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

[Olaoluwa Osuntokun]

Hi Y'all,

I've read bits of the archive of this mailing list, but never subscribed
until now when it was brought to to my attention that y'all were discussing
the new Noise variant we're using for Lightning. My name is Laolu Osuntokun,
I'm one of the co-authors of the Lightning Network specifications and the
lead developer for lnd[1].

I'm very pleased to see y'all like our specification as well as the key
rotation scheme I came up with. I'm the primary author of BOLT08, so I'll be
able to answer the discussion points that Trevor brought up further in the
thread.

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

Our choice of secp256k1 and SHA-256 are to better align ourselves with the
existing cryptographic software implementations in the Bitcoin space. There
exist some libraries highly optimized for the choice of curve parameters
such as libsecp256k1[2] (which is very widely used within the ecosystem)
that we're able to take advantage of by sticking with "bitcoin crypto".


Jason wrote:
> 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.

secp256k1 has a co-factor of 1, so I believe it isn't susceptible to small
sub-group attacks. We're also protected from invalid-curve attacks since we
use point compression everywhere within the protocol.

However, there may be other analogous attacks against the curve that I'm not
aware of.


Jason wrote:
> 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

Implicitly, we've gone with the "abort early" route. It isn't precisely
spelled out in the Lightning specification atm, but I'll remedy that with an
amendment.  My implementation (brontide) along with the other
implementations [3][4] will _reject_ a point not on the secp256k1 curve
during deserialization.  As implemented now, the invalid point will
essentially be rejected by the DH functions. Therefore, the spec currently
doesn't outline the usage of null points.


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

I lean towards option B myself as it defers curve specific point
handling/rejection to the DH functions themselves, maintaining
encapsulation.

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

I don't think we require the specification of a null value since we use
point-compression everywhere (thereby rejecting invalid points). However,
there may be some other benefits of doing so that I haven't thought of yet.


-- Laolu

1. https://github.com/lightningnetwork/lnd
2. https://github.com/bitcoin-core/secp256k1
3.
https://github.com/ACINQ/eclair/blob/wip-bolts/eclair-node/src/main/scala/fr/acinq/eclair/crypto/Noise.scala
4.
https://github.com/ElementsProject/lightning/blob/1e34e5344d31989ee3b27ce86887dc37c7b652fd/lightningd/handshake/handshake.c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170117/d80afb9d/attachment.html>