Enforce the hash length in psa_sign_hash and psa_verify_hash #869

New issue

Open

opened 2026-08-12 08:38:49 -05:00 by gilles-peskine-arm · 0 comments

gilles-peskine-arm commented

2026-08-12 08:38:49 -05:00

(Migrated from github.com)

psa_sign_hash() and psa_verify_hash(), with a hash-then-sign algorithm, take an input which purports to be a hash of a certain type. It's impossible to verify that the hash input is actually a hash of the given type, but we should require that is has the expected length. This is a requirement in the PSA Crypto specification since version 1.1.

We currently don't check the length of the hash. This was reported by Steven Cooreman during the API design. Thanks to saikumar279 for reminding us that the issue is still present in TF-PSA-Crypto 1.2.0.

There is no direct security impact from not validating the length of the hash input. But it is not compliant, and it is error-prone. In particular, an application that calls psa_sign_hash() on arbitrary inputs may leak its private key (however this isn't as concerning as it might sound, because the leak can happen even if the inputs have the length of a hash).

Goal of this issue: in psa_sign_hash(), psa_verify_hash() and any other sign/verify-hash function (multipart, interruptible, …), if the algorithm is a hash-the-sign algorithm, enforce the expected length of the hash input. (For other signature algorithms, such as PSA_ALG_RSA_PKCS1V15_SIGN_RAW, there is no specific length to enforce.)

[`psa_sign_hash()`](https://arm-software.github.io/psa-api/crypto/1.1/api/ops/sign.html#c.psa_sign_hash) and [`psa_verify_hash()`](https://arm-software.github.io/psa-api/crypto/1.1/api/ops/sign.html#c.psa_verify_hash), with a hash-then-sign algorithm, take an input which purports to be a hash of a certain type. It's impossible to verify that the `hash` input is actually a hash of the given type, but we should require that is has the expected length. This is a requirement in the PSA Crypto specification since version 1.1. We currently don't check the length of the hash. This was [reported by Steven Cooreman](https://github.com/Mbed-TLS/mbedtls/issues/4213#issuecomment-795229785) during the API design. Thanks to saikumar279 for reminding us that the issue is still present in TF-PSA-Crypto 1.2.0. There is no direct security impact from not validating the length of the `hash` input. But it is not compliant, and it is error-prone. In particular, an application that calls `psa_sign_hash()` on arbitrary inputs may leak its private key (however this isn't as concerning as it might sound, because the leak can happen even if the inputs have the length of a hash). Goal of this issue: in `psa_sign_hash()`, `psa_verify_hash()` and any other sign/verify-hash function (multipart, interruptible, …), if the algorithm is a hash-the-sign algorithm, enforce the expected length of the `hash` input. (For other signature algorithms, such as `PSA_ALG_RSA_PKCS1V15_SIGN_RAW`, there is no specific length to enforce.)

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#869

No description provided.

Rows
Columns