-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
crypto/sha3: import from x/crypto #69982
Comments
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
I guess this is going to work: hmac.New(crypto.SHA3_256.New, make([]byte, 32)) |
Speaking of Lines 145 to 150 in 38f8596
At least it does not panic. I assume that this is fine, right? |
Yeah, I was just thinking about that, and indeed it doesn't really matter since they will be equivalent and they don't panic. Newer versions of x/crypto will simply not register the hash if running on Go 1.24 (and import crypto/sha3 which will register its version). |
Indeed, though it's worth noting that SHA-3 has its own MAC construction, KMAC, which should probably be preferred over HMAC-SHA3. So making the package slightly harder to use with crypto/hmac is not necessarily a bad thing. |
Change https://go.dev/cl/616717 mentions this issue: |
This proposal has been added to the active column of the proposals project |
For now just internally, pending a dedicated proposal for the exposed package API. In this CL the code is copied verbatim, for ease of review. Only the imports were replaced with the corresponding internal ones, and crypto.RegisterHash calls were disabled. Also, the 0.5MB keccakkats file was dropped, supplanted by TestCSHAKEAccumulated and ACVP tests. Updates #65269 Updates #69982 For #69536 Change-Id: Ia4735b50c99b9573a5c4889733c4a119930fe658 Reviewed-on: https://go-review.googlesource.com/c/go/+/616717 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
Packages are initialized in order by import path (constrained by the package DAG), so because As @FiloSottile pointed out, it shouldn't be a problem either way, but it's not non-deterministic. |
If this is an issue for FIPS, we could check the caller in RegisterHash and prefer the built-in sha3. It's ugly. |
I don't think it's a problem: we can just communicate "you need to use at least x/crypto@v0.X.0 for it to redirect calls to the FIPS module". After all, if an application uses cryptography from some other external module there's nothing we can do about it. |
Based on the discussion above, this proposal seems like a likely accept. The proposal details are in #69982 (comment) |
Chatting with @rsc we thought about renaming the SHAKE helpers to have a Sum prefix, so it doesn't look like the type returned by NewSHAKE128/256.
[Edited the issue body.] |
No change in consensus, so accepted. 🎉 The proposal details are in #69982 (comment) |
Change https://go.dev/cl/629176 mentions this issue: |
Change https://go.dev/cl/636255 mentions this issue: |
As part of #65269 (and for #69536), I propose we migrate golang.org/x/crypto/sha3 to the standard library, with the following API.
/cc @golang/security @cpu
Changes from golang.org/x/crypto/sha3
*SHA3
and*SHAKE
instead ofhash.Hash
andShakeHash
func() hash.Hash
without wrapping. Feels worth it to me, and maybe we can make a v2 one day with generics, but if anyone has ideas to smooth this over let me know.ShakeSum/n/(hash, data []byte)
withSumSHAKE/n/(data []byte, length int) []byte
[]byte
arguments. The new one matches more closelySum/n/
and can be made zero-allocations in most cases by outlining a fixed-size allocation of a reasonable length. We can also make the default recommendation "Just use SHAKE128 with a length of 32" and this would be the easiest to use API for that.Clone() ShakeHash
Shake
toSHAKE
to match standard spellingFor reference, here is the current x/crypto/sha3 API.
The text was updated successfully, but these errors were encountered: