Remove 'unsalted' PSS handling by lumag · Pull Request #294 · RustCrypto/RSA

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag · 2023-04-15T01:38:18Z

The 'unsalted' PSS handling is not behaving like one would expect. It doesn't use salt of 0 length, but insteaad it uses some defaults which are not properly documented. Make the salt_len mandatatory for both singing and verification.

tarcieri

Looks good to me!

I don't understand the potential real-world usages of unsalted PSS, but from a theoretical perspective it makes no sense: the purpose of having a salt is to increase the tightness of the security proof. I don't understand why one would want to use PSS in a way which defeats the security proof.

So that said, I'm all for removing the unsalted API.

I think we could further improve the API by having one where the default salt length equals the output length of the digest function, but I'm happy to open a followup PR to add that.

lumag · 2023-04-15T01:48:52Z

@tarcieri sounds good to me.

cc @roblabla @dignifiedquire

tarcieri · 2023-04-15T01:49:11Z

@lumag alternatively, you could implement ^^^ proposed API in this PR, which would avoid the need to deprecate anything.

Instead, change new to be salted, but infer the salt size from the digest function.

(Or I'm still happy to do that as a followup, which would simplify the overall changes and help organize discussion perhaps)

lumag · 2023-04-15T01:52:40Z

Sure, I'll do that in a minute

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag · 2023-04-15T02:15:04Z

done

…n during verification (#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: #361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR #294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

Current new() and random() functions cause confusion. There is the default from ASN.1 encoding of RSAPSS parameters (20). There is also another default of (mod_size - 2 - hash_size). And there is a recommendation to use salt_len of hash_size. Drop old defaults and always use digest output size as the salt_len. Clearly document new default. * pss: specify salt_len when verifying the message All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS verification has an explicit salt length parameter (rather than determining it from the message). Drop our 'automagic' code and pass salt length when verifying the message. Old functions now default to digest output size as a hash length. * pss: remove possible non-constant time operation in PSS salt handling The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. --------- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

…n during verification (RustCrypto#546) This PR adds an optional method to automatically detect the salt length during RSA-PSS signature verification. Should Fix: RustCrypto#361 and similar situations. ### Problem The crate currently requires a fixed salt length for PSS verification. This prevents verification of signatures where the salt length is not known beforehand, a situation not uncommon in interoperability contexts. This capability was previously available but was removed in PR RustCrypto#294. ### Solution This change re-introduces salt length auto-detection as an explicit, opt-in feature. A new constructor, `VerifyingKey::new_with_auto_salt_len`, creates a verifier that performs this detection during verification. * The change is opt-in and does not affect default behavior. * It improves interoperability by handling signatures with variable / unknown salt lengths. * The salt detection logic is implemented in constant(-ish) time to resist timing attacks. ### Commit Structure This PR consists of three commits: 1. **test:** Adds a failing unit test to demonstrate the issue. 2. **feat:** Implements `new_with_auto_salt_len` and re-introduces the previous detection logic. 3. **fix:** Updates the detection logic to be less prone to timing attacks. Because salt length auto-detection is OpenSSL's default, it's likely that many systems were built without a mechanism to enforce or communicate a fixed salt length. Without this PR, it was impossible to reliably use this crate in my current project, and I suspect others face the same blocker. I've lost quite a bit of time dealing with seemingly random signature verification failures until I realized the crux of the problem.

lumag mentioned this pull request Apr 15, 2023
pss: make *_with_salt methods the default #291
Closed

tarcieri approved these changes Apr 15, 2023
View reviewed changes

Dmitry Baryshkov added 3 commits April 15, 2023 05:11

pss: remove possible non-constatnt time operation in PSS salt handling
d6a4fb0
The emsa_pss_get_salt() is possibly non-constant-time op. Change it to be a contant-time operation. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

lumag force-pushed the pss-no-salt branch from 0bfd861 to d6a4fb0Compare April 15, 2023 02:15

lumag mentioned this pull request Apr 15, 2023
pss: add random key generation for BlindedSigningKey #295
Merged

tarcieri approved these changes Apr 15, 2023
View reviewed changes

tarcieri requested a review from dignifiedquire April 15, 2023 02:27

tarcieri merged commit e7201ed into RustCrypto:masterApr 17, 2023

tarcieri mentioned this pull request Apr 27, 2023
v0.9.0 #318
Merged

tarcieri mentioned this pull request Aug 22, 2023
Update from 0.8 to 0.9 broke verification after reading PEM and using Sha256 PSS #361
Closed

rrauch mentioned this pull request Jul 30, 2025
PSS: Improve interoperability with optional auto salt length detection during verification #546
Merged