[noise] Why encrypted keys are authenticated?

[Trevor Perrin]

On Mon, May 13, 2019 at 6:48 PM Loup Vaillant David
<loup at loup-vaillant.fr> wrote:
> >
> > 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?

X25519 does allow several representations of the same public key (e.g.
add a small-order point to one public key to get an equivalent one).


> (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.)

Sure, if the app inspects the public key after it's decrypted but
before it's authenticated you'd have to worry about things like that.

Which is a good reason to tightly laminate encryption and
authentication together so you don't have this dangerous time interval
between them.


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

"constant time" is a term of art that refers to something more
specific: code that doesn't leak information about its secret inputs
(keys, plaintext).

I'm not sure X25519 functions consistently treat the other party's
public key as a "secret input", that's kind of an edge case.  For
example, some X25519 implementations will behave differently (return
an error value) if given a small-order public key, and public-key
validation is also common for some other types of public keys.

So I'm not sure your reasoning about "constant time" crypto code
making this safe is correct.

Trevor