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

[Jason A. Donenfeld]

On Wed, Nov 11, 2015 at 11:40 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>> 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.

Doesn't this pose some problem?

-> e
<- s, e
-----
-> dhee, [X] ...

At point [X] there, k and ck are the same every time. I see how this
amounts to having a preshared key (as you pointed out later in your
email), where none of the public nor private components are known, but
it could pose a problem: the next encryption (of e) uses the same key
and nonce everytime. I know that the plain text (e) changes every
time, but still -- isn't this a big no no? e isn't completely random
either - it will be a point on the curve. From the poly1305 paper:

> Any protocol that uses Poly1305-AES must ensure unpredictability of the secret
> key (k, r). This section assumes that secret keys are chosen from the uniform
> distribution: i.e., probability 2 −234 for each of the 2^234 possible pairs
> (k, r). Any protocol that uses Poly1305-AES must ensure that the secret key
> is, in fact, kept secret. This section assumes that all operations are
> independent of (k, r), except for the computation of authenticators by the
> sender and receiver. (There are safe ways to reuse k for encryption, but those
> ways are not analyzed in this paper.) The sender must never use the same nonce
> for two different messages. The simplest way to achieve this is for the sender
> to use an increasing sequence of nonces in, e.g., reverse-lexicographic order
> of 16-byte strings. (Problem: If a key is stored on disk, while increasing
> nonce values are stored in memory, what happens when the power goes out?
> Solution: Store a safe nonce value—a new nonce larger than any nonce used—on
> disk alongside the key.) Any protocol that uses Poly1305-AES must specify a
> mechanism of nonce generation and maintenance that prevents duplicates.

To make this safe, wouldn't you have to mix in some random value too?

>
>>> > 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.

Ahh, neat - because of the Poly mac on the first e. But see my objection above.