[noise] Post-Quantum Kyber and Noise

[Trevor Perrin]

On Thu, Jul 6, 2017 at 9:43 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Wed, Jul 5, 2017 at 3:33 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> To throw something out, a different notation could allow numbered sets
>> of public keys, with the keys in each numbered set only allowed to
>> interact with each other?  So instead of "f", hybrid forward-secrecy
>> could be:
>>  -> e1
>>  <- e1, e1e1
>>
>> And hybrid, ephemeral-static encryption, done in the same protocol, could
>> be:
>>  -> s2
>>  <- e2, s2e2
>
>
> While this could work, I think this is stretching the model a little.  A DH
> exchange has three steps: Alice sends her public key, Bob sends his public
> key, Alice&Bob calculate the shared secret once both keys are available.
> Pre-messages can stand in for sending a key of course.
>
> KEM's by contrast are a two-step process: Alice sends her public key, Bob
> encrypts the shared secret back to Alice's key.


Mm, good point!

[As a minor point, the "KEM" notion returns a secret key as output of
"encapsulation" and "decapsulation", it's not the case that the caller
chooses the secret key and the KEM encrypts it, which is what
"encapsulation" would make you think!  KEM is not a great name, but
it's what cryptographers have chosen.]

But you're right there's a difference:
 - With DH, the second party performs a key-generation to get a
(public key, private key), and later performs an "ee" DH to get a
shared secret key.
 - With KEM, the second party performs an encapsulation to get a
(ciphertext, shared secret key) right away.

So you have a good point that treating the KEM as DH requires storing
the shared secret key so it can be used with MixKey() later.  On one
hand that's not that different from storing an ephemeral private key
to use later.

On the other hand, does it gain anything?  Is there a reason to
support this flexibility (separating encapsulation from MixKey)?  I
don't see one right now, anyone else?

Assuming Rhys is right that we always want to perform
encapsulation+MixKey together, there's a notation question.  Rhy
suggests:
 -> ekey1
 <- ekem1

 -> skey1
 <- skem1


Another option:
 -> e1
 <- e1e1

 -> s1
 <- s1e1


A third option:
 -> e1
 <- e1kem

 -> s1
 <- s1kem

?


Trevor