1342546 - Implement SHA-3

Status: REOPENED

(NSS :: Libraries, enhancement, P5)

Description

[J.C. Jones [:jcj] (he/they)]

This is a meta-mug to track the implementation of SHA-3, standardized by NIST in 2015.

Firefox SHA-3 family of hash functions OIDs are defined at CSOR [1] as:

  id-rsassa-pkcs1-v1_5-with-sha3-256 ::= { sigAlgs 14 }
  id-rsassa-pkcs1-v1_5-with-sha3-384 ::= { sigAlgs 15 }
  id-rsassa-pkcs1-v1_5-with-sha3-512 ::= { sigAlgs 16 }

  id-ecdsa-with-sha3-256 ::= { sigAlgs 10 }
  id-ecdsa-with-sha3-384 ::= { sigAlgs 11 }
  id-ecdsa-with-sha3-512 ::= { sigAlgs 12 }

There is a staring point implementation by Richard Barnes, Bob Relyea, and Martin Thomson here: https://github.com/martinthomson/sha3

[1] http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html

Comment 1

[sjw]

WolfSSL supports it since 3.12.0:
https://www.wolfssl.com/wolfssl-3-12-0-now-available/
https://github.com/wolfSSL/wolfssl/pull/937

mbedtls is working on it:
https://github.com/ARMmbed/mbedtls/pull/479

OpenSSL will support it in the next major release:
https://github.com/openssl/openssl/issues/439

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:kjacobs, maybe it's time to close this bug?

Comment 3

[Hubert Kario]

OpenSSL also can use SHA-3 in PKCS#12 files, both for MAC (since 1.1.1) and for PRF in PBKDF2 (also since 1.1.1 but the API is quite clunky, better support should happen in a release after 3.0.0).

Example generated files are in https://github.com/redhat-qe-security/keyfile-corpus

Comment 4

[Benjamin Beurdouche [:beurdouche]]

Hubert, does RedHat need this for something?
Otherwise, since we already have code for this in HACL*, I can add it to our backlog for later.

Comment 5

[Hubert Kario]

No, it isn't needed for anything in particular. Just providing information for completeness sake.
(creating file with SHA-3 MAC with OpenSSL is actually quite easy, you just need to specify -macalg sha3-256 to openssl pkcs12, so technically users can create files like this, but if any of our customers encounter them we can always tell them to use openssl to re-encrypt with a MAC supported by NSS)

Comment 6

[Simon Friedberger (:simonf)]

It would be helpful if we could migrate this HACL* code over. We need something indistinguishable from a RO for DAP and the natural choice would be SHAKE.
What would be the required steps and effort?

Comment 7

[Simon Friedberger (:simonf)]

I've discussed this with ekr, please add support for SHA-3.

Comment 8

[Anna Weine]

Many thanks to John Schanck for adding SHA3.

Comment 9

[Alexey Chernyak]

Reopening as this was only partially implemented by Bug 1753026 implementation of some of the SHA-3 family primitives.

The reporter requested implementation of the RSA and ECDSA digital signatures using SHA-3 family of hash functions.

Currently NSS secoidt.h has defined:

• less than half of the CSOR registered SHA-3 family hash OIDs,
• All of the CSOR registered SHA-3 family HMAC OIDs, and
• None of the DSA, RSA or ECDSA CSOR registered SHA-3 family digital signature OIDs requested by the reporter.

As mentioned by Simon in Comment #6, apart from the 4 SHA-3 hash algorithms the SHA-3 family does also include the 2 SHAKE hash algorithms.

The 2 SHAKE algorithms have been standardised in 2019 by IETF as part of PKIX under the RFC 8692.

Without these implemented, when Firefox currently encounters a website with an OpenSSL generated certificate signed using ecdsa_with_SHA3-384 algorithm, it fails with SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED "The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure" error because the NSS sec_DecodeSigAlg and CERT_VerifySignedDataWithPublicKey functions don't recognise the signature algorithm.

With SHA-3 primitives already implemented by Bug 1753026, I'm guessing implementing SHA-3 digital signatures and certificate validation support should be easier?