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

[Karthikeyan Bhargavan]

Hi Trevor,

Re-reading other parts of the spec, authentication goal 1 explicitly speaks about “ss”, so this may need to change as well,
if we decide we want to forbid patterns that rely on “ss” for authentication (which I think is good general advice, but perhaps too strong a restriction.)

“””
Sender authentication vulnerable to key-compromise impersonation (KCI). The sender authentication is based on a static-static DH ("ss") involving both parties' static key pairs. If the recipient's long-term private key has been compromised, this authentication can be forged. Note that a future version of Noise might include signatures, which could improve this security property, but brings other trade-offs.
“””

Responding to a couple of your other comments:

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

I agree that there has been a lot of confusion about this, even for X25519.
I was speaking of an is_on_curve check which is typically less expensive
than scalar multiplication, but yes, can be difficult to implement for some coordinate systems.

A question worth asking is what if someone uses Noise with P-256?
In that case, they do need to perform key validation or else may be vulnerable to invalid curve attacks, right?
It may be good to warn about this in the security considerations.

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

Indeed, I do think of “ss” as a way of computing a PSK from static DH keys.
In that sense, any protections we provide for PSK patterns should be inherited
by pure “ss” patterns (unless we forbid pure “ss” protocols, as you indicate.)

-Karthik


>> 
>> Trevor
>> 
>> [1] https://moderncrypto.org/mail-archive/curves/2017/000896.html
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180622/66034d06/attachment.sig>