<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 8:48 AM, Adam Crain <span dir="ltr"><<a href="mailto:jadamcrain@automatak.com" target="_blank">jadamcrain@automatak.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><br></div></div></div></div>I have a question regarding how Noise uses AEAD cipher modes to authenticate the key agreement. Is this primarily how Noise accomplishes "identity hiding"? I.e., all the key agreement payloads would be encrypted, thus observers wouldn't see any payload certificates, etc?</div></div></div></div></div></blockquote><div><br></div><div><br></div><div><div>Hi Adam,</div><div><br></div><div>The AEAD during handshake accomplishes a few things, not just identity hiding, e.g.</div><div> - encrypts and authenticates handshake payloads</div><div> - confirms that the other party has derived the correct keys</div><div> - confirms that the other party has the same view of handshake hash</div><div><br></div><div>If you want authentication of data, not confidentiality, I suppose you could define ENCRYPT() and DECRYPT() in terms of HMAC (which Noise needs anyways), e.g.</div><div><br></div><div>ENCRYPT(k, n, ad, plaintext): </div><div>  plaintext || HMAC(k, n || len(ad) || ad || plaintext)</div><div><br></div><div><br></div><div>A lot of the Noise patterns defer sending static public keys until they can do it under encryption, but if that doesn't matter for you, you could consider patterns where all static public keys are sent in clear, like:</div><div><br></div><div>-> e, s</div><div><- e, s, dhee, dhes, dhse</div><div><br></div><div><br></div><div>Trevor</div></div><div><br></div></div></div></div>