[noise] generated go from noise-explorer uses deprecated point multiplication

[Nadim Kobeissi]

Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone.

Nadim
Sent from my iPhone

> On 13 Aug 2021, at 11:17 PM, Yawning Angel <yawning at schwanenlied.me> wrote:
> 
> Hello,
> 
>> 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:
> https://github.com/golang/crypto/blob/0ba0e8f031222feafe2c6fe04ba9c3da11dd361a/curve25519/curve25519.go#L14
> 
> 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:
>> https://hdevalence.ca/blog/2020-10-04-its-25519am)
> 
> Nothing the noise protocol framework does, has anything to do with how
> Ed25519 verification has many divergent implementations[0].  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...
> 
> 
>> downsides
>> =========
>> 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.
> 
> Regards,
> 
> -- 
> Yawning Angel
> 
> [0]: 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
> https://moderncrypto.org/mailman/listinfo/noise