[noise] generated go from noise-explorer uses deprecated point multiplication
nadim.kobeissi at outlook.com
Fri Aug 13 15:00:59 PDT 2021
Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone.
Sent from my iPhone
> On 13 Aug 2021, at 11:17 PM, Yawning Angel <yawning at schwanenlied.me> wrote:
>> On 8/13/21 8:38 PM, john at sys.casa wrote:
>> 1) should noise end its usage of the now deprecated x25519.ScalarMult
>> when auto-generating go implementations?
> See 11.1 and 12.1 of the Noise Protocol specification.
>> 3) the low-level api for operating across the ed25519 curve is another
>> solution here - is it worth pondering the tradeoffs in switching
>> entirely to this API? https://github.com/FiloSottile/edwards25519
> No. For several reasons.
> 1) Recent versions of `x/crypto/curve25519` already use that package (If
> people are wondering why your scalar multiply performance cratered
> recently after updating their import, this is why). See:
> 2) That package does not (on it's own) implement u-coordinate only
> "multiplication". Doing an Ed25519 scalar-point multiply and then
> converting to Montgomery u-coordinate will be slower than having a
> dedicated code path.
> 3) 32-bit performance is awful.
>> 1. Constant-time implementations for each curve operation used in IK.
> Huh? `x/crypto/curve25519` has always been constant time.
>> 2. Addresses some issues with the inconsistency between implementations
>> of curve/ed 25519. (read more:
> Nothing the noise protocol framework does, has anything to do with how
> Ed25519 verification has many divergent implementations. This is
> totally irrelevant in the context of noise.
>> 3. edwards25519 planned to merge with the internal ed25519 API in go1.17
> It's internal, and not accessible from normal code. You would need to
> import Filo's standalone version.
>> 4. Provides an array of useful extensions/operations for utilization
>> across curve 25519.
> I guess you could reuse the scalar and finite field implementations? It
> doesn't provide much else apart from a way to go from a twisted Edwards
> point to a u-coordinate...
>> 1. Fairly significant API change
> If you mean, use the raw field element library, and implement the
> multiplications that you need by hand, then sure. If you just want to
> use the library for the sake of using it, then bumping your import does
> so, without any changes.
> Don't get me wrong, I like the edwards25519 library, and I've used it
> for other things. But as far as Noise is concerned, there isn't really
> a decision to be made here. If the library uses recent
> `x/crypto/curve25519` then it will be used, if not, it won't.
> Yawning Angel
> : Off-topic, if people need to solve the Ed25519 verification
> behavior issue in, ed25519consensus (implements ZIP-215) and
> curve25519-voi (implements several variants) exist to solve this.
> Really, "Just use Ristretto" though.
> Noise mailing list
> Noise at moderncrypto.org
More information about the Noise