[noise] Why encrypted keys are authenticated?

[Loup Vaillant David]

On Mon, 2019-05-13 at 09:00 -0700, david wong wrote:
> In the first case. The first encryption allows you to hide the static
> from passive observers. 

I'm not talking about encryption. I'm talking about *authentication*.
Besides, I believe the keys are encrypted only once.

The ENCRYPT() function does both encryption and authentication, and its
authentication tag is integrated to the message. I was wondering if we
could reasonably omit that authentication tag without losing any
security. I believe we can, but I wanted to make sure I didn't miss
anything.

(Of course, the authentication tag of the payloads should never be
omitted. As far as I understand, the whole security of Noise hinges on
those tags.)

Loup.



> David
> 
> Sent from my iPhone
> 
> > On May 13, 2019, at 3:49 AM, 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