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
x/crypto/nacl: add support for sign #24350
Comments
/cc @FiloSottile |
Agreed that NaCl is probably not going to add support for Ed25519. Now that the RFC is published, and we have Ed25519 in x/crypto, adding a small wrapper around it would be fine. One thing to keep in mind is that the RFC defines the signatures to be non-malleable by requiring s to be minimal. We might want to standardise on that if things like libsodium have. |
I took a look at the libsodium signature checking code regarding the non-malleability question. It looks like it does check for non-malleability by default. I'll document the details here so you can double check. The call chain looks like this crypto_sign_open() -> crypto_sign_ed25519_open() -> crypto_sign_ed25519_verify_detached() -> sc25519_is_canonical() That last call only happens if ED25519_COMPAT is not defined. sc25519_is_canonical() does the 0<=S<l check described in RFC8032 , at least it looks like that to me (someone double check those two lines in the do-while loop please) and is mostly identical the code introduced in jedisct1/libsodium@62911ed. So it looks like libsodium does conform to the RFC. What does |
Change https://golang.org/cl/100436 mentions this issue: |
I think |
Great. That makes nacl/sign fairly trivial. I have the code and tests, which I'll send as soon as the CL is merged. |
https://tools.ietf.org/html/rfc8032#section-5.1.7 requires that s be in the range [0, order) in order to prevent signature malleability. This is a new requirement in the RFC so the ed25519 package predates it. This change aligns the code with the RFC. The linked bug says that libsodium is also enforcing this check by default. See golang/go#24350 Change-Id: Ib69ce7c9e5a58971cbe225318d9fd87660bd5e4b Reviewed-on: https://go-review.googlesource.com/100436 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change https://golang.org/cl/100578 mentions this issue: |
https://tools.ietf.org/html/rfc8032#section-5.1.7 requires that s be in the range [0, order) in order to prevent signature malleability. This is a new requirement in the RFC so the ed25519 package predates it. This change aligns the code with the RFC. The linked bug says that libsodium is also enforcing this check by default. See golang/go#24350 Change-Id: Ib69ce7c9e5a58971cbe225318d9fd87660bd5e4b Reviewed-on: https://go-review.googlesource.com/100436 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds the equivalents of crypto_sign, crypto_sign_open and crypto_sign_keypair in TweetNaCl and libsodium using the Ed25519 system. The original NaCl codebase does not contain functions with identical semantics but its documentation stated the intent of using Ed25519 in future releases. Fixes golang/go#24350 Change-Id: I4c3c86b4875f2f718ad9299c2274b4ad9e11fbeb Reviewed-on: https://go-review.googlesource.com/100578 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
This change adds the equivalents of crypto_sign, crypto_sign_open and crypto_sign_keypair in TweetNaCl and libsodium using the Ed25519 system. The original NaCl codebase does not contain functions with identical semantics but its documentation stated the intent of using Ed25519 in future releases. Fixes golang/go#24350 Change-Id: I4c3c86b4875f2f718ad9299c2274b4ad9e11fbeb Reviewed-on: https://go-review.googlesource.com/100578 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
This change adds the equivalents of crypto_sign, crypto_sign_open and crypto_sign_keypair in TweetNaCl and libsodium using the Ed25519 system. The original NaCl codebase does not contain functions with identical semantics but its documentation stated the intent of using Ed25519 in future releases. Fixes golang/go#24350 Change-Id: I4c3c86b4875f2f718ad9299c2274b4ad9e11fbeb Reviewed-on: https://go-review.googlesource.com/100578 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
This change adds the equivalents of crypto_sign, crypto_sign_open and crypto_sign_keypair in TweetNaCl and libsodium using the Ed25519 system. The original NaCl codebase does not contain functions with identical semantics but its documentation stated the intent of using Ed25519 in future releases. Fixes golang/go#24350 Change-Id: I4c3c86b4875f2f718ad9299c2274b4ad9e11fbeb Reviewed-on: https://go-review.googlesource.com/100578 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
This change adds the equivalents of crypto_sign, crypto_sign_open and crypto_sign_keypair in TweetNaCl and libsodium using the Ed25519 system. The original NaCl codebase does not contain functions with identical semantics but its documentation stated the intent of using Ed25519 in future releases. Fixes golang/go#24350 Change-Id: I4c3c86b4875f2f718ad9299c2274b4ad9e11fbeb Reviewed-on: https://go-review.googlesource.com/100578 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
cc @agl
There was a ticket for this 2 years ago (#15222).
The reasoning for not adding sign in the comments on that ticket was to wait for NaCl to add Ed25519 support. However, there hasn't been an update to the original codebase since 2011, while other implementations have added Ed25519 support.
I don't really understand the hesitation in adding Ed25519 sign, given that both TweetNaCl (by the original NaCl authors) as well as libsodium (which is by far the most popular implementation) and several other implementations do exactly that (to my understanding, but I'm not an expert).
Furthermore it seems like the existing Ed25519 implementation contains all the necessary pieces.
Given the popularity of the NaCl interface supporting all of the core functionality seems quite important. Could you comment on the situation? If you want to move forward with this I'm happy to contribute some code.
The text was updated successfully, but these errors were encountered: