<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 5, 2017 at 3:33 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To throw something out, a different notation could allow numbered sets<br>
of public keys, with the keys in each numbered set only allowed to<br>
interact with each other?  So instead of "f", hybrid forward-secrecy<br>
could be:<br>
 -> e1<br>
 <- e1, e1e1<br>
<br>
And hybrid, ephemeral-static encryption, done in the same protocol, could be:<br>
 -> s2<br>
 <- e2, s2e2<br></blockquote><div><br></div><div>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.<br><br>KEM's by contrast are a two-step process: Alice sends her public key, Bob encrypts the shared secret back to Alice's key.<br><br></div><div>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):<br></div><div><br></div><div>-> e, ekey1<br></div><div><- e, ee, ekem1<br></div><div><br></div><div>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.<br><br></div><div>XX with PQ authentication and forward secrecy:<br></div><div><br>-> e, ekey1<br><- e, ee, ekem1, s, skey2, es<br>-> skem2, s, skey3, se<br></div><div><- skem3<br></div><div><br></div>Cheers,<br><div><br></div><div>Rhys.<br></div><br></div></div></div>