Proposal Details
Go 1.24 added a crypto/sha3 module imported from x/crypto (see #69982). One of the changes in crypto/sha3 compared to x/crypto is missing NewLegacyKeccak256/NewLegacyKeccak512 functions that allowed to work with legacy padding. This is known and while x/crypto now forwards many standard SHA3 hashes to crypto/sha3, the algorithm implementation is still kept because it's needed for NewLegacyKeccak256/NewLegacyKeccak512 (see https://go-review.googlesource.com/c/crypto/+/681755).
From what I've checked, src/crypto/internal/fips140/sha3 module that contains actual implementations exposed to public via crypto/sha3 still uses code similar to x/crypto, it has dsbyte and appropriate constants for Keccak to work correctly, but it's not available to crypto/sha3 users.
The proposal is rather simple: add the same NewLegacyKeccak256/NewLegacyKeccak512 pair that x/crypto had to crypto/sha3. The implementation cost is about zero, the only question is why should anyone care about Keccak. And the rationale is rather simple to me: Ethereum (https://ethereum.org/). Not a small size project that uses old padding scheme for years and has to deal with it somehow. There are many more projects in blockchain space following Ethereum and just using the same algorithms, there are also projects that have to be compatible with Ethereum. If you're to check the list of current golang.org/x/crypto/sha3 users (https://pkg.go.dev/golang.org/x/crypto/sha3?tab=importedby), there is a lot of blockchain-related software and most of that software needs Keccak version of SHA3.
Eventually this would also allow to remove SHA3 implementation from x/crypto.
Comment From: gabyhelp
Related Issues
- x/crypto/sha3: add Keccak 512 support #29533 (closed)
- x/crypto/sha3: add Keccak 256 support #19709 (closed)
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)