Add support for RSA sign/verify with raw PKCS #1 data without DigestInfo #10226
Comments
|
Are there any test vectors we can use to confirm functionality here? |
|
The best I have found for now are NIST test vectors for RSA signatures, part of their Cryptographic Algorithm Validation Program (CAVP). The RSA test vector files are linked from the "Test Vectors" section. The SigGen15_186-*.txt files contain the private exponent which makes it possible to create signatures in addition to verifying them. Unfortunately the vector files do not contain data for the intermediary steps. So the test code has perform the low-level message encoding according to section 9.2 in RFC 3447. (It is quite straightforward). I have also tried to find public test data for RSA-signatures of 36-byte TLS 1.1 MD5+SHA1 hash values, but so far without any luck. |
|
After spending considerable effort, I could not find any nice, public test vectors for the SSL/TLS 1.1 signature case (RSA-signed 36-bytes MD5+SHA1 hashes). As an alternative, I could create a test vector for this case, by running a TLS handshake trace with OpenSSL, documenting the steps so it can be reproduced by others. Would you have any use of a test vector created this way? Is there anything else I can help with to advance this feature request? |
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Oct 29, 2024
Commit 1e562de ("crypto: rsassa-pkcs1 - Migrate to sig_alg backend") enforced that rsassa-pkcs1 sign/verify operations specify a hash algorithm. That is necessary because per RFC 8017 sec 8.2, a hash algorithm identifier must be prepended to the hash before generating or verifying the signature ("Full Hash Prefix"). However the commit went too far in that it changed user space behavior: KEYCTL_PKEY_QUERY system calls now return -EINVAL unless they specify a hash algorithm. Intel Wireless Daemon (iwd) is one application issuing such system calls (for EAP-TLS). Closer analysis of the Embedded Linux Library (ell) used by iwd reveals that the problem runs even deeper: When iwd uses TLS 1.1 or earlier, it not only queries for keys, but performs sign/verify operations without specifying a hash algorithm. These legacy TLS versions concatenate an MD5 to a SHA-1 hash and omit the Full Hash Prefix: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls-suites.c#n97 TLS 1.1 was deprecated in 2021 by RFC 8996, but removal of support was inadvertent in this case. It probably should be coordinated with iwd maintainers first. So reinstate support for such legacy protocols by defaulting to hash algorithm "none" which uses an empty Full Hash Prefix. If it is later on decided to remove TLS 1.1 support but still allow KEYCTL_PKEY_QUERY without a hash algorithm, that can be achieved by reverting the present commit and replacing it with the following patch: https://lore.kernel.org/r/[email protected]/ It's worth noting that Python's cryptography library gained support for such legacy use cases very recently, so they do seem to still be a thing. The Python developers identified IKE version 1 as another protocol omitting the Full Hash Prefix: pyca/cryptography#10226 pyca/cryptography#5495 The author of those issues, Zoltan Kelemen, spent considerable effort searching for test vectors but only found one in a 2019 blog post by Kevin Jones. Add it to testmgr.h to verify correctness of this feature. Examination of wpa_supplicant as well as various IKE daemons (libreswan, strongswan, isakmpd, raccoon) has determined that none of them seems to use the kernel's Key Retention Service, so iwd is the only affected user space application known so far. Fixes: 1e562de ("crypto: rsassa-pkcs1 - Migrate to sig_alg backend") Reported-by: Klara Modin <[email protected]> Tested-by: Klara Modin <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Lukas Wunner <[email protected]>
herbertx
pushed a commit
to herbertx/cryptodev
that referenced
this issue
Nov 10, 2024
Commit 1e562de ("crypto: rsassa-pkcs1 - Migrate to sig_alg backend") enforced that rsassa-pkcs1 sign/verify operations specify a hash algorithm. That is necessary because per RFC 8017 sec 8.2, a hash algorithm identifier must be prepended to the hash before generating or verifying the signature ("Full Hash Prefix"). However the commit went too far in that it changed user space behavior: KEYCTL_PKEY_QUERY system calls now return -EINVAL unless they specify a hash algorithm. Intel Wireless Daemon (iwd) is one application issuing such system calls (for EAP-TLS). Closer analysis of the Embedded Linux Library (ell) used by iwd reveals that the problem runs even deeper: When iwd uses TLS 1.1 or earlier, it not only queries for keys, but performs sign/verify operations without specifying a hash algorithm. These legacy TLS versions concatenate an MD5 to a SHA-1 hash and omit the Full Hash Prefix: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls-suites.c#n97 TLS 1.1 was deprecated in 2021 by RFC 8996, but removal of support was inadvertent in this case. It probably should be coordinated with iwd maintainers first. So reinstate support for such legacy protocols by defaulting to hash algorithm "none" which uses an empty Full Hash Prefix. If it is later on decided to remove TLS 1.1 support but still allow KEYCTL_PKEY_QUERY without a hash algorithm, that can be achieved by reverting the present commit and replacing it with the following patch: https://lore.kernel.org/r/[email protected]/ It's worth noting that Python's cryptography library gained support for such legacy use cases very recently, so they do seem to still be a thing. The Python developers identified IKE version 1 as another protocol omitting the Full Hash Prefix: pyca/cryptography#10226 pyca/cryptography#5495 The author of those issues, Zoltan Kelemen, spent considerable effort searching for test vectors but only found one in a 2019 blog post by Kevin Jones. Add it to testmgr.h to verify correctness of this feature. Examination of wpa_supplicant as well as various IKE daemons (libreswan, strongswan, isakmpd, raccoon) has determined that none of them seems to use the kernel's Key Retention Service, so iwd is the only affected user space application known so far. Fixes: 1e562de ("crypto: rsassa-pkcs1 - Migrate to sig_alg backend") Reported-by: Klara Modin <[email protected]> Tested-by: Klara Modin <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are non-standard RSA signature formats where the PKCS #1-padded data is without DigestInfo. A few examples:
Some old Thawte and Verisign timestamp certificates.
Signed MD5/SHA1 hashes in TLS 1.1 or earlier (RFC 4346, section 4.7).
IKE version 1 signatures (RFC 2409, section 5.1).
By making it possible to support these formats the Cryptography library would be even more versatile and useful, broadening its user base.
The
RSAPublicKey.recover_data_from_signaturealready supports these type of non-standard formats. (See issue #5495).A straightfoward solution would be to extend the
RSAPrivateKey.signandRSAPublicKey.verifyAPIs to allowNonein the in thealgorithmparameter. This would also make these APIs symmetrical withRSAPublicKey.recover_data_from_signature, which acceptsNonefor the exact same purpose.The text was updated successfully, but these errors were encountered: