Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: x/crypto/curve25519: new X25519 API #32670
The names are the same as the
The main issue with the current API is that there is no way to return an error from
See #31846 and the linked paper, where it was only the Go implementations that were actually exploitable, due to our lack of safety checks, which is the opposite of what we want to achieve.
The implementation of
There is a split in Go crypto APIs between slices (like
So while type safety is nice, the failure mode of arrays in practice is worse. Slices cause an error at runtime, but if the code is ever tested, that condition should be caught more easily than the example above.
Should we have
Does this function always allocate, or will inliner and escape analysis be able to figure out that if the return value is quickly disposed of it can live on the stack?
Should we deprecate the unsafe
Adding an error
This package lives in curve25519, so we could add an error return value to
The problem is indeed that it would probably go unnoticed for existing code.
Adding a check function
The unsafe inputs generate recognizable results, so we could add a
This is the opposite of secure by default.
Replacing only ScalarMult
We could just deprecate
I could honestly not think of a good name, and it seemed like a good opportunity to switch to slices and the naming of the RFC.
Discussed with @rsc, comments inline.
This wouldn't be very useful, as unnamed types and equivalent named types don't conflict.
It should be possible to write it such that it does not allocate. Will write an experiment and a test.
Deprecation for ScalarMult, just a note for ScalarBaseMult.
Perhaps you need to say
referenced this issue
Jun 28, 2019
The inliner trick is working. For example in the following code, the