<html><head></head><body><div><div><div style="display:none;border:0px;width:0px;height:0px;overflow:hidden"><img src="https://r.superhuman.com/bwJ7vf7CryXVN4XOiy0HK0fGXNVpqlPP6heLJlR5zsPdcgTJMZTTzVnUskj5IQ2SxpRjHOGClwhNPpqUV-xjQ7d8ZzgJPzmDdDG9Cf4WLGZhc4KvpFUyuF95l4F5A0QE3T9ijQCdoiwcwGcfx6IQVbU.gif" alt=" " width="1" height="0" style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden; visibility: hidden;"></div><div><div class="">During a code review a colleague flagged an issue that I don't have a great answer for.<br></div><div class=""><br></div><div class=""> The Noise spec requires that the EncryptWithAd operation might not actually encrypt, if it's called before the key is set. This seems surprising and potentially a source of subtle bugs. I'd have expected an error to be signalled if you attempt an encryption or decryption operation without a key.<br></div><div class=""><br></div><div class="">It appears it's defined this way to make WriteMessage simpler when processing an initial key in the first part of a handshake, before any DH operation has run. Everything being written out can be passed through EncryptAndHash without a special case for the position where no key is available. But translated directly to code this results in a rather odd exception inside the core encryption codepath which just looks all wrong. My colleague was right to flag it, even though the overall protocol and algorithm is correct.<br></div><div class=""><br></div><div class="">Perhaps a future spec revision could adjust the definition of WriteMessage to fork the codepath depending on if 'k' is set, before CipherState is invoked?<br></div><div class=""><br></div><div class="">thanks,<br></div><div class="">-mike</div></div><br><div class="gmail_signature"></div></div></div></body></html>