New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support key generation from seed as described in RFC 8032 section 5.1.5 #64
Comments
I don't understand. There's getPublicKey? |
getPublicKey and getExtendedPublicKey |
Thank you, but I don't think "private key" (not "seed") is being exported. It looks like seed (which is named
In function "getExtendedPublicKey", I need Either:
For comparison with the Go package,
https://pkg.go.dev/crypto/ed25519 Edit: And another example from TweetNaCl Javascript: Where they are appending the public key to the private key (that's why it's 64 bytes). |
utils.getExtendedPublicKey is exported and described in readme in getPublicKey docs.
|
For anyone in the future sharing my confusion: What TweetNaCL , Go, and other packages call the "private key" is simply the seed concatenated with the public key. Also, NaCL used to return the the private key as the "secret scalar s" with the "prefix" (the second half of the digest of the seed). Instead of doing that most libraries simply regenerate both secrete scalar s and prefix from seed, and optionally cache public key. Thank you Paul for you work on this fantastic library. 👍 |
It's a shame they use 64-byte private keys:
|
Looking through the project, I did not see key generation from seed as describe in RFC 8032 section 5.1.5.
I would suggest ignoring the RFC's term "private key" and follow Go's term "seed". It makes the functions more readable while differentiating private key and seed.
Go's NewKeyFromSeed:
https://cs.opensource.google/go/go/+/refs/tags/go1.18.3:src/crypto/ed25519/ed25519.go;l=116
And Go's SetBytesWithClamping
https://cs.opensource.google/go/go/+/refs/tags/go1.18.3:src/crypto/internal/edwards25519/scalar.go;l=138;drc=7846e25418a087ca15122b88fc179405e26bf768;bpv=1;bpt=1
I would also point out Filippo's comment:
Edit: The JavaScript TweetNaCl also is doing this like the Go implementation except they've dubbed it "secretKey" whereas the Go library has dubbed it "private key" (with the public 32 byte component appended). The first 32 bytes of secretKey is the secret component.
https://github.com/dchest/tweetnacl-js#naclsignkeypairfromsecretkeysecretkey
The text was updated successfully, but these errors were encountered: