RSA PSS security advantage
up vote
5
down vote
favorite
To my humble opinion, please correct me if I'm wrong, RSA-PSS (PKCS#1 ver 2.1) advantage over RSA as described in PKCS#1 ver. 1.5 is in its security proofs. Does this proof and the advantage is still there even if the "salt" in the RSA-PSS scheme is constant over all messages, or it conditioned in generating a random salt each and every signature? That is, does the security proof of RSA-PSS assumes random salt over messages?
rsa signature salt digital
add a comment |
up vote
5
down vote
favorite
To my humble opinion, please correct me if I'm wrong, RSA-PSS (PKCS#1 ver 2.1) advantage over RSA as described in PKCS#1 ver. 1.5 is in its security proofs. Does this proof and the advantage is still there even if the "salt" in the RSA-PSS scheme is constant over all messages, or it conditioned in generating a random salt each and every signature? That is, does the security proof of RSA-PSS assumes random salt over messages?
rsa signature salt digital
Related to Why use randomness in digital signature algorithms?.
– fgrieu
yesterday
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
To my humble opinion, please correct me if I'm wrong, RSA-PSS (PKCS#1 ver 2.1) advantage over RSA as described in PKCS#1 ver. 1.5 is in its security proofs. Does this proof and the advantage is still there even if the "salt" in the RSA-PSS scheme is constant over all messages, or it conditioned in generating a random salt each and every signature? That is, does the security proof of RSA-PSS assumes random salt over messages?
rsa signature salt digital
To my humble opinion, please correct me if I'm wrong, RSA-PSS (PKCS#1 ver 2.1) advantage over RSA as described in PKCS#1 ver. 1.5 is in its security proofs. Does this proof and the advantage is still there even if the "salt" in the RSA-PSS scheme is constant over all messages, or it conditioned in generating a random salt each and every signature? That is, does the security proof of RSA-PSS assumes random salt over messages?
rsa signature salt digital
rsa signature salt digital
asked yesterday
Evgeni Vaknin
375110
375110
Related to Why use randomness in digital signature algorithms?.
– fgrieu
yesterday
add a comment |
Related to Why use randomness in digital signature algorithms?.
– fgrieu
yesterday
Related to Why use randomness in digital signature algorithms?.
– fgrieu
yesterday
Related to Why use randomness in digital signature algorithms?.
– fgrieu
yesterday
add a comment |
1 Answer
1
active
oldest
votes
up vote
4
down vote
Even if we make RSASSA-PSS
deterministic by fixing its seed, it remains with a security proof in the Random Oracle Model per Full Domain Hashing (Jean-Sébastien Coron, On the Exact Security of Full Domain Hashing, in proceedings of Crypto 2000). We can't say the same for RSASSA-PKCS1-v1_5
, because a lot of the message representative is fixed.
In practice, a better argument to use deterministic RSASSA-PSS
rather than RSASSA-PKCS1-v1_5
is that vulnerable implementations of verification of RSASSA-PKCS1-v1_5
abound, when I know no vulnerable implementation of RSASSA-PSS
verification (regardless of randomization), and this is less likely to happen accidentally.
However a practical argument against RSASSA-PSS
is that it requires careful specification of the hash and the mask generation function: even if the later is almost universally MGF1, that could be with another hash (e.g. stuck to SHA-1) depending on implementations.
Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten.
– Maarten Bodewes
13 hours ago
@Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
13 hours ago
Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that.
– Maarten Bodewes
13 hours ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
Even if we make RSASSA-PSS
deterministic by fixing its seed, it remains with a security proof in the Random Oracle Model per Full Domain Hashing (Jean-Sébastien Coron, On the Exact Security of Full Domain Hashing, in proceedings of Crypto 2000). We can't say the same for RSASSA-PKCS1-v1_5
, because a lot of the message representative is fixed.
In practice, a better argument to use deterministic RSASSA-PSS
rather than RSASSA-PKCS1-v1_5
is that vulnerable implementations of verification of RSASSA-PKCS1-v1_5
abound, when I know no vulnerable implementation of RSASSA-PSS
verification (regardless of randomization), and this is less likely to happen accidentally.
However a practical argument against RSASSA-PSS
is that it requires careful specification of the hash and the mask generation function: even if the later is almost universally MGF1, that could be with another hash (e.g. stuck to SHA-1) depending on implementations.
Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten.
– Maarten Bodewes
13 hours ago
@Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
13 hours ago
Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that.
– Maarten Bodewes
13 hours ago
add a comment |
up vote
4
down vote
Even if we make RSASSA-PSS
deterministic by fixing its seed, it remains with a security proof in the Random Oracle Model per Full Domain Hashing (Jean-Sébastien Coron, On the Exact Security of Full Domain Hashing, in proceedings of Crypto 2000). We can't say the same for RSASSA-PKCS1-v1_5
, because a lot of the message representative is fixed.
In practice, a better argument to use deterministic RSASSA-PSS
rather than RSASSA-PKCS1-v1_5
is that vulnerable implementations of verification of RSASSA-PKCS1-v1_5
abound, when I know no vulnerable implementation of RSASSA-PSS
verification (regardless of randomization), and this is less likely to happen accidentally.
However a practical argument against RSASSA-PSS
is that it requires careful specification of the hash and the mask generation function: even if the later is almost universally MGF1, that could be with another hash (e.g. stuck to SHA-1) depending on implementations.
Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten.
– Maarten Bodewes
13 hours ago
@Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
13 hours ago
Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that.
– Maarten Bodewes
13 hours ago
add a comment |
up vote
4
down vote
up vote
4
down vote
Even if we make RSASSA-PSS
deterministic by fixing its seed, it remains with a security proof in the Random Oracle Model per Full Domain Hashing (Jean-Sébastien Coron, On the Exact Security of Full Domain Hashing, in proceedings of Crypto 2000). We can't say the same for RSASSA-PKCS1-v1_5
, because a lot of the message representative is fixed.
In practice, a better argument to use deterministic RSASSA-PSS
rather than RSASSA-PKCS1-v1_5
is that vulnerable implementations of verification of RSASSA-PKCS1-v1_5
abound, when I know no vulnerable implementation of RSASSA-PSS
verification (regardless of randomization), and this is less likely to happen accidentally.
However a practical argument against RSASSA-PSS
is that it requires careful specification of the hash and the mask generation function: even if the later is almost universally MGF1, that could be with another hash (e.g. stuck to SHA-1) depending on implementations.
Even if we make RSASSA-PSS
deterministic by fixing its seed, it remains with a security proof in the Random Oracle Model per Full Domain Hashing (Jean-Sébastien Coron, On the Exact Security of Full Domain Hashing, in proceedings of Crypto 2000). We can't say the same for RSASSA-PKCS1-v1_5
, because a lot of the message representative is fixed.
In practice, a better argument to use deterministic RSASSA-PSS
rather than RSASSA-PKCS1-v1_5
is that vulnerable implementations of verification of RSASSA-PKCS1-v1_5
abound, when I know no vulnerable implementation of RSASSA-PSS
verification (regardless of randomization), and this is less likely to happen accidentally.
However a practical argument against RSASSA-PSS
is that it requires careful specification of the hash and the mask generation function: even if the later is almost universally MGF1, that could be with another hash (e.g. stuck to SHA-1) depending on implementations.
edited yesterday
answered yesterday
fgrieu
76.9k7158322
76.9k7158322
Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten.
– Maarten Bodewes
13 hours ago
@Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
13 hours ago
Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that.
– Maarten Bodewes
13 hours ago
add a comment |
Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten.
– Maarten Bodewes
13 hours ago
@Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
13 hours ago
Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that.
– Maarten Bodewes
13 hours ago
Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten.
– Maarten Bodewes
13 hours ago
Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten.
– Maarten Bodewes
13 hours ago
@Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
13 hours ago
@Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
13 hours ago
Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that.
– Maarten Bodewes
13 hours ago
Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that.
– Maarten Bodewes
13 hours ago
add a comment |
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64516%2frsa-pss-security-advantage%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Related to Why use randomness in digital signature algorithms?.
– fgrieu
yesterday