tink
tink copied to clipboard
tink-crypto
Plans for Curve25519/X25519/Field25519
Any plans to make Curve25519/X25519/Field25519 ready for production?
The code seem to be pretty stable at this point. Is there anything we can do to help move the process along?
I work for a company called UniKey and we leverage Curve25519 and Ed25519 in our products. Specifically: generating Curve25519 public and private keys, Ed25519 public and private keys, computing Curve25519 shared secrets, and Ed25519 signing and verification.
These classes are marked @Alpha and they're located under the subtle package. The user guide has explicit warnings about using classes that meet either of these conditions so I'm wondering if there are known issues with the implementations that are keeping these classes from being ready for a production environment.
Some extra info that may or may not be helpful:
Out of an abundance of caution and not knowing if there's anything wrong with the implementations, I generated 10 million shared secrets from random public and private keys using PyNaCl. I pumped the same set of inputs into X25519.computeSharedSecret(privateKey, publicKey); and all 10 million matched what PyNaCl produced.
Thanks Luis.
We haven't found an application where we need Curve25519, but we're thinking about adding it as a KEM for Hybrid Encryption.
Although it's @Alpha and in subtle, we think it's not in bad quality.
Luis, are you using Curve25519 in a hybrid encryption scheme? Or are you using it in key exchange protocols?
Yes we are using it in a hybrid encryption scheme. We use Curve25519 to derive shared secrets that are used in AES-128-cbc encryption.
We're going to support X25519 with XChaCha20Poly1305 in our hybrid encryption. C++ first, Java may need some love from a contributor.
Java may need some love from a contributor.
What needs to be done actually? would testing by comparing output with another library such as https://github.com/signalapp/curve25519-java for example (by using same parameters if applicable) be sufficient?
We use Curve25519 to derive shared secrets that are used in AES-128-cbc encryption.
🤔 Strange, a non alpha feature is based on an alpha feature.... ??
Ah maybe I have found the trick in the documentation:
This class only implements point arithmetic, if you want to use the ECDH Curve25519 function, please checkout {@link com.google.crypto.tink.subtle.X25519}
This is pretty self explanatory
For a use currently internal to Google I think I'd need a key type for Curve25519 keys to compute shared secrets using X25519. What would the process be to define a new key type (both public and private key, with 32 byte arrays for the key values) for use with X25519 and to define a new mechanism to derive shared secrets from two keys? (Which does not seem to exist as a primitive operation yet?)
How about support ed25519 key to curve25519 like https://doc.libsodium.org/advanced/ed25519-curve25519
This is in subtle. As such, it anyhow should not be used by users directly, even if it was not marked as Alpha. I will close this.
This is in subtle. As such, it anyhow should not be used by users directly, even if it was not marked as Alpha. I will close this.
To be frank, this is not what this issue asked for.
To be frank, this is not what this issue asked for.
Sorry for closing it, in this case. But then I don't understand what the issue asks for: I assumed the request is for users to use the classes Curve25519/X25519/Field25519 directly.