[noise] Why encrypted keys are authenticated?
nadim at symbolic.software
Mon May 13 10:17:06 PDT 2019
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.
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:
> 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.)
> Noise mailing list
> Noise at moderncrypto.org
More information about the Noise