<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 25, 2016 at 1: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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">The fact that SIDH key pairs are generated specifically for either the "Alice" or "Bob" role is an interesting twist.  You make a good observation that Noise with SIDH could still support all patterns if each party has a doubled static "keypair" that contains both "Alice" and "Bob" SIDH keypairs, and uses one or the other, as needed.<div class="gmail_quote"><div><div><br></div><div>At the PETS conference I talked with Peter Schwabe, Isis, and others about PQ key exchange, and Peter mentioned this same idea (attributing it to MSR).</div></div></div></div></div></blockquote><div><br></div><div>I'm sure I wasn't the first to think of it. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div>Your proposed spec extensions make sense, but the Alice and Bob labelling seems somewhat specific to SIDH, so there's a question whether extensions like this should be:<div><br></div><div> (a) integrated into the main pseudocode in the main spec</div><div> (b) described in a separate section of the main spec (like PSK or SSK)</div><div> (c) described in a separate extension document</div><div><br></div><div>I lean away from (a) because I worry the spec is already too long.  I think Noise is fundamentally simple, but it will help people appreciate that simplicity if we cordon off new concepts (like "Alice" and "Bob" labelling) into a separate section - or, probably better, a separate document.</div></div></div></div></div></blockquote><div><br></div><div>Agreed.  Either an Appendix or a separate document for "post-quantum extension" is fine by me.  We already have cases where we say later "the definition changes in this way": PSK's alter the core definition of Initialize() and the "e" token, and SSK's alter the core definition of Split(), for example.<br><br></div><div>I think the only part we need to put in the main specification is the details of token doubling.  What does "Alg1+Alg2" mean for the definitions of the tokens?  As I said in a previous thread, "25519+448" would work as a forward secrecy strengthener so we don't need any extra algorithms to demonstrate how the tokens will work when doubled.</div><div><br></div><div>Cheers,<br><br></div><div>Rhys.<br></div></div><br></div></div>