[noise] Why encrypted keys are authenticated?

Loup Vaillant David loup at loup-vaillant.fr
Mon May 13 03:49:50 PDT 2019


Noise has an apparent redundancy that bothers me a little: encrypted
public keys in handshake messages are authenticated *twice*: once with
the key that encrypts them, and once again with the key that encrypts
(and authenticates) the payload message. This lengthens the handshake
messages for no apparent reason beyond paying lip service to Moxie's
cryptographic doom principle.

Let's take for instance the XX pattern:

    -> e
    <- e, ee, s, es
    -> s, se

The responder's key is authenticated
- with ee
- with ee + es

The initiator's key is authenticated
- with ee + es
- with ee + es + se

In each case, the first authentication looks useless: when the
initiator decrypts the responder's static key, it can only rely on the
transmitted ephemeral key, which at this point could have been sent by
anyone. An attacker who wants to send a corrupted static key can just
make sure it authenticates against ee, and the initiator will only be
able to tell by verifying the transcript with ee + es, and validate the
responder's key at the application layer.

Likewise, when the responder decrypts the initiator's key, they only
have the initiator's ephemeral to work with. They too have to verify
the transcript tag with ee + es + se, then validate the initiator's key
at the application layer.

Another way to look at it is that encryption is not even required to
get a secure handshake. If we just transmitted the static key in plain
text, we'd only lose the anonymity properties of the handshake. The
other properties would be preserved. Assuming I'm correct about this
(am I?), then we don't *need* integrity at this point, just secrecy:
integrity comes naturally with the transcript tags.


Hence my question: why the double authentication? Is there any known
security property that would be hurt by removing the redundancy? Or was
it done just because it felt safer, simpler, or easier?

(Also, whatever the reason, it might be a good idea to add it to the
rationales, as was done for the choice of HKDF.)


More information about the Noise mailing list