[noise] Why encrypted keys are authenticated?

[Loup Vaillant David]

> If I understand the point you're attempting to make, you want to
> shoehorn in unauthenticated encryption as a micro-optimization to
> save the size of one MAC in the key exchange.

That, the cost of computing the MAC, and the cost of programming it
all. (Very small costs I concede.)


> An open question though: can an attacker inject low-order points in
> the authenticated protocol and use them to perform a MitM attack? 

I believe this point was addressed by Noise's restriction that the
result of exchanges from low order points must be independent from the
victim's key. Curve25519, and I believe Curve448, yield "zero" when a
low order point is used.


> I think the onus is on you to demonstrate:
> 
> 1) […]
> 2) This change does not introduce security vulnerabilities owing to
> an attacker who is able to inject low order points and therefore have
> a D-H output be zero

Because of the restriction above, I'm not too worried about that. If I
was, I'd be worried about patterns like IX, where the initiator sends
all keys in plaintext with no authentication whatsoever.

My biggest concern right now is that not authenticating the keys could
expose an oracle attack (the attacker could modify the ciphertext,
observe errors/timings on the other end, and deduce the true value of
the key).

It would be nice if we could prove the absence of such oracles (if for
instance any modification to the ciphertext could only trigger constant
time failure at the other end). One way it could go wrong, is that if a
point in the curve has several representations, the attacker could try
them and see if one works (the attacker would receive "unknown public
key" instead "wrong handshake").  If it does, the attacker has found
the public key, and broke anonymity.

I don't know if the above is possible with Curve25519 or Curve448, but
that would be the kind of stuff I'm looking for.

Loup.