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

[Filippo Valsorda]

_o/

We don't remove deprecated APIs. x/crypto follows the Go 1 Compatibility Promise. See https://golang.org/wiki/Deprecated.

Indeed, this deprecation is due mostly to contributory behavior. The X25519 APIs have been discussed at length, so I won't rehash the debate, but I'll mention that there were real-world security vulnerabilities due to the old API behavior. Note that the Noise spec has the equivalent of a MAY for checking low order points:

> Alternatively, implementations are allowed to detect inputs that produce an all-zeros output and signal an error instead. This behavior is discouraged because it adds complexity and implementation variance, and does not improve security. This behavior is allowed because it might match the behavior of some software.
> https://noiseprotocol.org/noise.html#the-25519-dh-functions

The new API also uses slices, which is generally more ergonomic, saves copies of secret material, and most importantly avoids silently copying a short buffer into a fixed size array.

All in all, a Noise implementation is probably going to be fine with either.

2021-08-14 09:23 GMT+02:00 Nadim Kobeissi <nadim.kobeissi at outlook.com>:
> Hello everyone,
> 
> I’ve looked through the exchange between John and Yawning and I understand the issue better now.
> 
> A look at ScalarMult indicates that Yawning is correct: its deprecation has to do entirely with ensuring “contributory behavior” to mitigate for low-order points. To quote: "Deprecated: when provided a low-order point, ScalarMult will set dst to all zeroes, irrespective of the scalar. Instead, use the X25519 function, which will return an error.” [1]
> 
> I agree with Yawning that if this is the only reason for the deprecation of ScalarMult, then no change should be made to the current Go-generated Noise Explorer code. This is for two reasons:
> 1. RFC 7748 marks the low-order point check as optional.
> 2. Trevor has repeatedly expressed his opinion which seems to oppose APIs which return errors on low-order points. So this should be Trevor’s call and not mine.
> 
> However there is still one important concern. The common definition of “deprecation” in the context of software engineering seems to include the possibility that the deprecated functionality will be removed entirely in future software updates. [2] It would be good if Filippo (who `git blame` indicates is responsible for this deprecation in 2019 [3]) could shed light on whether ScalarMult is scheduled for removal in the future. In that case, there would need to be some alternative code to the Go crypto API such that the low-order point check could be bypassed in order to keep with the current targeted behavior for Noise Handshake Pattern implementations. Or, alternatively, Trevor would validate that low-order point checks are not anathema to the intended behavior of Noise Handshake Pattern implementations.
> 
> Have a good week-end,
> 
> Nadim
> Sent from my computer
> 
> References:
> [1] https://github.com/golang/crypto/blob/master/curve25519/curve25519.go#L19-L21
> [2] https://docs.oracle.com/javase/8/docs/technotes/guides/javadoc/deprecation/index.html
> [3] https://github.com/golang/crypto/commit/f4817d981bb690635456c5c1c6aa0585e5d45891
> 
> > On 14 Aug 2021, at 12:34 AM, Yawning Angel <yawning at schwanenlied.me> wrote:
> > 
> > On 8/13/21 10:00 PM, Nadim Kobeissi wrote:
> >> Noise Explorer author here. I’ll take a close look at this tomorrow. Thanks for your patience everyone.
> > There really isn't much to look at.  The new API is more ergonomic, but
> > forces contributory behavior by checking if the output is a low-order
> > point, and spits out an error.  RFC 7748 has this check as a MAY.  The
> > noise spec prefers not having the check (which is what the deprecated
> > API does).
> > 
> > As an aside, I misspoke about the parts of the spec, dummy psks don't
> > have anything to do with this,  Sorry it's been a while since I've
> > thought about this.  I seem to vaguely recall years ago, some explicit
> > use case that involved sending the neutral element, but I might just be
> > confused.
> > 
> > Regards,
> > 
> > -- 
> > Yawning Angel
> > 
> > _______________________________________________
> > Noise mailing list
> > Noise at moderncrypto.org
> > https://moderncrypto.org/mailman/listinfo/noise
> 
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20210814/529fb5cb/attachment.htm>