[noise] Wrong arguments for KDF in PSK mode

[Trevor Perrin]

On Thu, Apr 21, 2016 at 9:58 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> In PSK mode, for NoiseIK (and similar), the first two calculations
> wind up being:
>
> ck, temp = KDF("NoisePSK_IK_blablabla", psk)
[...]
>
> The first line is somewhat problematic, because psk -- a key value --
> is used as the input parameter, and not as the key parameter. These
> arguments should be reversed:


I'd argue Noise is fine here:

(a) In the Random Oracle Model we assume the hashes are random
oracles, so HMAC and HKDF are also random oracles, and the outputs are
random if any inputs are random.

(b) HKDF endorses the use of a constant salt (as here), when nothing
better is available.

(c) Having any KDF do entropy extraction without random oracles or a
pre-existing random salt is difficult, so even if we required the PSK
to be uniformly random, we still wouldn't avoid the ROM without
complicated analysis about how the DH and hash function interact.
That would probably involve some assumptions about the DH producing
raw outputs that are close-enough to random, and the hash compression
function being a "dual PRF" when keyed through its "message", as
above.

(d) Note that whether you pass a key to HMAC in the first or second
argument, this key is processed as message data by the hash function.
So security reductions for HMAC (like Bellare's 2006 proof) already
need to assume that the underlying compression function is a "dual
PRF", a PRF when keyed either through the chaining variable or the
message.


I should add another Security Consideration discussing the importance
of a strong hash function, and clarifying the collision-resistance and
random-oracle assumptions we're making.

I'd also like to consider whether we should be more restrictive in
what we allow as PSK inputs, so people don't misuse PSKs with
low-entropy data, but I'll bring that up separately.


Trevor