[noise] Pre-shared Secret - preventing DoS, and ensuring post-quantum PFS

[Trevor Perrin]

On Wed, Nov 11, 2015 at 2:26 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Wed, Nov 11, 2015 at 10:16 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>  * A Noise handshake specifies a fixed sequence of MixKey / MixHash
>> steps, so we can't add an optional MixKey to a handshake.  This would
>> require either specifying "preshared_key" versions of the handshakes,
>> or always performing an extra MixKey().
>
> Why would optional be bad? The idea would be - if both parties a) know
> to use a pre-shared key and b) use the same pre-shared key, their
> handshakes will be successful. Otherwise, they're not legitimate.

Because if you use the same keys for preshared-key and
non-preshared-key handshakes, the role of the different MixKey steps
would be ambiguous.


>>  * h is intended to bind *all* previous data, but also to be
>> non-secret, so we'd need to MixHash() some value derived from the
>> pre-shared key.
>
> I had feared this. So in that case what about: "If a pre-shared key is
> provided, in Initialize, call MixKey(psk) followed by MixHash(psk)."
> Off-hand, I can't imagine any reason why this would leak anything
> important.

That's not making this simpler, and also I'd prefer to MixHash an
independent value, not the psk directly.


>> So instead of a pre-shared symmetric key, the parties could use
>> pre-shared ephemeral public keys, and you could augment any handshake
>> to a "pse" version like this:
>>
>> Noise_IK_pse(s, rs):
>>   -> e
>>   <- s, e
>>   ------
>>   -> dhee, e, dhes, s, dhss
>>   <- e, dhee, dhes
>
> In this version, is the pre-shared ephemeral "e" a different "e" (say,
> e prime) than what's later exchanged?

Yes.


> In other words, do you mean
> this:
>
>   -> e'
>   <- s, e'
>   ------
>   -> dhee, e, dhes, s, dhss
>   <- e, dhee, dhes


I meant it as written - the spec says every occurrence of "e"
generates a new ephemeral.


> But this has a major problem. From the spec:
>
>     "Calls MixHash() once for each public key listed in the pre-messages
>     from new_handshake_pattern, passing in that public key as input"
>
> Since only MixHash() is called on each pre-shared ephemeral, the
> pre-shared ephemerals do NOT become part of the symmetric encryption
> key.

They contribute to the key through the initial "dhee".


> The symmetric encryption key, then, is still derived from only
> diffie-hellman results, the public keys for which are shared through
> the wire.

No, the pre-message public keys are not "shared through the wire".


> This means PFS is broken if the DH function is broken
> (post-quantum, better rho, other DH weaknesses...), which is the
> precise threat model I wanted to protect against. If all our traffic
> is logged, I don't want it to be decryptable in the future.

If you're keeping the ephemeral DH public keys secret, there's nothing
to break, and this is the same as a pre-shared symmetric key.


>> > 2. If a pre-shared secret is provided, the first unencrypted public key written receives a MAC (using hmac or keyed-blake2) using the pre-shared secret.

Also with what I suggested.


Trevor