[noise] Stricter rules #2: PSKs fixed to 256 bits

[Trevor Perrin]

Currently the PSK can be an arbitrary-length sequence of bytes, though
in Security Considerations we say "should be secret values with 256
bits of entropy (or more)".

I worry that people might be tempted to feed low-entropy data like
passwords into the PSK input.  They might assume Noise will take care
to protect the password and only use it over a secure channel based on
DH authentication.

But Noise doesn't do that!  Noise assumes the PSK is a secure key and
uses it immediately to help encrypt/authenticate.  Consider the first
message of NoisePSK_XX:

 -> e

The payload is encrypted/authenticated by a PSK.  That's good, because
the PSK can be used to accomplish 0-RTT encryption with session
tickets or caches, but it means a low-entropy PSK is exposed to
offline guessing attacks.


So I'm considering requiring the PSK to be a 256-bit value with 256
bits of entropy.  Benefits:

 (a) Makes clear that you should be passing a key with large entropy,
not a password.

 (b) Simplifies Noise implementation, since HKDF doesn't have to
handle arbitrary-length inputs, only DHLEN and 32-byte inputs (which
are the same with 25519).

 (c) Possibly simplifies the security analysis, since we don't have to
worry about whether unsalted HKDF does good entropy extraction from
arbitrary PSK distributions, and there's possibly some super-tiny
security benefit in giving less control for someone trying to input
malicious PSK values (not that that's a realistic attack model, or
that it should have any effect on a good hash function).

Thoughts?

Trevor