Why is the BSI not using powers of two?
$begingroup$
In their Technical Guideline TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths the BSI is giving minimal key lengths for - e.g. the TLS handshake protocol. All of these are not integers that are a power of two. I always thought, that it was the norm to give key lengths as powers of two. Is it not?
notation
$endgroup$
add a comment |
$begingroup$
In their Technical Guideline TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths the BSI is giving minimal key lengths for - e.g. the TLS handshake protocol. All of these are not integers that are a power of two. I always thought, that it was the norm to give key lengths as powers of two. Is it not?
notation
$endgroup$
add a comment |
$begingroup$
In their Technical Guideline TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths the BSI is giving minimal key lengths for - e.g. the TLS handshake protocol. All of these are not integers that are a power of two. I always thought, that it was the norm to give key lengths as powers of two. Is it not?
notation
$endgroup$
In their Technical Guideline TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths the BSI is giving minimal key lengths for - e.g. the TLS handshake protocol. All of these are not integers that are a power of two. I always thought, that it was the norm to give key lengths as powers of two. Is it not?
notation
notation
edited 17 hours ago
AleksanderRas
2,7671835
2,7671835
asked 17 hours ago
Tom K.Tom K.
1486
1486
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
My guess is that it is stated a round decimal number (e.g. 2000) of bits in order not to disqualify solutions using keys that can be up to the next round binary number (e.g. 2048) of bits, but are occasionally slightly less.
In particular, in RSA, when we make the product of two 1024-bit primes, the result is 2047 or 2048-bit. This scenario happens with some versions of PGP/GPG, and some SSH software. Contrast with FIPS 186-4, which wants 2048-bit moduli to be exactly 2048-bit, and towards that goal generates 1024-bit primes at least $2^{1023.5}$. TR-02102-2 is slightly more lenient, in a way that does not practically compromise security.
$endgroup$
1
$begingroup$
On the subject of "occasionally slightly less," cf. the recent silliness around "64-bit" certificate serial numbers that were really 63 bits. That was an example of a standard specifying an exact power of two, and then when software inevitably went off-by-one (in this case, to preserve the sign bit of a 64-bit integer), it counted as noncompliance-with-the-standard and provoked extreme reactions. If the standard had said "serial numbers must have at least 60 bits," or "100 bits," there'd have been no problem.
$endgroup$
– Quuxplusone
7 hours ago
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%2f68034%2fwhy-is-the-bsi-not-using-powers-of-two%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$
My guess is that it is stated a round decimal number (e.g. 2000) of bits in order not to disqualify solutions using keys that can be up to the next round binary number (e.g. 2048) of bits, but are occasionally slightly less.
In particular, in RSA, when we make the product of two 1024-bit primes, the result is 2047 or 2048-bit. This scenario happens with some versions of PGP/GPG, and some SSH software. Contrast with FIPS 186-4, which wants 2048-bit moduli to be exactly 2048-bit, and towards that goal generates 1024-bit primes at least $2^{1023.5}$. TR-02102-2 is slightly more lenient, in a way that does not practically compromise security.
$endgroup$
1
$begingroup$
On the subject of "occasionally slightly less," cf. the recent silliness around "64-bit" certificate serial numbers that were really 63 bits. That was an example of a standard specifying an exact power of two, and then when software inevitably went off-by-one (in this case, to preserve the sign bit of a 64-bit integer), it counted as noncompliance-with-the-standard and provoked extreme reactions. If the standard had said "serial numbers must have at least 60 bits," or "100 bits," there'd have been no problem.
$endgroup$
– Quuxplusone
7 hours ago
add a comment |
$begingroup$
My guess is that it is stated a round decimal number (e.g. 2000) of bits in order not to disqualify solutions using keys that can be up to the next round binary number (e.g. 2048) of bits, but are occasionally slightly less.
In particular, in RSA, when we make the product of two 1024-bit primes, the result is 2047 or 2048-bit. This scenario happens with some versions of PGP/GPG, and some SSH software. Contrast with FIPS 186-4, which wants 2048-bit moduli to be exactly 2048-bit, and towards that goal generates 1024-bit primes at least $2^{1023.5}$. TR-02102-2 is slightly more lenient, in a way that does not practically compromise security.
$endgroup$
1
$begingroup$
On the subject of "occasionally slightly less," cf. the recent silliness around "64-bit" certificate serial numbers that were really 63 bits. That was an example of a standard specifying an exact power of two, and then when software inevitably went off-by-one (in this case, to preserve the sign bit of a 64-bit integer), it counted as noncompliance-with-the-standard and provoked extreme reactions. If the standard had said "serial numbers must have at least 60 bits," or "100 bits," there'd have been no problem.
$endgroup$
– Quuxplusone
7 hours ago
add a comment |
$begingroup$
My guess is that it is stated a round decimal number (e.g. 2000) of bits in order not to disqualify solutions using keys that can be up to the next round binary number (e.g. 2048) of bits, but are occasionally slightly less.
In particular, in RSA, when we make the product of two 1024-bit primes, the result is 2047 or 2048-bit. This scenario happens with some versions of PGP/GPG, and some SSH software. Contrast with FIPS 186-4, which wants 2048-bit moduli to be exactly 2048-bit, and towards that goal generates 1024-bit primes at least $2^{1023.5}$. TR-02102-2 is slightly more lenient, in a way that does not practically compromise security.
$endgroup$
My guess is that it is stated a round decimal number (e.g. 2000) of bits in order not to disqualify solutions using keys that can be up to the next round binary number (e.g. 2048) of bits, but are occasionally slightly less.
In particular, in RSA, when we make the product of two 1024-bit primes, the result is 2047 or 2048-bit. This scenario happens with some versions of PGP/GPG, and some SSH software. Contrast with FIPS 186-4, which wants 2048-bit moduli to be exactly 2048-bit, and towards that goal generates 1024-bit primes at least $2^{1023.5}$. TR-02102-2 is slightly more lenient, in a way that does not practically compromise security.
edited 9 hours ago
answered 15 hours ago
fgrieufgrieu
81.6k7175347
81.6k7175347
1
$begingroup$
On the subject of "occasionally slightly less," cf. the recent silliness around "64-bit" certificate serial numbers that were really 63 bits. That was an example of a standard specifying an exact power of two, and then when software inevitably went off-by-one (in this case, to preserve the sign bit of a 64-bit integer), it counted as noncompliance-with-the-standard and provoked extreme reactions. If the standard had said "serial numbers must have at least 60 bits," or "100 bits," there'd have been no problem.
$endgroup$
– Quuxplusone
7 hours ago
add a comment |
1
$begingroup$
On the subject of "occasionally slightly less," cf. the recent silliness around "64-bit" certificate serial numbers that were really 63 bits. That was an example of a standard specifying an exact power of two, and then when software inevitably went off-by-one (in this case, to preserve the sign bit of a 64-bit integer), it counted as noncompliance-with-the-standard and provoked extreme reactions. If the standard had said "serial numbers must have at least 60 bits," or "100 bits," there'd have been no problem.
$endgroup$
– Quuxplusone
7 hours ago
1
1
$begingroup$
On the subject of "occasionally slightly less," cf. the recent silliness around "64-bit" certificate serial numbers that were really 63 bits. That was an example of a standard specifying an exact power of two, and then when software inevitably went off-by-one (in this case, to preserve the sign bit of a 64-bit integer), it counted as noncompliance-with-the-standard and provoked extreme reactions. If the standard had said "serial numbers must have at least 60 bits," or "100 bits," there'd have been no problem.
$endgroup$
– Quuxplusone
7 hours ago
$begingroup$
On the subject of "occasionally slightly less," cf. the recent silliness around "64-bit" certificate serial numbers that were really 63 bits. That was an example of a standard specifying an exact power of two, and then when software inevitably went off-by-one (in this case, to preserve the sign bit of a 64-bit integer), it counted as noncompliance-with-the-standard and provoked extreme reactions. If the standard had said "serial numbers must have at least 60 bits," or "100 bits," there'd have been no problem.
$endgroup$
– Quuxplusone
7 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.
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%2f68034%2fwhy-is-the-bsi-not-using-powers-of-two%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