[noise] secp256k1 (was Re: Notes and thoughts from RWC2017)

[Trevor Perrin]

On Mon, Jan 16, 2017 at 1:16 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Mon, Jan 16, 2017 at 6:53 AM, Trevor Perrin <trevp at trevp.net> wrote:
>> They're doing Noise_XK_secp256k1_ChaChaPoly_SHA256, so this introduces
>> a new pattern and a new curve into use.

[Jason wrote]:
> I'd suggest not adding this old curve the specification...

I agree that we have a good small set of recommendations in core spec,
and should be reluctant to change that.

However we might want a registry of additional names people have used
(e.g. NewHope, secp256k1), somewhere.


> One thing we discussed a while ago with 25519 is what happens handling
> degenerate points, and the span of valid byte strings. IIRC, it turned
> out that good implementations returned an all zero string in constant
> time, so we decided that it was up to the implementer as to what to do
> in this case -- keep processing, so that the whole noise handshake
> message would receive constant time treatment, or abort early, so as
> to not waste cycles. Due to the zero string output, both strategies
> were considered fine, with one caveat about implementation
> fingerprinting.

Slightly different - from section 4.1:

"""
If the function detects an invalid public_key, the output may be all
zeros or any other value that doesn't leak information about the
private key. For reasons discussed in Section 9.1 it is recommended
for the function to have a null public key value that always yields
the same output, regardless of private key. For example, the DH
functions in Section 10 always map a DH public key of all zeros to an
output of all zeros.
"""

This works well for (and was designed around) 25519 and 448.

But secp256k1 is different - it uses point compression and rejects
invalid points (and the Lightning code does this correctly, AFAICT).
It also doesn't support a null value.

These are reasonable choices, and other curves like FourQ, NIST
P-256/P-384, or Decaf versions of 25519/448, might be more similar to
this than to 25519/448.

So we should consider the above spec language in light of this, and
perhaps either:

 (A) Strengthen the language around returning all zeros for invalid
public keys (instead of rejecting)

 (B) Allow DH functions to mandate rejection of invalid public keys

And also discuss whether they'd want to specify a null value for secp256k1.

I'm not sure if we have any Lightning Network people on this list, but
we should get their input.


Trevor