[noise] Why encrypted keys are authenticated?

[Loup Vaillant David]

On Mon, 2019-05-13 at 19:17 +0200, Nadim Kobeissi wrote:
> Indeed, this is due to identity hiding considerations becoming more
> relevant later in the Noise Protocol Framework’s history.

I'm not sure I follow. Are you saying Noise evolved kinda like the
following?

"""
  First, keys weren't encrypted at all. Then the authors thought of
  identity hiding. So the existing ENCRYPT() function was used to
  encrypt the keys. The authentication tag it produces was just kept,
  and never questioned since.
"""

That would make sense. I would be more worried if those tags *were*
useful: it would mean I'm missing something, and in my line of work,
this would have consequences.


> 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 […]

I agree changing Noise would cause more problems than it would solve. I
however work on Monokex, which is closely related but not identical to
Noise. I don't require backward compatibility, so I'll take every ounce
of performance and simplicity I can get.


> […] and re-engineering things will likely entail a scenario where
> message authentication is selective only in cases where we have
> encrypted symmetric public keys.

I don't think it would: if you can encrypt a public key, then you can
authenticate the message that contains it, which Noise already does. A
handshake message currently cannot contain an encrypted DH key *and* a
plaintext payload. It would mean the symmetric state could *lose* its
key, and as far as I am aware it never does.

The selectivity you fear would likely not happen. Then again, I agree
with the main point: this change is likely not worth the trouble.

Loup.


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