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
edited Mar 15 at 10:18
AleksanderRas
2,8501835
asked Mar 15 at 9:49
Tom K.Tom K.
1556
$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
edited Mar 15 at 10:18
AleksanderRas
2,8501835
asked Mar 15 at 9:49
Tom K.Tom K.
1556
$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
edited Mar 15 at 10:18
AleksanderRas
2,8501835
asked Mar 15 at 9:49
Tom K.Tom K.
1556
$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 Mar 15 at 10:18
AleksanderRas
2,8501835
asked Mar 15 at 9:49
Tom K.Tom K.
1556
edited Mar 15 at 10:18
AleksanderRas
2,8501835
asked Mar 15 at 9:49
Tom K.Tom K.
1556
edited Mar 15 at 10:18
AleksanderRas
2,8501835
edited Mar 15 at 10:18
AleksanderRas
2,8501835
edited Mar 15 at 10:18
AleksanderRas
2,8501835
2,8501835
asked Mar 15 at 9:49
Tom K.Tom K.
1556
asked Mar 15 at 9:49
Tom K.Tom K.
1556
asked Mar 15 at 9:49
Tom K.Tom K.
1556
1556
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.
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
$endgroup$
2
$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
Mar 15 at 19:44
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.
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
$endgroup$
2
$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
Mar 15 at 19:44
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.
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
$endgroup$
2
$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
Mar 15 at 19:44
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.
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
$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.
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
edited Mar 15 at 17:55
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
answered Mar 15 at 11:51
fgrieufgrieu
81.8k7178349
81.8k7178349
2
$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
Mar 15 at 19:44
add a comment |
2
$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
Mar 15 at 19:44
2
2
$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
Mar 15 at 19:44
$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
Mar 15 at 19:44
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
