[noise] Why encrypted keys are authenticated?

[Loup Vaillant David]

On Mon, 2019-05-13 at 16:48 -0700, Trevor Perrin wrote:
> On Mon, 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.
> 
> Hi Loup,
> 
> We discussed this briefly before:
> 
> https://moderncrypto.org/mail-archive/noise/2018/001864.html

Oh, kind of forgot about that. I may have dismissed this argument as
"of course, if implementations do stupid things, we'll get stupid
results". That was perhaps a little reckless </understatement>.

That said, I wonder whether there are even more serious oracles.  Like,
what if Curve25519 allows several representations of the same public
key? (That may depend on how many implementations interpret the high
bit as 2^255, or if they ignore it.) If the attacker XOR's the
canonical public key, then XOR the alternate representation, the result
should look like "unknown public key" instead of "broken handshake".
And there goes the anonymity of that key.

(Honest question: does the attack above look like it would work? It
only takes one such example to settle the issue once and for all.)


> Omitting the "authenticated" part can open up attacks against
> confidentiality, e.g. a network attacker can XOR something into a
> legitimate ciphertext causing the receiver to operate on a tampered
> plaintext in a way that reveals something about the plaintext (either
> via an error behavior or timing).

Well, the idea was, all inputs are processed in constant time, because
DJB is awesome. (Curve25519 implementations generally process
everything in constant time, even malicious inputs.) So I figured that
tampering with the ciphertext could only cause an error when we
authenticate the message, and that error would not leak any timing.

It's only today that I thought of alternate representation shenanigans,
and I'm starting to realise I was underplaying the importance of
mitigating implementation botches.

Loup.