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
asked Dec 3 at 11:20
Evgeni Vaknin
375110
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
asked Dec 3 at 11:20
Evgeni Vaknin
375110
Related to Why use randomness in digital signature algorithms?.
– fgrieu
Dec 3 at 11:46
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
asked Dec 3 at 11:20
Evgeni Vaknin
375110
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 Dec 3 at 11:20
Evgeni Vaknin
375110
asked Dec 3 at 11:20
Evgeni Vaknin
375110
asked Dec 3 at 11:20
Evgeni Vaknin
375110
asked Dec 3 at 11:20
Evgeni Vaknin
375110
asked Dec 3 at 11:20
Evgeni Vaknin
375110
375110
Related to Why use randomness in digital signature algorithms?.
– fgrieu
Dec 3 at 11:46
add a comment |
Related to Why use randomness in digital signature algorithms?.
– fgrieu
Dec 3 at 11:46
Related to Why use randomness in digital signature algorithms?.
– fgrieu
Dec 3 at 11:46
Related to Why use randomness in digital signature algorithms?.
– fgrieu
Dec 3 at 11:46
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.
answered Dec 3 at 12:03
fgrieu
77.4k7160326
1
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
Dec 4 at 14:46
@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
Dec 4 at 14:55
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
Dec 4 at 15:13
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "281"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
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.
answered Dec 3 at 12:03
fgrieu
77.4k7160326
1
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
Dec 4 at 14:46
@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
Dec 4 at 14:55
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
Dec 4 at 15:13
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.
answered Dec 3 at 12:03
fgrieu
77.4k7160326
1
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
Dec 4 at 14:46
@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
Dec 4 at 14:55
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
Dec 4 at 15:13
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.
answered Dec 3 at 12:03
fgrieu
77.4k7160326
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.
answered Dec 3 at 12:03
fgrieu
77.4k7160326
edited Dec 3 at 12:08
answered Dec 3 at 12:03
fgrieu
77.4k7160326
answered Dec 3 at 12:03
fgrieu
77.4k7160326
answered Dec 3 at 12:03
fgrieu
77.4k7160326
77.4k7160326
1
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
Dec 4 at 14:46
@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
Dec 4 at 14:55
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
Dec 4 at 15:13
add a comment |
1
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
Dec 4 at 14:46
@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
Dec 4 at 14:55
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
Dec 4 at 15:13
1
1
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
Dec 4 at 14:46
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
Dec 4 at 14:46
@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
Dec 4 at 14:55
@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
Dec 4 at 14:55
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
Dec 4 at 15:13
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
Dec 4 at 15:13
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
Dec 3 at 11:46