[noise] Pattern validity questions

Alex alex at centromere.net
Sun May 14 13:06:16 PDT 2017

On Sun, 14 May 2017 19:52:48 +0000
Trevor Perrin <trevp at trevp.net> wrote:

> On Sun, May 14, 2017 at 7:31 PM, Alex <alex at centromere.net> wrote:
> > In section 7.1 of rev32b, item 2 states:
> >  
> >> Parties must not send their static public key, or an ephemeral
> >> public key, more than once per handshake (i.e. including the
> >> pre-messages, there must be no more than one occurrence of "e",
> >> and one occurrence of "s", in the messages sent by any party).  
> >
> > The language says, "no more than one", which indicates to me that
> > it's valid to have a pattern with zero e tokens. Wouldn't this lead
> > to catastrophic key re-use?  
> No, key reuse is prevented by 7.1 bullet 3 (for DH) and 9.3 (for PSK).
> Currently the spec allows handshake patterns which don't use any DH
> outputs or PSKs, for example the empty pattern, or patterns like:
>  -> e  
>  <- e
> Where public keys are transmitted but never used.
> We could add another validity rule to explicitly disallow this.
> However it's pretty obvious that if you don't use keys you won't get
> security.  So that doesn't seem like an important observation, and I
> think I'd be mildly opposed to adding it.
> > Should the language be modified to indicate
> > that the `e` token must appear "exactly once"?  
> I think the existing rules are sufficient.
> > And item 3 states:
> >  
> >> After performing a DH between a remote public key and any local
> >> private key that is not an ephemeral private key, the local party
> >> must not send any encrypted data unless they have also performed a
> >> DH between an ephemeral private key and the remote public key.  
> >
> > What is meant by "must not send any encrypted data"? Is information
> > contained in the payload of a Noise message considered encrypted
> > data, or does "encrypted data" refer to information encrypted with
> > keys derived from Split()?  
> What is meant is any data encrypted via ENCRYPT().  I'll think about
> how to be more explicit there.

So in Noise_IK:

Noise_IK(s, rs):
   <- s
   -> e, es, s, ss
   <- e, ee, se

it is valid for the initiator to send encrypted data in the payload of
its first Noise message, *only* because of the presence of the `es`
token, correct? In other words, had that token not been there, it would
be an invalid pattern?


More information about the Noise mailing list