If handshake_name is used as the initial k, as you've changed in response to my first inquiry, it doesn't _also_ need to be included in the initial h, because the first call to encrypt/getkey will use k, and thus h will be bound to the initial value of k, which is handshake_name. Therefore, I'd suggest k = handshake_name, h = empty. Jason <div class="gmail_quote">On Oct 1, 2015 6:46 PM, "Trevor Perrin" <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Oct 1, 2015 at 3:00 AM, Jason A. Donenfeld <<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>> wrote: > With a premessage and a handshake name, things wind up looking like: > > initiator.key = 32 bytes of zeros > initiator.hash = HASH("Noise WireGuard zx2c4 2015-09-30" || > responder.static_public) > > Why not instead initiate the key with the handshake name, instead of the > hash? It seems like this would also go a bit further in reducing key-reuse > too. So, instead: > > initiator.key = "Noise WireGuard zx2c4 2015-09-30" > initiator.hash = HASH(responder.static_public) I want h to bind everything, including the name, so it could later be used for signatures etc. But now that we're not special-casing the first MixKey(), we might as well get use out of it, and you're right that mixing the name into k is a little more conservative, in case keys are shared with some other protocol that doesn't take any reuse precautions. So I've changed revision 8 to set k = h = handshake_name. Trevor </blockquote></div>