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

[Nadim Kobeissi]

Ah, I had indeed forgotten about the Go 1 Compatibility Promise and it’s good to see Go’s own deprecation policy page, which is a more relevant reference than the random other one from another programming language that I found on Google Search.

Thanks for this clarification; this likely settles the issue (at least until Go 2: Attack of the Gopher).

Nadim
Sent from my iPad

On 14 Aug 2021, at 11:36 AM, Filippo Valsorda <filippo at ml.filippo.io> wrote:


_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<mailto: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<mailto: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<mailto:Noise at moderncrypto.org>
> https://moderncrypto.org/mailman/listinfo/noise

_______________________________________________
Noise mailing list
Noise at moderncrypto.org<mailto: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/5559cae9/attachment.htm>