[noise] Notes and thoughts from RWC2017

[Jason A. Donenfeld]

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.

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.

I don't know specifics about secp256k1, but I do know that the older
NIST-era curves sometimes to dangerous things when passed points not
strictly on the curve. I wonder if this poses an issue for this
particular noise user.

In any case, if it is an issue, I imagine the most to do on the noise
spec side would be to add a note about this as a security
consideration, and perhaps inform the lightening people.