<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 24, 2016 at 8:12 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">As an alternative, consider:<br>
 * "f" - send the first public value<br>
 * "g" - send the second public value<br>
 * "fg" - MixKey() on the secret key output<br></blockquote><div><br></div><div>Are we also going to split "e" and "s" into "first value" and "second value"?  Well, we sort of already do with the variables "e"/"re" and "s"/"rs".  The "g" that you refer to above is really "rf" from the initiator's point of view.<br><br></div><div>This highlights another source of confusion in the current specification, with "e"/"s" used as variables in the HandshakeState and as tokens operating on said variables (or their "rx" counterparts).  Do we want to clean this up too?  "var-e", "var-s", "var-re", "var-rf", etc?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

That fixes above problems, but introduces new ones:<br>
 * "fg" and "dhxx" no longer look the same, so it becomes harder to<br>
read the pattern and immediately see which tokens send values, and<br>
which are MixKey() steps.<br>
</blockquote><div><br>"mix-ee", "mix-ss", etc instead?<br> </div> * change the convention so that the first character in "xy" refers to<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
the initiator, not the message sender.  This means the token's role in<br>
the overall protocol is not context-dependent, which a number of<br>
people have complained makes the patterns hard to read.  So we'd have:<br></blockquote><div><br></div><div>I'm not sure about this one.  Hard to read maybe, but not hard to implement.<br><br></div><div>WriteMessage() and ReadMessage() implement the tokens using the "local keypair" and "remote public key".  The code does exactly what the token tells it to do without reference to initiator vs responder.<br><br></div><div>With the proposed change, most of the tokens would be "do what it says", except for "se" and "es", which need to be flipped at runtime depending upon whether the "s"/"e" is local or remote at that point in the handshake.  Effectively the code needs a different implementation of WriteMessage()/ReadMessage() depending upon whether the role is initiator or responder.<br></div><div><br></div><div>Also, it is currently implied by "dhxy" that "x" is a key pair and "y" is a public key (in WriteMessage, reversed for ReadMessage).  With the proposed change, it is more subtle as to which is which.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So we'd have a clear distinction between single-char tokens (send a<br>
value) and double-char tokens (mix two values into the KDF), and the<br>
token names don't care whether the "mixing" is DH, or a KEM, or<br>
One-Pass Key Exchange, or whatever.<br></blockquote><div><br></div><div>In principle I'm OK with dropping/replacing the "dh" as long as it is obvious how to implement any given variable/token/etc.</div></div><br></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>