RSA PSS security advantage
$begingroup$
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 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
$endgroup$
add a comment |
$begingroup$
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 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
$endgroup$
$begingroup$
Related to Why use randomness in digital signature algorithms?.
$endgroup$
– fgrieu
Dec 3 '18 at 11:46
add a comment |
$begingroup$
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 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
$endgroup$
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 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
asked Dec 3 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
asked Dec 3 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
asked Dec 3 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
asked Dec 3 '18 at 11:20
Evgeni VakninEvgeni Vaknin
375110
375110
$begingroup$
Related to Why use randomness in digital signature algorithms?.
$endgroup$
– fgrieu
Dec 3 '18 at 11:46
add a comment |
$begingroup$
Related to Why use randomness in digital signature algorithms?.
$endgroup$
– fgrieu
Dec 3 '18 at 11:46
$begingroup$
Related to Why use randomness in digital signature algorithms?.
$endgroup$
– fgrieu
Dec 3 '18 at 11:46
$begingroup$
Related to Why use randomness in digital signature algorithms?.
$endgroup$
– fgrieu
Dec 3 '18 at 11:46
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
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 '18 at 12:03
fgrieufgrieu
78.4k7167332
$endgroup$
1
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 14:46
$begingroup$
@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.
$endgroup$
– fgrieu
Dec 4 '18 at 14:55
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 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',
autoActivateHeartbeat: false,
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
$begingroup$
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 '18 at 12:03
fgrieufgrieu
78.4k7167332
$endgroup$
1
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 14:46
$begingroup$
@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.
$endgroup$
– fgrieu
Dec 4 '18 at 14:55
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 15:13
add a comment |
$begingroup$
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 '18 at 12:03
fgrieufgrieu
78.4k7167332
$endgroup$
1
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 14:46
$begingroup$
@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.
$endgroup$
– fgrieu
Dec 4 '18 at 14:55
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 15:13
add a comment |
$begingroup$
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 '18 at 12:03
fgrieufgrieu
78.4k7167332
$endgroup$
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 '18 at 12:03
fgrieufgrieu
78.4k7167332
edited Dec 3 '18 at 12:08
answered Dec 3 '18 at 12:03
fgrieufgrieu
78.4k7167332
answered Dec 3 '18 at 12:03
fgrieufgrieu
78.4k7167332
answered Dec 3 '18 at 12:03
fgrieufgrieu
78.4k7167332
78.4k7167332
1
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 14:46
$begingroup$
@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.
$endgroup$
– fgrieu
Dec 4 '18 at 14:55
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 15:13
add a comment |
1
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 14:46
$begingroup$
@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.
$endgroup$
– fgrieu
Dec 4 '18 at 14:55
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 15:13
1
1
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 14:46
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 14:46
$begingroup$
@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.
$endgroup$
– fgrieu
Dec 4 '18 at 14:55
$begingroup$
@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.
$endgroup$
– fgrieu
Dec 4 '18 at 14:55
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 at 15:13
$begingroup$
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.
$endgroup$
– Maarten Bodewes♦
Dec 4 '18 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.
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
$begingroup$
Related to Why use randomness in digital signature algorithms?.
$endgroup$
– fgrieu
Dec 3 '18 at 11:46