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

[Yawning Angel]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20210813/347cda12/attachment.sig>