[noise] NoisePSK

[Jason A. Donenfeld]

On Thu, Nov 12, 2015 at 9:12 AM, Trevor Perrin <trevp at trevp.net> wrote:
> The issue is that Noise doesn't use explicit random values to prevent
> key reuse (like TLS ClientRandom / ServerRandom).  Instead, Noise
> relies on unique-per-handshake ephemerals, but that doesn't work for
> encrypting the ephemerals themselves.

>  (2) The initiator and responder's first messages begin with a 32-byte
> random field, and MixKey(random) is called on it, before processing
> the rest of the message.

Cool, this is what I had in mind mentioning random values in my
previous email; I like this idea. It's a lot more straightforward than
adding XChaCha20 support, though it is quite a bit more
computationally expensive. For example, for the DoS protection in a
NoiseIK, before being able to discard the message upon attempted
decryption/authentication of the first public ephemeral, this would
result in:

MixHash(handshake || prologue) - 1 hash
MixHash(pubkey) - 1 hash
HKDF(psk, none) - 6 hash
MixKey(psk1) - 6 hash
MixHash(psk2) - 1 hash

15 hashes in total. I don't have any numbers, but I imagine this is
still computationally preferable to a single DH, but still, it's an
awful lot.

For better DoS protection, you could add another aspect - a 32 byte
MAC from Keyed-Blake2 over all the previous bytes of the handshake
message, as the last field, that uses the psk as a key. This way
invalid messages could be discarded after a single keyed-hash
operation, instead of 15.

>
> This way, security from DH and PSK would be additive:  even if all DH
> stuff is insecure you get security from PSK, and vice versa.

Terrific. The way I'd probably go about using this is that for users
who don't provide a PSK of their own, I'll automatically use
"initiator.static_public || responder.static_public" as the PSK. This
way, so long as the public keys stay secret or are forgotten about
before the advent of a quantum computer / DH cryptographic advances,
the messages automatically remain safe. What do you think of that
idea? Is it as safe as I'm hoping?

> Thoughts?

I like the general idea here! Thanks a bunch for beginning to spec this out.