You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been dragging our feet on a curve25519 implementation. At Pull Request 566 we added test code to allow us to cross-validate a real implementation, but we never provided the real implementation. The real implementation was delayed for various reasons, but one of the bigger ones was the algorithms based on the curve are hard to fit into the library the way we want it to fit.
It also looks like the IETF has provided enough information/RFCs to roll an implementation and actually interop with other libraries and software.
This is the next step in getting proper curve25519 support into the library. It provides the near-constant time curve operations optimized for 32-bit and 64-bit platforms.
The text was updated successfully, but these errors were encountered:
We also clamp the private key and recalculate the public key. Note: we already know some IETF keys fail to validate because they are not clamped as specified in Bernsteain's paper or the RFCs (derp....)
We have been dragging our feet on a curve25519 implementation. At Pull Request 566 we added test code to allow us to cross-validate a real implementation, but we never provided the real implementation. The real implementation was delayed for various reasons, but one of the bigger ones was the algorithms based on the curve are hard to fit into the library the way we want it to fit.
It also looks like the IETF has provided enough information/RFCs to roll an implementation and actually interop with other libraries and software.
This is the next step in getting proper curve25519 support into the library. It provides the near-constant time curve operations optimized for 32-bit and 64-bit platforms.
The text was updated successfully, but these errors were encountered: