signature: Clamp PSS salt len to MD len #19724

neverpanic · 2022-11-21T11:11:16Z

FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection 5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of the hash function output block (in bytes)."

Switch the meaning of RSA_PSS_SALTLEN_AUTO to use at most the digest length, so that the default does not violate FIPS 186-4. Shorter values are still possible when long hashes are used with short keys.

Longer values can be created by using a specific value, or RSA_PSS_SALTLEN_MAX.

Checklist

documentation is added or updated
tests are added or updated (existing tests cover RSASSA-PSS and its salts)

t8m · 2022-11-21T12:33:47Z

The CI failure is relevant.

neverpanic · 2022-11-21T12:48:22Z

I'm not sure how to solve the failure with the old provider.

The issue here is that the provider computes the salt length independently from the routines that write the CMS, so while the signature generated by the old provider has a 222 bytes salt, the CMS will say it has a 32 byte salt. Any pointers on how to not compute the salt length twice (and thus incorrectly), and instead obtain it from the signature or the provider?

t8m · 2022-11-21T13:51:17Z

I am afraid this implies we cannot change this.

t8m · 2022-11-21T14:10:40Z

IMO the solution would be to use RSA_PSS_SALTLEN_DIGEST as the default or to invent another default value.

neverpanic · 2022-11-21T14:14:33Z

IMO the solution would be to use RSA_PSS_SALTLEN_DIGEST as the default or to invent another default value.

That will not work, because for some combinations of key length and digest (e.g. SHA-256 and RSA-512, or SHA-512 and RSA-1024) , RSA_PSS_SALTLEN_DIGEST is too long. Using a different value will also fail with the older providers.

However, I think it might be possible to obtain the correct value from the provider using OSSL_SIGNATURE_PARAM_ALGORITHM_ID instead of re-computing it in core, and I would even argue that's the way it should have been done in the first place. I'll give this a shot to see if it fixes the problem.

t8m · 2022-11-21T14:24:18Z

The problem is third party applications might depend on the value the same way as our CMS implementation did.

t8m · 2022-11-21T14:26:50Z

However, I think it might be possible to obtain the correct value from the provider using OSSL_SIGNATURE_PARAM_ALGORITHM_ID instead of re-computing it in core, and I would even argue that's the way it should have been done in the first place. I'll give this a shot to see if it fixes the problem.

It would fix the problem with the failing CI probably and yeah, it should have been done like that. However it won't solve the possible compatibility problem with 3rd party apps.

beldmit · 2022-11-21T14:29:15Z

@t8m as it's a FIPS requirement, we definitely need smth in this direction

t8m · 2022-11-21T14:29:58Z

Using a different value will also fail with the older providers.

The different default value would be a different default value inside the provider context - IMO that should work for new provider with new libcrypto. It would not work for combination of old libcrypto with new provider though because the value would be unknown to new libcrypto.

t8m · 2022-11-21T14:32:55Z

@t8m as it's a FIPS requirement, we definitely need smth in this direction

That something could be a sentence in the security policy.

neverpanic · 2022-11-21T14:35:51Z

That something could be a sentence in the security policy.

We're being told this is no longer enough. We can't wiggle our way out of this in the security policy, it either needs to be an explicit indicator (which we're going to ship downstream along with this change), or an implicit indicator (i.e., it must fail).

Breaking the few applications that were relying on the RSA_PSS_SALTLEN_AUTO being a specific value sounds like the lesser evil here.

beldmit · 2022-11-21T14:40:16Z

Putting an OTC hold on it to discuss it on regular meeting

slontis

Pretty sure we discussed this within OTC already when I added this. It was done this way in order to not break things.

neverpanic · 2022-11-24T13:25:56Z

I've changed this to introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and switch the CMS routines to determine the salt length from the provider's implementation. This preserves compatibility with older providers, while still supporting the new value.

t8m · 2022-11-24T13:31:06Z

crypto/rsa/rsa_ameth.c


    if (EVP_PKEY_CTX_get_signature_md(pkctx, &sigmd) <= 0)
        return NULL;
    if (EVP_PKEY_CTX_get_rsa_mgf1_md(pkctx, &mgf1md) <= 0)
        return NULL;
    if (EVP_PKEY_CTX_get_rsa_pss_saltlen(pkctx, &saltlen) <= 0)
        return NULL;
-    if (saltlen == -1) {
+    if (saltlen == RSA_PSS_SALTLEN_DIGEST || saltlen == RSA_PSS_SALTLEN_AUTO) {


Why is SALTLEN_AUTO here now and not equivalent to SALTLEN_MAX?

You're right, that's an oversight because I didn't review the diff against master again. I'll fix that.

t8m · 2022-11-24T13:37:19Z

providers/implementations/signature/rsa_sig.c

@@ -188,22 +188,36 @@ static void *rsa_newctx(void *provctx, const char *propq)
    prsactx->libctx = PROV_LIBCTX_OF(provctx);
    prsactx->flag_allow_md = 1;
    prsactx->propq = propq_copy;
-    /* Maximum for sign, auto for verify */
-    prsactx->saltlen = RSA_PSS_SALTLEN_AUTO;
+    /* Maximum until digest lnegth for sign, auto for verify */


up to digest length

t8m · 2022-11-24T13:38:29Z

providers/implementations/signature/rsa_sig.c

@@ -407,8 +421,8 @@ static int rsa_signverify_init(void *vprsactx, void *vrsa,

    prsactx->operation = operation;

-    /* Maximum for sign, auto for verify */
-    prsactx->saltlen = RSA_PSS_SALTLEN_AUTO;
+    /* Maximize until digest length for sign, auto for verify */


providers/implementations/signature/rsa_sig.c

crypto/rsa/rsa_pss.c

t8m · 2022-11-24T13:51:07Z

I think this will still break the Provider versions compat CI that is run on push as the libcrypto from 3.0.7 won't be able to cope with the changed default in the fips provider from master.

neverpanic · 2022-11-24T14:01:18Z

I think this will still break the Provider versions compat CI that is run on push as the libcrypto from 3.0.7 won't be able to cope with the changed default in the fips provider from master.

I think that can be fixed by cherry-picking Obtain PSS salt length from provider to 3.0. This duplicated computation should not have been done in this way in the first place, and to me it's a bug that core just assumes the PSS salt length will be computed in the same way in any provider.

t8m · 2022-11-24T14:04:00Z

I think that can be fixed by cherry-picking Obtain PSS salt length from provider to 3.0. This duplicated computation should not have been done in this way in the first place, and to me it's a bug that core just assumes the PSS salt length will be computed in the same in any provider.

I'd be OK with this solution. Still, it's better if we discuss it in OTC first.

neverpanic · 2022-11-28T10:37:07Z

For your information, I think the reason why NIST has this salt length limitation is this paragraph in PKCS #1 v2.1 on page 34 (emphasis mine):

Typical salt lengths in octets are hLen (the length of the output of the hash function Hash) and 0. In both cases the security of RSASSA-PSS can be closely related to the hardness of inverting RSAVP1. Bellare and Rogaway [4] give a tight lower bound for the security of the original RSA-PSS scheme, which corresponds roughly to the former case, while Coron [12] gives a lower bound for the related Full Domain Hashing scheme, which corresponds roughly to the latter case. In [13] Coron provides a general treatment with various salt lengths ranging from 0 to hLen; see [27] for discussion. See also [31], which adapts the security proofs in [4][13] to address the differences between the original and the present version of RSA-PSS as listed in Note 1 above.

[4] M. Bellare and P. Rogaway. The Exact Security of Digital Signatures – How to Sign with RSA and Rabin. In U. Maurer, editor, Advances in Cryptology – Eurocrypt ’96, volume 1070 of Lecture Notes in Computer Science, pp. 399 – 416. Springer Verlag, 1996.
[12] J.-S. Coron. On the Exact Security of Full Domain Hashing. In M. Bellare, editor, Advances in Cryptology – Crypto 2000, volume 1880 of Lecture Notes in Computer Science, pp. 229 – 235. Springer Verlag, 2000.
[13] J.-S. Coron. Optimal Security Proofs for PSS and Other Signature Schemes. In L. Knudsen, editor, Advances in Cryptology – Eurocrypt 2002, volume 2332 of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag, 2002.
[27] IEEE P1363 working group. IEEE P1363a D10: Standard Specifications for Public Key Cryptography: Additional Techniques. November 1, 2001. Available from http://grouper.ieee.org/groups/1363/.
[31] J. Jonsson. Security Proof for the RSA-PSS Signature Scheme (extended abstract). Second Open NESSIE Workshop. September 2001. Full version available from http://eprint.iacr.org/2001/053/.

mattcaswell · 2022-11-29T08:45:16Z

OTC: CMS code bug fix should be fixed in 3.0 and above, the default for salt length can be changed in 3.1 and above.

FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection 5.5 "PKCS openssl#1" says: "For RSASSA-PSS […] the length (in bytes) of the salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of the hash function output block (in bytes)." Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will not use more than the digest length when signing, so that FIPS 186-4 is not violated. This value has two advantages when compared with RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when verifying signatures for maximum compatibility, where RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will work for combinations where the maximum salt length is smaller than the digest size, which typically happens with large digest sizes (e.g., SHA-512) and small RSA keys. J.-S. Coron shows in "Optimal Security Proofs for PSS and Other Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332 of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag, 2002." that longer salts than the output size of modern hash functions do not increase security: "For example,for an application in which at most one billion signatures will be generated, k0 = 30 bits of random salt are actually sufficient to guarantee the same level of security as RSA, and taking a larger salt does not increase the security level." Signed-off-by: Clemens Lang <cllang@redhat.com>

neverpanic · 2022-12-06T19:24:58Z

CI failure in CIFuzz/Fuzzing seems unrelated to me.

t8m · 2022-12-07T08:21:21Z

@beldmit please reconfirm.

beldmit · 2022-12-07T08:31:53Z

Reconfirm.

openssl-machine · 2022-12-08T09:00:21Z

This pull request is ready to merge

Rather than computing the PSS salt length again in core using ossl_rsa_ctx_to_pss_string, which calls rsa_ctx_to_pss and computes the salt length, obtain it from the provider using the OSSL_SIGNATURE_PARAM_ALGORITHM_ID param to handle the case where the interpretation of the magic constants in the provider differs from that of OpenSSL core. Add tests that verify that the rsa_pss_saltlen:max, rsa_pss_saltlen:<integer> and rsa_pss_saltlen:digest options work and put the computed digest length into the CMS_ContentInfo struct when using CMS. Do not add a test for the salt length generated by a provider when no specific rsa_pss_saltlen option is defined, since that number could change between providers and provider versions, and we want to preserve compatibility with older providers. Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19724)

FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection 5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of the hash function output block (in bytes)." Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will not use more than the digest length when signing, so that FIPS 186-4 is not violated. This value has two advantages when compared with RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when verifying signatures for maximum compatibility, where RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will work for combinations where the maximum salt length is smaller than the digest size, which typically happens with large digest sizes (e.g., SHA-512) and small RSA keys. J.-S. Coron shows in "Optimal Security Proofs for PSS and Other Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332 of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag, 2002." that longer salts than the output size of modern hash functions do not increase security: "For example,for an application in which at most one billion signatures will be generated, k0 = 30 bits of random salt are actually sufficient to guarantee the same level of security as RSA, and taking a larger salt does not increase the security level." Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19724)

t8m · 2022-12-08T10:09:32Z

Merged to master branch. Unfortunately this does not cherry-pick cleanly to 3.1. @neverpanic Could you please create pull requests against 3.1 and 3.0 (CMS fix only) branches?

Rather than computing the PSS salt length again in core using ossl_rsa_ctx_to_pss_string, which calls rsa_ctx_to_pss and computes the salt length, obtain it from the provider using the OSSL_SIGNATURE_PARAM_ALGORITHM_ID param to handle the case where the interpretation of the magic constants in the provider differs from that of OpenSSL core. Add tests that verify that the rsa_pss_saltlen:max, rsa_pss_saltlen:<integer> and rsa_pss_saltlen:digest options work and put the computed digest length into the CMS_ContentInfo struct when using CMS. Do not add a test for the salt length generated by a provider when no specific rsa_pss_saltlen option is defined, since that number could change between providers and provider versions, and we want to preserve compatibility with older providers. Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#19724) (cherry picked from commit 5a3bbe1)

FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection 5.5 "PKCS openssl#1" says: "For RSASSA-PSS […] the length (in bytes) of the salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of the hash function output block (in bytes)." Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will not use more than the digest length when signing, so that FIPS 186-4 is not violated. This value has two advantages when compared with RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when verifying signatures for maximum compatibility, where RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will work for combinations where the maximum salt length is smaller than the digest size, which typically happens with large digest sizes (e.g., SHA-512) and small RSA keys. J.-S. Coron shows in "Optimal Security Proofs for PSS and Other Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332 of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag, 2002." that longer salts than the output size of modern hash functions do not increase security: "For example,for an application in which at most one billion signatures will be generated, k0 = 30 bits of random salt are actually sufficient to guarantee the same level of security as RSA, and taking a larger salt does not increase the security level." Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#19724) (cherry picked from commit 6c73ca4)

Rather than computing the PSS salt length again in core using ossl_rsa_ctx_to_pss_string, which calls rsa_ctx_to_pss and computes the salt length, obtain it from the provider using the OSSL_SIGNATURE_PARAM_ALGORITHM_ID param to handle the case where the interpretation of the magic constants in the provider differs from that of OpenSSL core. Add tests that verify that the rsa_pss_saltlen:max, rsa_pss_saltlen:<integer> and rsa_pss_saltlen:digest options work and put the computed digest length into the CMS_ContentInfo struct when using CMS. Do not add a test for the salt length generated by a provider when no specific rsa_pss_saltlen option is defined, since that number could change between providers and provider versions, and we want to preserve compatibility with older providers. Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#19724) (cherry picked from commit 5a3bbe1)

Rather than computing the PSS salt length again in core using ossl_rsa_ctx_to_pss_string, which calls rsa_ctx_to_pss and computes the salt length, obtain it from the provider using the OSSL_SIGNATURE_PARAM_ALGORITHM_ID param to handle the case where the interpretation of the magic constants in the provider differs from that of OpenSSL core. Add tests that verify that the rsa_pss_saltlen:max, rsa_pss_saltlen:<integer> and rsa_pss_saltlen:digest options work and put the computed digest length into the CMS_ContentInfo struct when using CMS. Do not add a test for the salt length generated by a provider when no specific rsa_pss_saltlen option is defined, since that number could change between providers and provider versions, and we want to preserve compatibility with older providers. Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#19724)

FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection 5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of the hash function output block (in bytes)." Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will not use more than the digest length when signing, so that FIPS 186-4 is not violated. This value has two advantages when compared with RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when verifying signatures for maximum compatibility, where RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will work for combinations where the maximum salt length is smaller than the digest size, which typically happens with large digest sizes (e.g., SHA-512) and small RSA keys. J.-S. Coron shows in "Optimal Security Proofs for PSS and Other Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332 of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag, 2002." that longer salts than the output size of modern hash functions do not increase security: "For example,for an application in which at most one billion signatures will be generated, k0 = 30 bits of random salt are actually sufficient to guarantee the same level of security as RSA, and taking a larger salt does not increase the security level." Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#19724)

Rather than computing the PSS salt length again in core using ossl_rsa_ctx_to_pss_string, which calls rsa_ctx_to_pss and computes the salt length, obtain it from the provider using the OSSL_SIGNATURE_PARAM_ALGORITHM_ID param to handle the case where the interpretation of the magic constants in the provider differs from that of OpenSSL core. Add tests that verify that the rsa_pss_saltlen:max, rsa_pss_saltlen:<integer> and rsa_pss_saltlen:digest options work and put the computed digest length into the CMS_ContentInfo struct when using CMS. Do not add a test for the salt length generated by a provider when no specific rsa_pss_saltlen option is defined, since that number could change between providers and provider versions, and we want to preserve compatibility with older providers. Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#19724)

FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection 5.5 "PKCS openssl#1" says: "For RSASSA-PSS […] the length (in bytes) of the salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of the hash function output block (in bytes)." Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will not use more than the digest length when signing, so that FIPS 186-4 is not violated. This value has two advantages when compared with RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when verifying signatures for maximum compatibility, where RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will work for combinations where the maximum salt length is smaller than the digest size, which typically happens with large digest sizes (e.g., SHA-512) and small RSA keys. J.-S. Coron shows in "Optimal Security Proofs for PSS and Other Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332 of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag, 2002." that longer salts than the output size of modern hash functions do not increase security: "For example,for an application in which at most one billion signatures will be generated, k0 = 30 bits of random salt are actually sufficient to guarantee the same level of security as RSA, and taking a larger salt does not increase the security level." Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#19724)

github-actions bot added the severity: fips change The pull request changes FIPS provider sources label Nov 21, 2022

t8m added branch: master Merge to master branch triaged: feature The issue/pr requests/adds a feature branch: 3.1 Merge to openssl-3.1 labels Nov 21, 2022

neverpanic force-pushed the cllang-rsassa-pss-saltlen-fips186-4 branch from 823238c to f7fd2c2 Compare November 21, 2022 14:26

beldmit added the hold: need otc decision The OTC needs to make a decision label Nov 21, 2022

slontis reviewed Nov 21, 2022

View reviewed changes

neverpanic force-pushed the cllang-rsassa-pss-saltlen-fips186-4 branch from f7fd2c2 to 280cd94 Compare November 24, 2022 13:03

t8m requested changes Nov 24, 2022

View reviewed changes

neverpanic force-pushed the cllang-rsassa-pss-saltlen-fips186-4 branch from 280cd94 to 6eda3de Compare November 24, 2022 13:58

mattcaswell added hold: needs tests The PR needs tests to be added to it and removed hold: need otc decision The OTC needs to make a decision labels Nov 29, 2022

neverpanic force-pushed the cllang-rsassa-pss-saltlen-fips186-4 branch from a73ebe2 to 89bfb0c Compare December 6, 2022 18:11

t8m requested a review from slontis December 7, 2022 08:20

t8m approved these changes Dec 7, 2022

View reviewed changes

beldmit added approval: done This pull request has the required number of approvals and removed approval: review pending This pull request needs review by a committer labels Dec 7, 2022

openssl-machine added approval: ready to merge The 24 hour grace period has passed, ready to merge and removed approval: done This pull request has the required number of approvals labels Dec 8, 2022

t8m removed the branch: 3.1 Merge to openssl-3.1 label Dec 8, 2022

t8m closed this Dec 8, 2022

neverpanic mentioned this pull request Dec 8, 2022

signature: Clamp PSS salt len to MD len (openssl-3.1) #19862

Closed

2 tasks

neverpanic deleted the cllang-rsassa-pss-saltlen-fips186-4 branch December 8, 2022 11:22

neverpanic mentioned this pull request Dec 8, 2022

Obtain PSS salt length from provider #19863

Closed

2 tasks

t8m mentioned this pull request Dec 16, 2022

rsapssSaltlen (80-test_cms) failed on MSYS2/Win32/MinGW #19907

Closed

alonbl mentioned this pull request May 20, 2023

PSS signature fails with legacy RSA_METHOD #21008

Closed

neverpanic mentioned this pull request Mar 5, 2024

Add fips indicator requirements doc #23609

Open

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

signature: Clamp PSS salt len to MD len #19724

signature: Clamp PSS salt len to MD len #19724

neverpanic commented Nov 21, 2022 •

edited by beldmit

Loading

t8m commented Nov 21, 2022

neverpanic commented Nov 21, 2022

t8m commented Nov 21, 2022

t8m commented Nov 21, 2022

neverpanic commented Nov 21, 2022

t8m commented Nov 21, 2022

t8m commented Nov 21, 2022

beldmit commented Nov 21, 2022

t8m commented Nov 21, 2022

t8m commented Nov 21, 2022

neverpanic commented Nov 21, 2022

beldmit commented Nov 21, 2022

slontis left a comment

neverpanic commented Nov 24, 2022

t8m Nov 24, 2022

neverpanic Nov 24, 2022

t8m Nov 24, 2022

neverpanic Nov 24, 2022

t8m Nov 24, 2022

neverpanic Nov 24, 2022

t8m commented Nov 24, 2022

neverpanic commented Nov 24, 2022 •

edited

Loading

t8m commented Nov 24, 2022

neverpanic commented Nov 28, 2022

mattcaswell commented Nov 29, 2022

neverpanic commented Dec 6, 2022

t8m commented Dec 7, 2022

beldmit commented Dec 7, 2022

openssl-machine commented Dec 8, 2022

t8m commented Dec 8, 2022

signature: Clamp PSS salt len to MD len #19724

signature: Clamp PSS salt len to MD len #19724

Conversation

neverpanic commented Nov 21, 2022 • edited by beldmit Loading

Checklist

t8m commented Nov 21, 2022

neverpanic commented Nov 21, 2022

t8m commented Nov 21, 2022

t8m commented Nov 21, 2022

neverpanic commented Nov 21, 2022

t8m commented Nov 21, 2022

t8m commented Nov 21, 2022

beldmit commented Nov 21, 2022

t8m commented Nov 21, 2022

t8m commented Nov 21, 2022

neverpanic commented Nov 21, 2022

beldmit commented Nov 21, 2022

slontis left a comment

Choose a reason for hiding this comment

neverpanic commented Nov 24, 2022

t8m Nov 24, 2022

Choose a reason for hiding this comment

neverpanic Nov 24, 2022

Choose a reason for hiding this comment

t8m Nov 24, 2022

Choose a reason for hiding this comment

neverpanic Nov 24, 2022

Choose a reason for hiding this comment

t8m Nov 24, 2022

Choose a reason for hiding this comment

neverpanic Nov 24, 2022

Choose a reason for hiding this comment

t8m commented Nov 24, 2022

neverpanic commented Nov 24, 2022 • edited Loading

t8m commented Nov 24, 2022

neverpanic commented Nov 28, 2022

mattcaswell commented Nov 29, 2022

neverpanic commented Dec 6, 2022

t8m commented Dec 7, 2022

beldmit commented Dec 7, 2022

openssl-machine commented Dec 8, 2022

t8m commented Dec 8, 2022

neverpanic commented Nov 21, 2022 •

edited by beldmit

Loading

neverpanic commented Nov 24, 2022 •

edited

Loading