Switch from SHAKE-256 to SHA-256

[dlongley]

I recommend we switch to using the SHA-256-based BBS ciphersuite over the SHAKE-256. SHA-256 implementations are much easier to come by (this also includes the HMAC portion) so this will lower the burden for implementers significantly. It could potentially lower the amount of code that needs to be delivered in Web applications as well, due to the Web Crypto API supporting SHA-256 (but not SHAKE-256).

[dlongley]

I'll note that it doesn't seem you can do SHAKE-256 HMAC in openssl (or in other environments that depend on it like node.js): https://github.com/nodejs/node/blob/v20.11.0/deps/openssl/openssl/doc/man3/HMAC.pod#description

There doesn't seem to be an HMAC shake* algorithm in the JOSE IANA registry either: https://www.iana.org/assignments/jose/jose.xhtml

I think we should prefer SHA-256 for this version and if SHAKE-256 gets better uptake generally a new cryptosuite that supports in the future could be introduced.

[Wind4Greg]

Hi all (@dlongley, @msporny) this was discussed in issue https://github.com/w3c/vc-di-bbs/issues/93 where I polled folks concerning SHA-256 versus SHAKE-256. At the time @dlongley preferred SHA-256 since it has wider implementations in libraries, and @msporny preferred SHAKE-256. The thoughts with IETF/DIF BBS was that SHAKE-256 was more modern and the way forward. Though the IETF BBS Signature Scheme supports both flavors via a parameter.

I don't think SHAKE-256 implementations are very large compared to the size of a BLS12-381 curve (with pairing) implementation so I'm not sure about compatibility arguments with libraries and software that don't already support BLS12-381 (WebCrypto, SSL don't support BLS12-381). See @noble/hashes SHA3 implementation for sizing.

Since I change all the text from SHA-256 to SHAKE-256 (and test vectors) based on the previous poll and responses, can I get folks to respond one last time to which is preferred and why. Please let your friends know too, I don't want to have to switch everything again. Greg

[dlongley]

+1 to SHA-256 from me, reasons stated above.

Note that the decision impacts the HMAC as well -- which is separate from the BBS implementation being used. There will be some libraries that will happen to provide both, but a library that only provides BBS (and SHAKE-256) may require an implementer to implement the HMAC part themselves. We'll also have to say more about the length of the HMAC output as a variable length hashing function isn't contemplated in the generalized HMAC interface (which is probably one reason that long established crypto libraries like openssl don't support them -- because they aren't perfect "drop-in" replacements for that interface).

[msporny]

+1 to SHA-256, since implementation support for SHAKE-256 is... shaky. :)

[Wind4Greg]

Okay, any other inputs? Otherwise this clears the way for SHA-256 throughout: (a) SHA-256 version of BBS (ciphersuite_id = "BBS_BLS12381G1_XMD:SHA-256_SSWURO", See https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html#section-7.2.2), (b) SHA-256 with standard HMAC for N-Quad shuffle, (c) implicit (default) SHA-256 used in RDF canonicalization algorithm.

If I don't hear any objections to returning to SHA-256 based hashing for everything then I will write up a PR tomorrow.

[ChristopherA]

We recently ran into a similar issue (we had chosen Blake3 hash over SHA256) but ultimately decided after initial implementation for a many reasons to return to SHA256 for our revised IETF draft.

Basically SHA256 isn’t broken, isn’t vulnerable to quantum computing, and has huge hardware support even on constrained devices. Other hash algorithms (SHA3, Shake, Blake, etc.) just don’t offer sufficient benefits. Worse, with emerging homomorphic mcp crypto, there are some new hash algorithms coming out that are highly efficient in cryptographic circuits. Likely when we retire SHA256 we will use one of these as it matures, and not SHA3, Shake, Blake, etc.

— Christopher Allen

[Wind4Greg]

Putting together PR for this and separately for several others issues. I will regenerate test vectors after those other PRs since they will also affect the values.

[dlongley]

This was my issue and it's been addressed now, closing.