From 143ebcc1d60ba20c2fddcd475f3ac4f985405f2b Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Tue, 13 Dec 2022 20:30:10 +0100 Subject: [PATCH] PKCS#1v1.5 sign/verify uses hash metadata Signed-off-by: Gilles Peskine --- docs/architecture/psa-migration/md-cipher-dispatch.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/psa-migration/md-cipher-dispatch.md b/docs/architecture/psa-migration/md-cipher-dispatch.md index 9b13735692..dc043abc70 100644 --- a/docs/architecture/psa-migration/md-cipher-dispatch.md +++ b/docs/architecture/psa-migration/md-cipher-dispatch.md @@ -97,7 +97,7 @@ In this work, we want two things: We can classify code that implements or uses cryptographic mechanisms into several groups: * Software implementations of primitive cryptographic mechanisms. These are not expected to change. -* Software implementations of constructed cryptographic mechanisms (e.g. HMAC, CTR_DRBG, RSA (calling a hash for PSS/OAEP), …). These need to keep working whenever a legacy implementation of the auxiliary mechanism is available, even if a PSA implementation is also available. +* Software implementations of constructed cryptographic mechanisms (e.g. HMAC, CTR_DRBG, RSA (calling a hash for PSS/OAEP, and needing to know the hash length in PKCS1v1.5 sign/verify), …). These need to keep working whenever a legacy implementation of the auxiliary mechanism is available, regardless of whether a PSA implementation is also available. * Code implementing the PSA crypto interface. This is not expected to change, except perhaps to expose some internal functionality to overhauled glue code. * Code that's subject to `MBEDTLS_USE_PSA_CRYPTO`: `pk.h`, X.509, TLS (excluding TLS 1.3). * Code that always uses PSA for crypto: TLS 1.3, LMS.