[noise] Another spec issue: remote ephemeral keys

[Trevor Perrin]

On Fri, Apr 15, 2016 at 4:10 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> In section 5.3 under the description of ReadMessage():
>
>     For "e": Sets re to the next DHLEN bytes from the
>     message.  Calls MixHash(re.public_key).
>
> That should probably read as:
>
>     For "e": Sets re to the next DHLEN bytes from the
>     message.  If "e" is the null public key value, then
>     abort the handshake with an error.  Otherwise call
>     MixHash(re.public_key).
>
> While implementing ReadMessage() today, I realised that a hostile party
> could downgrade the security of the handshake to "none at all" by specifying
> a null ephemeral key in their first packet.  That will cause all future
> encryption key values to become predictable to an eavesdropper.

A hostile party could always downgrade the security of its own
handshake, e.g. by using an ephemeral with a known/published private
key.

Using a null ephemeral public key shouldn't accomplish anything more
than that.  (It won't necessarily cause "all future encryption key
values to become predictable", only those involving the null public
key.  The validity rules in 8.1 ensure that encryption based on other
key values is still randomized).

So checking for null public keys isn't required (unless you want to
optimize for them by skipping the DH calculation).

Maybe we could explain this a little better...


> It may also be worth being more explicit as to exactly what circumstances a
> null static key can be used in accordance with "9.1. Dummy static public
> keys".  Can every handshake pattern involving static keys use them

Well, if you encrypt to a null static public key with Noise_N, you're
obviously not getting any security.

So the effects of this are mostly straightforward, and the same as
just publishing your private key.  But maybe that could be explained
better, as well.

Trevor