80-bit collision resistence because of 80-bit x87 registers?What are the practical differences between...
Boss asked me to sign a resignation paper without a date on it along with my new contract
Which was the first story to feature space elevators?
STM32 PWM problem
Define function that behaves almost identically to Mathematica function
Can a planet be tidally unlocked?
Microphone on Mars
How do I add a strong "onion flavor" to the biryani (in restaurant style)?
Was Opportunity's last message to Earth "My battery is low and it's getting dark"?
put country dropdown in phtml file in magento2
Is opening a file faster than reading variable content?
Identical projects by students at two different colleges: still plagiarism?
Why is Shelob considered evil?
Why Third 'Reich'? Why is 'reich' not translated when 'third' is? What is the English synonym of reich?
How can I differentiate duration vs starting time
Does changing "sa" password require a SQL restart (in mixed mode)?
Integral check. Is partial fractions the only way?
How does the income of your target audience matter for logo design?
The Longest Chess Game
I hate taking lectures, can I still survive in academia?
Why is ra lower than re while la is higher than le?
How many copper coins fit inside a cubic foot?
Discouraging missile alpha strikes
How to play songs that contain one guitar when we have two or more guitarists?
How can I portray body horror and still be sensitive to people with disabilities?
80-bit collision resistence because of 80-bit x87 registers?
What are the practical differences between 256-bit, 192-bit, and 128-bit AES encryption?Is there a practical security difference between XXX-bit encryption?Why is the complexity of RSA-1024 80 bit and not 86 bit?1 Billion Bit Encryption?Can there be a need for 1024-bit (symmetric) encryption?What was the first MD5 collision ever constructed?Bruteforcing a 64-bit keyAre 256-bit SSL certificates still secure?384-bit ChaCha20 / Salsa20Does C# Triple DES Encryption need 128 bit key or 192 bit key
$begingroup$
This is just a curious question, and it probably doesn't belong here anyway, and I'm just being bold asking it here.
80-bit used to be considered an adequate level of security, Skipjack and SHA1 were designed to be 80-bit-secure. But why 80 bits? Isn't 96 bits better because it's a multiple of 32 and gives a higher margin?
Does the choice of 80 bits have anything to do with the fact that the 8087 processor has a 80-bit floating-point register as part of the design?
key-size history
edited 1 hour ago
kodlu
8,93611329
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
$endgroup$
add a comment |
$begingroup$
This is just a curious question, and it probably doesn't belong here anyway, and I'm just being bold asking it here.
80-bit used to be considered an adequate level of security, Skipjack and SHA1 were designed to be 80-bit-secure. But why 80 bits? Isn't 96 bits better because it's a multiple of 32 and gives a higher margin?
Does the choice of 80 bits have anything to do with the fact that the 8087 processor has a 80-bit floating-point register as part of the design?
key-size history
edited 1 hour ago
kodlu
8,93611329
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
$endgroup$
add a comment |
$begingroup$
This is just a curious question, and it probably doesn't belong here anyway, and I'm just being bold asking it here.
80-bit used to be considered an adequate level of security, Skipjack and SHA1 were designed to be 80-bit-secure. But why 80 bits? Isn't 96 bits better because it's a multiple of 32 and gives a higher margin?
Does the choice of 80 bits have anything to do with the fact that the 8087 processor has a 80-bit floating-point register as part of the design?
key-size history
edited 1 hour ago
kodlu
8,93611329
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
$endgroup$
This is just a curious question, and it probably doesn't belong here anyway, and I'm just being bold asking it here.
80-bit used to be considered an adequate level of security, Skipjack and SHA1 were designed to be 80-bit-secure. But why 80 bits? Isn't 96 bits better because it's a multiple of 32 and gives a higher margin?
Does the choice of 80 bits have anything to do with the fact that the 8087 processor has a 80-bit floating-point register as part of the design?
key-size history
key-size history
edited 1 hour ago
kodlu
8,93611329
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
edited 1 hour ago
kodlu
8,93611329
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
edited 1 hour ago
kodlu
8,93611329
edited 1 hour ago
kodlu
8,93611329
edited 1 hour ago
kodlu
8,93611329
8,93611329
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
asked 3 hours ago
DannyNiuDannyNiu
1,2091627
1,2091627
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
Coprocessors are designed for improved performance in a certain case, and in the case of fixed-width mathematics, I do not believe you would see a performance increase.
I am quite sure that 80-bits is simply because it is 10, 8-bit words, and not that it is targeting the 80-bit registers in a FPU. Primarily, it would be inconvenient to use an FPU for this case due to the instruction layout. In the case of Skipjack or a Feistel network in general, I do not know of any easy way to do the block swap without pulling the words out of the FPU back to the CPU to do the swap because the FPU hardware is designed around mantissa functions, not shifts and XORs. You could use the FPU for intermediate storage, but because the x87 (this is particular case that is very x86 specific), you pull the 10-byte sequence from the stack, which would be more of a cost than just keeping it all in the integer unit.
Another note of security margins and Skipjack, it was designed for a minimally viable VLSI implementation. If you were going to put something on an IC circa 1996, you'd probably lean toward 80-bits over 88 or 96, or larger. MPEG-1, 2, 4 etc all had choices that were sub-optimal mathematically but the decoder ICs needed to be viable as a VLSI implementation. At meetings, this is always a constraint that comes up. At NIST 8114, we've had the discussions but I've never seen these discussions formalized. In power constrained computing, such as passively powered RFID, I still make engineering choices that are sub-optimal as far as ideal cryptography because bits cost money to make, power to use, and I don't have the luxury of increasing IC costs or power consumption. Encryption often takes a backseat to economics in the same way that security does to convenience.
answered 1 hour ago
b degnanb degnan
1,9051627
$endgroup$
add a comment |
$begingroup$
To get 80 bit security for a Hash function, you need a hash with output bitlength 160 bits due to the birthday problem and collision resistance. Note that $160=5times 32.$
So, the 80 bits was convenient as security level for Hashes since they then equalled the existing idea of 80 bits as being a good security level for symmetric key at that time. The fact that AES was already 128 bits was due to inbuilt extra margins to survive well into the future.
answered 1 hour ago
kodlukodlu
8,93611329
$endgroup$
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%2f67491%2f80-bit-collision-resistence-because-of-80-bit-x87-registers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Coprocessors are designed for improved performance in a certain case, and in the case of fixed-width mathematics, I do not believe you would see a performance increase.
I am quite sure that 80-bits is simply because it is 10, 8-bit words, and not that it is targeting the 80-bit registers in a FPU. Primarily, it would be inconvenient to use an FPU for this case due to the instruction layout. In the case of Skipjack or a Feistel network in general, I do not know of any easy way to do the block swap without pulling the words out of the FPU back to the CPU to do the swap because the FPU hardware is designed around mantissa functions, not shifts and XORs. You could use the FPU for intermediate storage, but because the x87 (this is particular case that is very x86 specific), you pull the 10-byte sequence from the stack, which would be more of a cost than just keeping it all in the integer unit.
Another note of security margins and Skipjack, it was designed for a minimally viable VLSI implementation. If you were going to put something on an IC circa 1996, you'd probably lean toward 80-bits over 88 or 96, or larger. MPEG-1, 2, 4 etc all had choices that were sub-optimal mathematically but the decoder ICs needed to be viable as a VLSI implementation. At meetings, this is always a constraint that comes up. At NIST 8114, we've had the discussions but I've never seen these discussions formalized. In power constrained computing, such as passively powered RFID, I still make engineering choices that are sub-optimal as far as ideal cryptography because bits cost money to make, power to use, and I don't have the luxury of increasing IC costs or power consumption. Encryption often takes a backseat to economics in the same way that security does to convenience.
answered 1 hour ago
b degnanb degnan
1,9051627
$endgroup$
add a comment |
$begingroup$
Coprocessors are designed for improved performance in a certain case, and in the case of fixed-width mathematics, I do not believe you would see a performance increase.
I am quite sure that 80-bits is simply because it is 10, 8-bit words, and not that it is targeting the 80-bit registers in a FPU. Primarily, it would be inconvenient to use an FPU for this case due to the instruction layout. In the case of Skipjack or a Feistel network in general, I do not know of any easy way to do the block swap without pulling the words out of the FPU back to the CPU to do the swap because the FPU hardware is designed around mantissa functions, not shifts and XORs. You could use the FPU for intermediate storage, but because the x87 (this is particular case that is very x86 specific), you pull the 10-byte sequence from the stack, which would be more of a cost than just keeping it all in the integer unit.
Another note of security margins and Skipjack, it was designed for a minimally viable VLSI implementation. If you were going to put something on an IC circa 1996, you'd probably lean toward 80-bits over 88 or 96, or larger. MPEG-1, 2, 4 etc all had choices that were sub-optimal mathematically but the decoder ICs needed to be viable as a VLSI implementation. At meetings, this is always a constraint that comes up. At NIST 8114, we've had the discussions but I've never seen these discussions formalized. In power constrained computing, such as passively powered RFID, I still make engineering choices that are sub-optimal as far as ideal cryptography because bits cost money to make, power to use, and I don't have the luxury of increasing IC costs or power consumption. Encryption often takes a backseat to economics in the same way that security does to convenience.
answered 1 hour ago
b degnanb degnan
1,9051627
$endgroup$
add a comment |
$begingroup$
Coprocessors are designed for improved performance in a certain case, and in the case of fixed-width mathematics, I do not believe you would see a performance increase.
I am quite sure that 80-bits is simply because it is 10, 8-bit words, and not that it is targeting the 80-bit registers in a FPU. Primarily, it would be inconvenient to use an FPU for this case due to the instruction layout. In the case of Skipjack or a Feistel network in general, I do not know of any easy way to do the block swap without pulling the words out of the FPU back to the CPU to do the swap because the FPU hardware is designed around mantissa functions, not shifts and XORs. You could use the FPU for intermediate storage, but because the x87 (this is particular case that is very x86 specific), you pull the 10-byte sequence from the stack, which would be more of a cost than just keeping it all in the integer unit.
Another note of security margins and Skipjack, it was designed for a minimally viable VLSI implementation. If you were going to put something on an IC circa 1996, you'd probably lean toward 80-bits over 88 or 96, or larger. MPEG-1, 2, 4 etc all had choices that were sub-optimal mathematically but the decoder ICs needed to be viable as a VLSI implementation. At meetings, this is always a constraint that comes up. At NIST 8114, we've had the discussions but I've never seen these discussions formalized. In power constrained computing, such as passively powered RFID, I still make engineering choices that are sub-optimal as far as ideal cryptography because bits cost money to make, power to use, and I don't have the luxury of increasing IC costs or power consumption. Encryption often takes a backseat to economics in the same way that security does to convenience.
answered 1 hour ago
b degnanb degnan
1,9051627
$endgroup$
Coprocessors are designed for improved performance in a certain case, and in the case of fixed-width mathematics, I do not believe you would see a performance increase.
I am quite sure that 80-bits is simply because it is 10, 8-bit words, and not that it is targeting the 80-bit registers in a FPU. Primarily, it would be inconvenient to use an FPU for this case due to the instruction layout. In the case of Skipjack or a Feistel network in general, I do not know of any easy way to do the block swap without pulling the words out of the FPU back to the CPU to do the swap because the FPU hardware is designed around mantissa functions, not shifts and XORs. You could use the FPU for intermediate storage, but because the x87 (this is particular case that is very x86 specific), you pull the 10-byte sequence from the stack, which would be more of a cost than just keeping it all in the integer unit.
Another note of security margins and Skipjack, it was designed for a minimally viable VLSI implementation. If you were going to put something on an IC circa 1996, you'd probably lean toward 80-bits over 88 or 96, or larger. MPEG-1, 2, 4 etc all had choices that were sub-optimal mathematically but the decoder ICs needed to be viable as a VLSI implementation. At meetings, this is always a constraint that comes up. At NIST 8114, we've had the discussions but I've never seen these discussions formalized. In power constrained computing, such as passively powered RFID, I still make engineering choices that are sub-optimal as far as ideal cryptography because bits cost money to make, power to use, and I don't have the luxury of increasing IC costs or power consumption. Encryption often takes a backseat to economics in the same way that security does to convenience.
answered 1 hour ago
b degnanb degnan
1,9051627
answered 1 hour ago
b degnanb degnan
1,9051627
answered 1 hour ago
b degnanb degnan
1,9051627
answered 1 hour ago
b degnanb degnan
1,9051627
1,9051627
add a comment |
add a comment |
$begingroup$
To get 80 bit security for a Hash function, you need a hash with output bitlength 160 bits due to the birthday problem and collision resistance. Note that $160=5times 32.$
So, the 80 bits was convenient as security level for Hashes since they then equalled the existing idea of 80 bits as being a good security level for symmetric key at that time. The fact that AES was already 128 bits was due to inbuilt extra margins to survive well into the future.
answered 1 hour ago
kodlukodlu
8,93611329
$endgroup$
add a comment |
$begingroup$
To get 80 bit security for a Hash function, you need a hash with output bitlength 160 bits due to the birthday problem and collision resistance. Note that $160=5times 32.$
So, the 80 bits was convenient as security level for Hashes since they then equalled the existing idea of 80 bits as being a good security level for symmetric key at that time. The fact that AES was already 128 bits was due to inbuilt extra margins to survive well into the future.
answered 1 hour ago
kodlukodlu
8,93611329
$endgroup$
add a comment |
$begingroup$
To get 80 bit security for a Hash function, you need a hash with output bitlength 160 bits due to the birthday problem and collision resistance. Note that $160=5times 32.$
So, the 80 bits was convenient as security level for Hashes since they then equalled the existing idea of 80 bits as being a good security level for symmetric key at that time. The fact that AES was already 128 bits was due to inbuilt extra margins to survive well into the future.
answered 1 hour ago
kodlukodlu
8,93611329
$endgroup$
To get 80 bit security for a Hash function, you need a hash with output bitlength 160 bits due to the birthday problem and collision resistance. Note that $160=5times 32.$
So, the 80 bits was convenient as security level for Hashes since they then equalled the existing idea of 80 bits as being a good security level for symmetric key at that time. The fact that AES was already 128 bits was due to inbuilt extra margins to survive well into the future.
answered 1 hour ago
kodlukodlu
8,93611329
answered 1 hour ago
kodlukodlu
8,93611329
answered 1 hour ago
kodlukodlu
8,93611329
answered 1 hour ago
kodlukodlu
8,93611329
8,93611329
add a comment |
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%2f67491%2f80-bit-collision-resistence-because-of-80-bit-x87-registers%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
