[noise] generated go from noise-explorer uses deprecated point multiplication
nadim.kobeissi at outlook.com
Sat Aug 14 00:23:48 PDT 2021
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.” 
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.  It would be good if Filippo (who `git blame` indicates is responsible for this deprecation in 2019 ) 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,
Sent from my computer
> 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
> Yawning Angel
> Noise mailing list
> Noise at moderncrypto.org
More information about the Noise