<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 27, 2017 at 6:24 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;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">I was thinking the client would send:<br>
<br>
version with explicit 25519 ephemeral<br>
version with implicit 25519 ephemeral<br>
version with implicit 25519 ephemeral<br>
...<br>
<br>
version with explicit 448 ephemeral<br>
version with implicit 448 ephemeral<br>
version with implicit 448 ephemeral<br>
...<br>
<br>
That would save bytes in case you're offering, say, a 25519 public key<br>
with several different ciphers.<br>
<br>
But Rhys is probably right that for simplicity we should just have all<br>
initial messages be explicit.<br></blockquote><div><br></div><div>Here's an alternative I thought of after sending my previous message:</div><div><br></div><div>0: XX_25519...AESGCM with explicit 25519 ephemeral<br>1: XX_25519...ChaChaPoly, duplicate 0<br>...</div><div>8: XX_448...AESGCM with explicit 448 ephemeral<br>9: XX_448...ChaChaPoly, duplicate 8<br></div><div><br></div><div>For implicit sub-messages, the number of the previous sub-message "e" that is being duplicated is given.  Then the responder doesn't have to "just know" which of the previous messages is being implicitly duplicated.  A single-byte sub-message with the index should be sufficient as there are no valid Noise handshakes with single-byte messages.</div><div><br></div><div>Duplication can only be used when the entire first handshake packet is identical.  In other words, "I already gave you the data for this packet in sub-message 8 above".  It should be easier to validate and less knowledge is needed to guess which of the previous sub-messages contains the "e" of interest.</div><div><br></div><div>Duplicating the entire packet makes the scheme easier to extend to HFS: it's not just the "e" that is elided, but "e, f".</div><div><br></div><div>If the sender did something deliberately malicious like duplicate a previous short 25519 packet for a later 448 pattern, then the normal length and packet validity checks will catch the problem later and the handshake will fail.</div><div><br></div><div>Cheers,</div><div><br></div><div>Rhys.<span class="gmail-HOEnZb"><font color="#888888"><br>
</font></span></div></div><br></div></div>