[noise] Noise XK 5 should be a 4?

[David Wong]

I’ll write a more thorough message as I was on my phone yesterday.

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.

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:

XK:
  <- s
  ...
  -> e, es, p
  <- e, ee, p
  -> s, se, p


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.)

David

> On Apr 30, 2019, at 6:00 AM, Nadim Kobeissi <nadim at symbolic.software> wrote:
> 
> https://noiseexplorer.com/patterns/XK/E.html <https://noiseexplorer.com/patterns/XK/E.html>  
> 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software <https://symbolic.software/>
> Sent from office
> 
> 
> On Tue, Apr 30, 2019 at 6:07 AM david wong <davidwong.crypto at gmail.com <mailto:davidwong.crypto at gmail.com>> wrote:
> Oh right! The payload authenticates the handshake. 
> 
> I suggest a payload token!
> 
> David
> 
> > On Apr 29, 2019, at 8:56 PM, Trevor Perrin <trevp at trevp.net <mailto:trevp at trevp.net>> wrote:
> > 
> >> On Mon, Apr 29, 2019 at 6:22 PM david wong <davidwong.crypto at gmail.com <mailto:davidwong.crypto at gmail.com>> wrote:
> >> 
> >> I think my brain is farting, but shouldn't XK's last message provide a 4 in dest payload security?
> > 
> > I think the spec is right (5).
> > 
> > 
> >> You can send your own e as the server's response and the client's last handshake payload will have weak forward secrecy
> > 
> > Forging the responder(server)'s response requires knowledge of either
> > the responder's static private key or the initiator's ephemeral
> > private key.
> > 
> > In the messages marked 5 the sender has authenticated the recipient's
> > ephemeral using their own (sender) ephemeral and the recipient's
> > static key, so there's no "weak forward secrecy" issues.
> > 
> > 
> > Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org <mailto:Noise at moderncrypto.org>
> https://moderncrypto.org/mailman/listinfo/noise <https://moderncrypto.org/mailman/listinfo/noise>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20190430/cb024bd0/attachment.html>