search

Mbed-TLS / mbedtls

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.
https://www.trustedfirmware.org/projects/mbed-tls/
Other
5.08k stars 2.52k forks source link

Require a minimum hash length for ECDSA #4213

Open stevew817 opened 3 years ago

stevew817 commented 3 years ago

Description

Enhancement\Feature Request

Input-length validation on the hash input to psa_sign_hash / psa_verify_hash.

Justification - why does the library need this feature?
NIST FIPS 186-4 specifies the following (in the context of ECDSA):

A hash function that provides a lower security strength than the security strength associated with the bit length of n ordinarily should not be used, since this would reduce the security strength of the digital signature process to a level no greater than that provided by the hash function.

'Should not' is a strong recommendation, but not a requirement. However, since one of the goals of PSA Crypto is to reduce the possibility of mistakes, it would be good to have this check regardless. If a user really wants to sign a shorter hash, they can then explicitly zero-pad their hash up to the required length.

Suggested enhancement
Make the psa_sign_hash function validate the length of the hash to be signed, and refuse to sign hashes which are shorter than the bit size of the curve used by the signing algorithm.

stevew817 commented 3 years ago

And looking at the current implementation: if alg contains a specific hash algorithm, at the very minimum the hash input length should be matched to the expected length for the algorithm. That doesn't seem to happen today.

gilles-peskine-arm commented 3 years ago

I agree that it's part of the objective of the PSA crypto API to reduce the risk of misuse, and a bad combination of algorithms is indeed potential misuse. However, security strength is not a precise and unchanging concept, and enforcing specific numbers doesn't always make sense. Furthermore, NIST is very insistent on having evenly matched security strengths throughout, but this doesn't always make sense.

For NIST, the main reference for security strengths is SP 800-57, §5.6.1 “Comparable Algorithm Strengths” (as of SP 800-57 part 1 rev. 5). For hashes, the strength is simply half the hash size. For ECC, it's approximately half the curve size, but the details are a bit problematic. The strength of an ECC curve is based on the size f of the order n of the base point G, with thresholds.

For Curve25519, if I'm not mistaken, f = 253, which does not achieve the 128-bit strength that it is commonly considered to have. That doesn't concern ECDSA, but it shows that enforcing exact rules can be detrimental to functionality even though there is no security impact.

The NIST guideline forbids using a P521 key to sign a SHA-384 hash. TLS uses SHA-384 and not SHA-512 to hash handshakes, so a TLS endpoint with a P521 key cannot follow this recommendation. Also, an endpoint with a P384 key may talk with a peer that only advertises support for SHA-256 ciphersuites, and this would not be allowed by this recommendation either.

So I'm not convinced that we should enforce this specific recommendation.