<br><br>On Thursday, August 27, 2015, 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">
<br>
Currently handshake messages and transport messages are distinct due<br>
to aad=h, if you lose that difference you'd have to convince yourself<br>
there's no case where handshake and transport messages could get<br>
confused for each other.<br>
<br>
You could probably do that, or maybe add a minor tweak to<br>
differentiate them, so it's probably secure or close to it.<br></blockquote><div><br></div><div>I have a 1 byte prologue that contains a message type, so there's no chance of things getting accidentally "confused". But that doesn't rule out a malicious party cutting and pasting chunks together.</div><div><br></div><div>This is why in the previous noise spec, I liked how all previous bytes of the message were added to AAD at each step. This seemed like an elegant solution to this.</div><div><br></div><div>In either case though, I don't really see how this attack would be feasible. Let's say a MITM modifies a handshake message and changes my one byte prologue from "type=handshake" to "type=transport". Or, let's say a MITM modifies a transport message and changes my one byte prologue from "type=transport" to "type=handshake". So what? Since transport messages use different (derived) keys than handshake messages, wouldn't the mismatched messages be rejected immediately? What's the vulnerability here precisely?</div><br><br>-- <br>Jason A. Donenfeld<br>Deep Space Explorer<br>fr: +33 6 51 90 82 66<br>us: +1 513 476 1200<br><a href="http://www.jasondonenfeld.com" target="_blank">www.jasondonenfeld.com</a><br><a href="http://www.zx2c4.com" target="_blank">www.zx2c4.com</a><br><a href="http://zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc" target="_blank">zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc</a><br>