<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’ll write a more thorough message as I was on my phone yesterday.<div class=""><br class=""></div><div class="">This authenticating payload has tricked me several times when looking at Noise (and keeps tripping me up it seems). It is not a problem when implementing Noise, but when thinking about it and trying to figure out what you can do and when you can send application data, it is an issue. I’ve talked to many developers who have read the spec, and they also tend to forget that a payload can be sent at the end of every handshake message.</div><div class=""><br class=""></div><div class="">It would be interesting to have a new token `p` for payload, and a new rule stating that each message pattern must end with a `p` token. It does sound redundant but I believe it adds clarity to the protocol. (In Disco, this would make even more sense as sending the final authentication tag can be seen as a separate step from sending the payload). XK would look like this:</div><div class=""><br class=""></div><div class=""><pre style="font-family: monospace, monospace; font-size: 0.98em; line-height: 1.25em; background-color: rgb(255, 255, 255); white-space: pre-wrap; overflow-wrap: break-word; margin-top: 0px; margin-bottom: 0px; color: rgb(68, 68, 68); font-variant-ligatures: normal; orphans: 2; widows: 2;" class=""><code style="white-space: pre; font-family: monospace, monospace; font-size: 0.98em; line-height: 1.25em;" class="">XK:
<- s
...
-> e, es, p
<- e, ee, p
-> s, se, p</code></pre><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">It’s a bit late to change the spec, so of course I don’t feel strongly about this one. (But I find this more elegant and clear.)</div><div class=""><br class=""></div><div class="">David<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 30, 2019, at 6:00 AM, Nadim Kobeissi <<a href="mailto:nadim@symbolic.software" class="">nadim@symbolic.software</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><a href="https://noiseexplorer.com/patterns/XK/E.html" class="">https://noiseexplorer.com/patterns/XK/E.html</a> <br clear="all" class=""><div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Nadim Kobeissi<div class="">Symbolic Software <span style="color:rgb(84,84,84);font-size:small" class="">• <a href="https://symbolic.software/" target="_blank" class="">https://symbolic.software</a></span></div><div class=""><span style="color:rgb(84,84,84);font-size:small" class="">Sent from office</span></div></div></div></div></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 6:07 AM david wong <<a href="mailto:davidwong.crypto@gmail.com" class="">davidwong.crypto@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Oh right! The payload authenticates the handshake. <br class="">
<br class="">
I suggest a payload token!<br class="">
<br class="">
David<br class="">
<br class="">
> On Apr 29, 2019, at 8:56 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank" class="">trevp@trevp.net</a>> wrote:<br class="">
> <br class="">
>> On Mon, Apr 29, 2019 at 6:22 PM david wong <<a href="mailto:davidwong.crypto@gmail.com" target="_blank" class="">davidwong.crypto@gmail.com</a>> wrote:<br class="">
>> <br class="">
>> I think my brain is farting, but shouldn't XK's last message provide a 4 in dest payload security?<br class="">
> <br class="">
> I think the spec is right (5).<br class="">
> <br class="">
> <br class="">
>> You can send your own e as the server's response and the client's last handshake payload will have weak forward secrecy<br class="">
> <br class="">
> Forging the responder(server)'s response requires knowledge of either<br class="">
> the responder's static private key or the initiator's ephemeral<br class="">
> private key.<br class="">
> <br class="">
> In the messages marked 5 the sender has authenticated the recipient's<br class="">
> ephemeral using their own (sender) ephemeral and the recipient's<br class="">
> static key, so there's no "weak forward secrecy" issues.<br class="">
> <br class="">
> <br class="">
> Trevor<br class="">
_______________________________________________<br class="">
Noise mailing list<br class="">
<a href="mailto:Noise@moderncrypto.org" target="_blank" class="">Noise@moderncrypto.org</a><br class="">
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank" class="">https://moderncrypto.org/mailman/listinfo/noise</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>