[noise] Another spec issue: remote ephemeral keys

[Trevor Perrin]

On Sat, Apr 16, 2016 at 3:07 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> Just to beat this dead horse one more time before I shut up. :-)
>
> I wrote a test to investigate the impact of null keys (ephemeral or static)
> on the chaining key.  For this purpose I classify "entropy collapse" as a
> scenario where all DH outputs are the null value, making the chaining key
> completely deterministic even if some of the inputs were non-null.

That's a nice list, but I'd describe it as listing the sets of private
keys which, if revealed, would allow decrypting the session.

My contention is there's no important difference between:
 (a) public key is small-order, thus always produces a fixed output,
e.g. the "null" public key
 (b) public key corresponds to a published private key which everyone
knows, thus always produces a known output

You're right that in the (b) case the session keys would still be
randomized, but I don't think there's a meaningful difference between
a compromised deterministic key and a compromised randomized key.

We've taken care in 8.1 Pattern Validity to ensure null public values
can't affect the randomized use of non-compromised keys.  And we've
take care in the "channel binding" discussion to ensure sessions have
unique identifiers (h) even if they have shared keys.

So I still don't think any more checks are needed.

Trevor