What is a related key?
$begingroup$
We talk of related keys and related key attacks, but what is a 'related key'? So in three related parts:-
- How can one key be related to another key?
- Is there a metric describing the degree of relationship?
- Is there a link between the nature of keys' relationships and any specific cryptographic functions?
keys
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
$endgroup$
add a comment |
$begingroup$
We talk of related keys and related key attacks, but what is a 'related key'? So in three related parts:-
- How can one key be related to another key?
- Is there a metric describing the degree of relationship?
- Is there a link between the nature of keys' relationships and any specific cryptographic functions?
keys
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
$endgroup$
add a comment |
$begingroup$
We talk of related keys and related key attacks, but what is a 'related key'? So in three related parts:-
- How can one key be related to another key?
- Is there a metric describing the degree of relationship?
- Is there a link between the nature of keys' relationships and any specific cryptographic functions?
keys
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
$endgroup$
We talk of related keys and related key attacks, but what is a 'related key'? So in three related parts:-
- How can one key be related to another key?
- Is there a metric describing the degree of relationship?
- Is there a link between the nature of keys' relationships and any specific cryptographic functions?
keys
keys
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
asked 4 hours ago
Paul UszakPaul Uszak
7,22111535
7,22111535
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
Related keys are keys with any mathematical relationship that leads to exploitability in the cipher. This can be a simple relationship, such as having many bits in common. This was the case with RC4 when used in WEP, where each packet is encrypted with a key composed of 104 bits of unchanging key material and 24 bits for an IV, leading to the FMS attack. The relationship might be more subtle, with keys sharing a complex differential relationship, as with the related key boomerang attacks in 256-bit AES.
A trivial example of related keys would be two keys which cause a collision in the cipher's key schedule, resulting in distinct keys having a relationship that allow them to resolve to the same round keys. Full collisions in the key schedule result in equivalent keys, such as with TEA where certain flipped bits in the key cause collisions. Related key attacks often (but not always) are caused by a weakness in the key schedule. A good cipher should not suffer from related key attacks, and all keys should be equally good.
It may be tempting to think that related key attacks don't really matter. After all, any good protocol will have each and every new key completely distinct from each previous key. However, the problem of related key attacks comes up if the cipher primitive is later used in other constructions, such as for a hash function. This was the case with TEA which was abused by Microsoft in the Xbox as a hash. This is an issue because many hash constructions such as Davies–Meyer use each (attacker-controlled) message block as a key. Related keys in the underlying block cipher could then manifest as collisions.
The most severe related key attacks are ones where keys can be related by chance or due to the way they are used in the protocol. It's more common that the relationships are so complex as to be very unlikely to ever arrive by chance and typically need an attacker to influence the choice of keys. As mentioned above, this is typically an issue when a block cipher is used to construct a hash function.
answered 3 hours ago
forestforest
3,3091236
$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%2f66868%2fwhat-is-a-related-key%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$
Related keys are keys with any mathematical relationship that leads to exploitability in the cipher. This can be a simple relationship, such as having many bits in common. This was the case with RC4 when used in WEP, where each packet is encrypted with a key composed of 104 bits of unchanging key material and 24 bits for an IV, leading to the FMS attack. The relationship might be more subtle, with keys sharing a complex differential relationship, as with the related key boomerang attacks in 256-bit AES.
A trivial example of related keys would be two keys which cause a collision in the cipher's key schedule, resulting in distinct keys having a relationship that allow them to resolve to the same round keys. Full collisions in the key schedule result in equivalent keys, such as with TEA where certain flipped bits in the key cause collisions. Related key attacks often (but not always) are caused by a weakness in the key schedule. A good cipher should not suffer from related key attacks, and all keys should be equally good.
It may be tempting to think that related key attacks don't really matter. After all, any good protocol will have each and every new key completely distinct from each previous key. However, the problem of related key attacks comes up if the cipher primitive is later used in other constructions, such as for a hash function. This was the case with TEA which was abused by Microsoft in the Xbox as a hash. This is an issue because many hash constructions such as Davies–Meyer use each (attacker-controlled) message block as a key. Related keys in the underlying block cipher could then manifest as collisions.
The most severe related key attacks are ones where keys can be related by chance or due to the way they are used in the protocol. It's more common that the relationships are so complex as to be very unlikely to ever arrive by chance and typically need an attacker to influence the choice of keys. As mentioned above, this is typically an issue when a block cipher is used to construct a hash function.
answered 3 hours ago
forestforest
3,3091236
$endgroup$
add a comment |
$begingroup$
Related keys are keys with any mathematical relationship that leads to exploitability in the cipher. This can be a simple relationship, such as having many bits in common. This was the case with RC4 when used in WEP, where each packet is encrypted with a key composed of 104 bits of unchanging key material and 24 bits for an IV, leading to the FMS attack. The relationship might be more subtle, with keys sharing a complex differential relationship, as with the related key boomerang attacks in 256-bit AES.
A trivial example of related keys would be two keys which cause a collision in the cipher's key schedule, resulting in distinct keys having a relationship that allow them to resolve to the same round keys. Full collisions in the key schedule result in equivalent keys, such as with TEA where certain flipped bits in the key cause collisions. Related key attacks often (but not always) are caused by a weakness in the key schedule. A good cipher should not suffer from related key attacks, and all keys should be equally good.
It may be tempting to think that related key attacks don't really matter. After all, any good protocol will have each and every new key completely distinct from each previous key. However, the problem of related key attacks comes up if the cipher primitive is later used in other constructions, such as for a hash function. This was the case with TEA which was abused by Microsoft in the Xbox as a hash. This is an issue because many hash constructions such as Davies–Meyer use each (attacker-controlled) message block as a key. Related keys in the underlying block cipher could then manifest as collisions.
The most severe related key attacks are ones where keys can be related by chance or due to the way they are used in the protocol. It's more common that the relationships are so complex as to be very unlikely to ever arrive by chance and typically need an attacker to influence the choice of keys. As mentioned above, this is typically an issue when a block cipher is used to construct a hash function.
answered 3 hours ago
forestforest
3,3091236
$endgroup$
add a comment |
$begingroup$
Related keys are keys with any mathematical relationship that leads to exploitability in the cipher. This can be a simple relationship, such as having many bits in common. This was the case with RC4 when used in WEP, where each packet is encrypted with a key composed of 104 bits of unchanging key material and 24 bits for an IV, leading to the FMS attack. The relationship might be more subtle, with keys sharing a complex differential relationship, as with the related key boomerang attacks in 256-bit AES.
A trivial example of related keys would be two keys which cause a collision in the cipher's key schedule, resulting in distinct keys having a relationship that allow them to resolve to the same round keys. Full collisions in the key schedule result in equivalent keys, such as with TEA where certain flipped bits in the key cause collisions. Related key attacks often (but not always) are caused by a weakness in the key schedule. A good cipher should not suffer from related key attacks, and all keys should be equally good.
It may be tempting to think that related key attacks don't really matter. After all, any good protocol will have each and every new key completely distinct from each previous key. However, the problem of related key attacks comes up if the cipher primitive is later used in other constructions, such as for a hash function. This was the case with TEA which was abused by Microsoft in the Xbox as a hash. This is an issue because many hash constructions such as Davies–Meyer use each (attacker-controlled) message block as a key. Related keys in the underlying block cipher could then manifest as collisions.
The most severe related key attacks are ones where keys can be related by chance or due to the way they are used in the protocol. It's more common that the relationships are so complex as to be very unlikely to ever arrive by chance and typically need an attacker to influence the choice of keys. As mentioned above, this is typically an issue when a block cipher is used to construct a hash function.
answered 3 hours ago
forestforest
3,3091236
$endgroup$
Related keys are keys with any mathematical relationship that leads to exploitability in the cipher. This can be a simple relationship, such as having many bits in common. This was the case with RC4 when used in WEP, where each packet is encrypted with a key composed of 104 bits of unchanging key material and 24 bits for an IV, leading to the FMS attack. The relationship might be more subtle, with keys sharing a complex differential relationship, as with the related key boomerang attacks in 256-bit AES.
A trivial example of related keys would be two keys which cause a collision in the cipher's key schedule, resulting in distinct keys having a relationship that allow them to resolve to the same round keys. Full collisions in the key schedule result in equivalent keys, such as with TEA where certain flipped bits in the key cause collisions. Related key attacks often (but not always) are caused by a weakness in the key schedule. A good cipher should not suffer from related key attacks, and all keys should be equally good.
It may be tempting to think that related key attacks don't really matter. After all, any good protocol will have each and every new key completely distinct from each previous key. However, the problem of related key attacks comes up if the cipher primitive is later used in other constructions, such as for a hash function. This was the case with TEA which was abused by Microsoft in the Xbox as a hash. This is an issue because many hash constructions such as Davies–Meyer use each (attacker-controlled) message block as a key. Related keys in the underlying block cipher could then manifest as collisions.
The most severe related key attacks are ones where keys can be related by chance or due to the way they are used in the protocol. It's more common that the relationships are so complex as to be very unlikely to ever arrive by chance and typically need an attacker to influence the choice of keys. As mentioned above, this is typically an issue when a block cipher is used to construct a hash function.
answered 3 hours ago
forestforest
3,3091236
edited 2 hours ago
answered 3 hours ago
forestforest
3,3091236
answered 3 hours ago
forestforest
3,3091236
answered 3 hours ago
forestforest
3,3091236
3,3091236
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%2f66868%2fwhat-is-a-related-key%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
