[noise] Why encrypted keys are authenticated?

[Nadim Kobeissi]

Indeed, this is due to identity hiding considerations becoming more relevant later in the Noise Protocol Framework’s history.

The question becomes whether their assuming a more center stage warrants re-engineering how authentication occurs at the message layer matters. I don’t think so, since the overhead described seems minor and re-engineering things will likely entail a scenario where message authentication is selective only in cases where we have encrypted symmetric public keys. Nobody wants that complexity.

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from my laptop

> On May 13, 2019, at 12:49 PM, Loup Vaillant David <loup at loup-vaillant.fr> wrote:
> 
> Hi,
> 
> 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:
> 
>  XX:
>    -> 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.)
> 
> Loup.
> 
> 
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise