[noise] Potential forgery attack on "ee, ss" patterns

[Karthikeyan Bhargavan]

Hi Trevor,


> That pattern is invalid per bullet 3 of 7.1:
> 
> http://noiseprotocol.org/noise.html
> """
> After performing a DH between a remote public key and any local
> private key that is not the ephemeral private key, the local party
> must not call ENCRYPT() unless it has also performed a DH between the
> ephemeral private key and the remote public key.
> “""

Aha! We misinterpreted the intention syntactic rule and so our pattern was accepted by noise explorer.
It hinges on the definition of “remote public key”.

One reading of this rule would be the following:
After performing a DH between a remote public key (some remote e or remote s)  And any local key that is not the ephemeral private key (some local s), the local party must not call ENCRYPT() unless it has also performed a DH between the ephemeral private key (some local e) and the remote public key (the same remote e or remote s).

Under the above interpretation the pattern KXS I showed you is valid, right?  Maybe by “remote public key” you meant to say “remote static key”? If so, this rule would not apply to all patterns, so I wonder if more word smithing is required here.

In any case, you are right that it does not have the same security as KX:  the authentication level is 1, and the confidentiality level is “5” or something. Still it is “good enough” to send messages if the responder does not care about KCI and is happy with weak PFS, right?


> So this is another reason for the validity rule:  Noise forces people
> to to use ephemeral-static DH for authentication, not static-static,
> because ephemeral-static DH provides better security in case the
> static keys are compromised.  The "ss" token is used in current
> patterns when there's no other option for authentication (e.g. 0-RTT),
> and could also be used for resistance to ephemeral-key compromise, but
> we've otherwise taken an opinionated stance against relying on "ss”.

This opinion was not obvious from the spec and should probably be made more explicit?
It is otherwise not obvious to the reader why Noise would allow unauthenticated patterns like NN but not allow weakly authenticated patterns like KXS.

Best regards,
Karthik



> 
> 
>> At a high-level, the above analysis  can be read in one of three ways:
>> 1) We need to be careful about uses of “ss” in Noise patterns
>> 2) We need to validate DH public values, including for Curve25519
>> 3) We need to ensure that independent sessions cannot have the same AEAD
>> keys
>> 
>> Consequently, a simple countermeasure would be any of the following:
>> 1) Forbid the use of “ss” unless accompanied by se or es
>> 2) Require implementations to validate incoming DH public values
>> 3) Mix ephemeral+static public DH values into the encryption key
> 
> The (1) bullets are the approach taken by Noise, in validity rule #3.
> 
> You mention a couple alternatives:  One was "validating" public keys.
> It's not clear what you mean, validating EC public keys has
> historically meant different things, some of them expensive, and this
> ambiguity has caused problems [1].  In particular, Noise is most
> commonly used with X25519 (previously Curve25519), for which
> widespread software and specs exist that don't apply any of the checks
> you might ask for, and which advertise the simplicity of this API as a
> virtue.
> 
> So if we were to rely on some set of validation checks while allowing
> patterns like KXS, people would likely use these patterns with
> libraries for which it was unsafe (e.g. versions of NaCl, libsodium,
> donna, etc).
> 
> Your (3) proposal was to randomize the calculation by using ephemeral
> public keys as nonces.  We do this if PSKs are involved, since we want
> PSK protocols to be secure even if all the DHs are bad.  But since
> we've already decided to force people to do ephemeral-static DH, this
> would just add unnecessary calculation to pure-DH protocols.
> 
> Trevor
> 
> [1] https://moderncrypto.org/mail-archive/curves/2017/000896.html