SHA-3 (Keccak) support

[Neustradamus]

Dear team,

Can you add the SHA-3 support?

• https://keccak.team/
• https://keccak.team/software.html
• https://en.wikipedia.org/wiki/SHA-3

Thanks in advance.

[twiss]

Hello 👋 Apologies for the delay. Normally, the process for adding new algorithms is laid out in #280 (comment). That being said, there was an idea for creating a single spec with multiple new (more modern) algorithms for Web Crypto (e.g. Argon2 as well, see WICG/proposals#59 (comment)). I personally think adding SHA-3 would make a lot of sense. Perhaps cc @tniessen, @panva and @lucacasonato, do you still have plans for writing up something like that?

[tniessen]

do you still have plans for writing up something like that?

@twiss I want to write a spec that includes SHA-3, but it seems like Google/BoringSSL/Chrome might stand in the way because they might skip SHA-3. See also w3c/webappsec-subresource-integrity#11 and electron/electron#30530.

While SHA-256 and SHA-512 are still considered secure, the main point of SHA-3 is to have a drop-in replacement in case the SHA-2 family is broken. Of course, if we don't support SHA-3 before that happens, then NIST's idea does not work. (SHA-3 has other benefits, such as security against length extension attacks, but apparently those have not convinced BoringSSL.)

[twiss]

I see. Yeah, to be fair, at the time that the competition for SHA-3 was created, there was a lot more uncertainty about the long-term security of SHA-2 than there is today, given that previous hash functions had been toppling over in rather rapid succession, which didn't happen to SHA-2. And NIST hasn't specified "just in case" alternatives for the other primitives, like AES, so I don't think that's really their general philosophy.

The advantage to adding SHA-3 to Web Crypto may rather be to enable implementing protocols that use SHA-3 using Web Crypto, though I haven't looked too deeply into how widely it's used now.

But, I personally also think that adding things like Argon2, and perhaps OCB or ChachaPoly, which offer more concrete security improvements over the algorithms currently in Web Crypto, should take higher priority.

Though, I think creating a draft with a collection of modern alternatives to the algorithms in Web Crypto still makes sense, and then we can always later see what gets widely implemented and merge only those into Web Crypto proper.

[OR13]

Since SHA-3 is required in ML-KEM, this issue is now also in the critical path for support for post quantum kems or kem combiners that might rely on SHA-3...

https://mailarchive.ietf.org/arch/msg/cfrg/xl1G8yUz8NRKiLVY6Jk2IIk0lFc/

I think it might be nice to layout a desired timeline for some of these potential crypto upgrades, I might recommend the following:

HPKE -> PQKEMS -> KEM Combiners

afaik, in the context of encryption, you won't need SHA-3 until you need to support a PQKem that requires it.

In the context of PQ signatures (MS-DSA, SLH-DSA), you might end up needing SHA-3 support sooner.

[twiss]

Yeah. FWIW, I think it would also make sense to at some point add PQC algorithms to Web Crypto as well, though that's obviously a separate issue, and of course if SHA-3 is required for that it'd make sense to expose it separately as well, and might be a nice step towards that.

[seriousme]

FYI: A few days ago NIST standardized PQC
https://cloudsecurityalliance.org/blog/2024/08/15/nist-fips-203-204-and-205-finalized-an-important-step-towards-a-quantum-safe-future

Would be nice if these were added.

[twiss]

@seriousme Could you open a separate issue for that, please?

[seriousme]

New issue: #367

[twiss]

On the topic of SHA-3, here is a draft spec: https://twiss.github.io/webcrypto-modern-algos/#sha3.

[Neustradamus]

@twiss: Thanks for SHA-3 draft spec info :)

@seriousme: Thanks for the new ticket :)