Replace SHA-256 with SHA3-256

[roblesjoel]

Replace the usage of SHA-256 HMAC with SHA3-256 KMAC.

[msporny]

Replace the usage of SHA-256 HMAC with SHA3-256 KMAC.

Can you provide some insight into why you believe we should switch to SHA3-256 KMAC?

[dlongley]

I'll note that while some newer hash functions might bring additional benefits, overriding preferences are for implementation availability (particularly on the Web platform, where SHA-3 is not available) and wide spread use. It is because SHA-256 is widely deployed (significantly more so than SHA-3) and widely considered acceptable, and because the IETF BBS spec also uses SHA-256, that we're using SHA-256 HMAC.

It is still a good idea to document why the suggestion was made to use SHA3-256 KMAC (so please provide that information), but I would expect that only an unforeseen failure with SHA-256 would cause the group to come to consensus to move away from SHA-256 in this version of the spec.

[Wind4Greg]

Hi @roblesjoel are you suggesting changing to BBS ciphersuite_id: "BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_" from BBS Ciphersuite_ID: "BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_"? Or just in the shuffle map of section https://w3c.github.io/vc-di-bbs/#createshuffledidlabelmapfunction which uses an HMAC?

It should be noted that this was discussed in issue #93 and then again in issue #118. The reasoning was basically to promote the widest adoption and easiest path forward for developers. But please review the history.

Also note that we use the same hash function in multiple places: (a) inside the RDF canonicalization scheme, (b) bash proof hashing, (c) shuffle map of blank node ids, and (d) embedded in the BBS signature suite.

[roblesjoel]

Hey

So I completely worded that incorrectly, really sorry about that.
It should be "Add the option to use SHA3-256" and with that the option to use kmac instead of hmac.

There are 2 reasons for that:

1. SHA-256 is susceptible to a length extension attack
2. The BBS draft also offers the flavor SHAKE-256 as hash.
   So it would be nice if the draft could be updated with the information that both flavours would be possible.

@Wind4Greg Not change, but extend the draft to include the SHAKE-256 version, so implementers can choose what they want to use

[dlongley]

SHA-256 is susceptible to a length extension attack

It is not susceptible to length extension attacks when used in an HMAC construction:

HMAC also uses a different construction and so is not vulnerable to length extension attacks.[6]

[dlongley]

@roblesjoel,

Using SHAKE-256 was attempted earlier on and was dropped in favor of SHA-256 because of hash implementation availability and widespread adoption. Adding options isn't without cost (and would require multiple independent implementations). If SHA-256 is broken, there will be much bigger problems than with this cryptosuite (across the entire internet) -- and it is at that time that we'll be able to pivot and require SHAKE-256 instead of SHA-256 via a security-driven spec update (which the WG charter will allow).

[roblesjoel]

Understood, will close the issue, thank you for the answers :)