[noise] new branch: psk2

[Trevor Perrin]

Cleaned up the "psk2" pseudocode:

https://github.com/trevp/noise/tree/psk2

 - Moved "psk" boolean -> SymmetricState.has_psk
 - Renamed "has_key" boolean -> SymmetricState.has_k
 - Added SymmetricState.MixPresharedKey() to better encapsulate PSK
handling, instead of calling MixKey().  Since we're using the 2nd HKDF
output in a special way, it doesn't make sense to store it in k, or
set has_k.

The last change allows a slight substance change:  we feed the full
2nd HKDF output into MixHash(), so with a 512--bit hash we MixHash()
64 bytes instead of 32.  This is perhaps a tiny improvement in
security: it would make it harder to construct two different PSKs that
behave equivalently, even if you could find collisions on a 256-bit
hash, provided a 512-bit hash is used.

I've implemented this in "screech":

https://github.com/trevp/screech/tree/psk2


Trevor


On Fri, Nov 13, 2015 at 11:16 PM, Trevor Perrin <trevp at trevp.net> wrote:
> https://github.com/trevp/noise/blob/psk2/noise.md
>
> I realized a problem in how we were using ephemerals as nonces.  So
> I'd like to eliminate encryption of ephemeral public keys, and also
> streamline PSK by using ephemeral public keys in place of explicit
> randoms:
>
>
>  * A few months back we changed to allow encryption of ephemerals,
> e.g. in Noise_IK the responder's ephemeral would be encrypted.
> Unfortunately, if the initial message was replayed, encryption of the
> responder's ephemeral will not be secure (key reuse).
>
> There was no strong rationale for encrypting the responder's
> ephemeral, this was mainly done to simplify the logic.  So there's no
> real problem if this encryption is weak, but it seems bad form.
>
> We could address this by always using explicit nonces in this
> situation, but then we're making the protocol less efficient just to
> shore up this unimportant encryption.
>
> So this branch changes back to unencrypted ephemerals.
>
>
>  * Instead of sending an explicit random for pre-shared keys, changed
> it to MixKey(e.public_key) when sending/receiving an ephemeral with
> PSK.  I don't have patent worries about mixing ephemeral public keys
> into the session key, and this is simpler and eliminates the explicit
> randoms, so PSK messages are the same size.
>
> This makes it crucial for each party's first message to begin with
> "e", so I reordered "s, e" -> "e, s" in a couple patterns, and
> explained this in Section 6.1 "Pattern validity".
>
>
>  * A more subtle "invalid" pattern would be one that sent encrypted
> data without first doing a DH with the sender's ephemeral against any
> public keys the remote party has sent.  Example:
>
>  -> e, s
>  <- e, dhee, dhss
>
> This could be insecure if the DH function allows a public value with
> small order, e.g. with the traditional Curve25519 DH function an
> attacker could send a value which forces the output to zero.  If a
> bogus initiator repeatedly sends such an "e", then the responder's
> dhee randomization will fail, and there will be key reuse based on the
> dhss key.
>
> The IETF is contemplating ECDH functions that perform an explicit
> check of the output against zero, but that introduces other issues
> (more complex, not all existing implementations do this, not all DH
> functions necessarily do this, the check should be const-time, need to
> research point validation patents, etc).
>
> So I think it's better to be secure even in the face of this behavior.
> If we require a "valid" pattern to include DH from sender's ephemeral
> against all recipient public keys, the problem disappears:
>
>  -> e, s
>  <- e, dhee, dhes, dhss
>
> Forcing dhee to 0 doesn't prevent dhes from randomizing things.  Using
> bad s and e to force all DH ops to 0 isn't an attack, and if a PSK is
> introduced, it still gets randomized appropriately by
> MixKey(e.public_key).
>
> That's a bit complicated of an analysis, and imposing these conditions
> on the patterns creates some risk of misuse.  The upside is efficiency
> and simplicity when using correct patterns, which feels more
> important.
>
>
> Trevor