[noise] Post-Quantum Kyber and Noise
Rhys Weatherley
rhys.weatherley at gmail.com
Thu Jul 6 02:43:10 PDT 2017
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.
It was a little awkward to integrate Kyber into HFS because HFS demands a
three-step process. The shared secret needs to be saved away until it can
be mixed in by the "ff" token at some future point. Something like the
following is more natural (NN+KEM):
-> e, ekey1
<- e, ee, ekem1
In WriteMessage(), the "ekemN" token encrypts the shared secret back with
the supplied public key and then immediately mixes the shared secret into
the chaining key. ReadMessage() decrypts the value and mixes the shared
secret into the chaining key.
XX with PQ authentication and forward secrecy:
-> e, ekey1
<- e, ee, ekem1, s, skey2, es
-> skem2, s, skey3, se
<- skem3
Cheers,
Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170706/7dee956e/attachment.html>
More information about the Noise
mailing list