<div dir="ltr"><div>Hi Y'all, </div><div><br></div><div>I've read bits of the archive of this mailing list, but never subscribed</div><div>until now when it was brought to to my attention that y'all were discussing</div><div>the new Noise variant we're using for Lightning. My name is Laolu Osuntokun,</div><div>I'm one of the co-authors of the Lightning Network specifications and the</div><div>lead developer for lnd[1].</div><div><br></div><div>I'm very pleased to see y'all like our specification as well as the key</div><div>rotation scheme I came up with. I'm the primary author of BOLT08, so I'll be</div><div>able to answer the discussion points that Trevor brought up further in the</div><div>thread.</div><div><br></div><div><div>Jason wrote:</div></div><div>> I'd suggest not adding this old curve the specification...</div><div><br></div><div>Our choice of secp256k1 and SHA-256 are to better align ourselves with the</div><div>existing cryptographic software implementations in the Bitcoin space. There</div><div>exist some libraries highly optimized for the choice of curve parameters</div><div>such as libsecp256k1[2] (which is very widely used within the ecosystem)</div><div>that we're able to take advantage of by sticking with "bitcoin crypto".</div><div><br></div><div><br></div><div>Jason wrote:</div><div>> I don't know specifics about secp256k1, but I do know that the older</div><div>> NIST-era curves sometimes to dangerous things when passed points not</div><div>> strictly on the curve.</div><div><br></div><div>secp256k1 has a co-factor of 1, so I believe it isn't susceptible to small</div><div>sub-group attacks. We're also protected from invalid-curve attacks since we</div><div>use point compression everywhere within the protocol.</div><div><br></div><div>However, there may be other analogous attacks against the curve that I'm not</div><div>aware of.</div><div><br></div><div><br></div><div>Jason wrote: </div><div>> so we decided that it was up to the implementer as to what to do</div><div>> in this case -- keep processing, so that the whole noise handshake</div><div>> message would receive constant time treatment, or abort early, so as</div><div>> to not waste cycles</div><div><br></div><div>Implicitly, we've gone with the "abort early" route. It isn't precisely</div><div>spelled out in the Lightning specification atm, but I'll remedy that with an</div><div>amendment.  My implementation (brontide) along with the other</div><div>implementations [3][4] will _reject_ a point not on the secp256k1 curve</div><div>during deserialization.  As implemented now, the invalid point will</div><div>essentially be rejected by the DH functions. Therefore, the spec currently</div><div>doesn't outline the usage of null points.</div><div><br></div><div><br></div><div>Trevor wrote:</div><div>> So we should consider the above spec language in light of this, and</div><div>> perhaps either:</div><div><br></div><div>I lean towards option B myself as it defers curve specific point</div><div>handling/rejection to the DH functions themselves, maintaining encapsulation.</div><div><br></div><div>> And also discuss whether they'd want to specify a null value for</div><div>> secp256k1.</div><div><br></div><div>I don't think we require the specification of a null value since we use</div><div>point-compression everywhere (thereby rejecting invalid points). However,</div><div>there may be some other benefits of doing so that I haven't thought of yet.</div><div><br></div><div><br></div><div>-- Laolu</div><div><br></div><div>1. <a href="https://github.com/lightningnetwork/lnd">https://github.com/lightningnetwork/lnd</a></div><div>2. <a href="https://github.com/bitcoin-core/secp256k1">https://github.com/bitcoin-core/secp256k1</a></div><div>3. <a href="https://github.com/ACINQ/eclair/blob/wip-bolts/eclair-node/src/main/scala/fr/acinq/eclair/crypto/Noise.scala">https://github.com/ACINQ/eclair/blob/wip-bolts/eclair-node/src/main/scala/fr/acinq/eclair/crypto/Noise.scala</a></div><div>4. <a href="https://github.com/ElementsProject/lightning/blob/1e34e5344d31989ee3b27ce86887dc37c7b652fd/lightningd/handshake/handshake.c">https://github.com/ElementsProject/lightning/blob/1e34e5344d31989ee3b27ce86887dc37c7b652fd/lightningd/handshake/handshake.c</a></div></div>