Any point using CMAC with AES-256?
$begingroup$
As we know, AES-256 is a block cipher with 256-bit key and 128-bit block size.
The CMAC message authentication code outputs tag length equal to block cipher block size - thus 128 bits with AES. And this provides an assurence that only 1 in 2^128 attempts in forgery may possibly succeed.
So is there any point using a 256-bit key as may be the case with AES-256?
aes cmac
$endgroup$
add a comment |
$begingroup$
As we know, AES-256 is a block cipher with 256-bit key and 128-bit block size.
The CMAC message authentication code outputs tag length equal to block cipher block size - thus 128 bits with AES. And this provides an assurence that only 1 in 2^128 attempts in forgery may possibly succeed.
So is there any point using a 256-bit key as may be the case with AES-256?
aes cmac
$endgroup$
$begingroup$
If you use AES-128 an attacker may find (in theory) brute-forcing the 128-bit key to be easier than trying the random forging approach, especially if it's a protocol like TLS that rekeys after a single MAC fail.
$endgroup$
– SEJPM♦
Dec 22 '18 at 15:05
add a comment |
$begingroup$
As we know, AES-256 is a block cipher with 256-bit key and 128-bit block size.
The CMAC message authentication code outputs tag length equal to block cipher block size - thus 128 bits with AES. And this provides an assurence that only 1 in 2^128 attempts in forgery may possibly succeed.
So is there any point using a 256-bit key as may be the case with AES-256?
aes cmac
$endgroup$
As we know, AES-256 is a block cipher with 256-bit key and 128-bit block size.
The CMAC message authentication code outputs tag length equal to block cipher block size - thus 128 bits with AES. And this provides an assurence that only 1 in 2^128 attempts in forgery may possibly succeed.
So is there any point using a 256-bit key as may be the case with AES-256?
aes cmac
aes cmac
asked Dec 22 '18 at 14:31
DannyNiuDannyNiu
1,2611628
1,2611628
$begingroup$
If you use AES-128 an attacker may find (in theory) brute-forcing the 128-bit key to be easier than trying the random forging approach, especially if it's a protocol like TLS that rekeys after a single MAC fail.
$endgroup$
– SEJPM♦
Dec 22 '18 at 15:05
add a comment |
$begingroup$
If you use AES-128 an attacker may find (in theory) brute-forcing the 128-bit key to be easier than trying the random forging approach, especially if it's a protocol like TLS that rekeys after a single MAC fail.
$endgroup$
– SEJPM♦
Dec 22 '18 at 15:05
$begingroup$
If you use AES-128 an attacker may find (in theory) brute-forcing the 128-bit key to be easier than trying the random forging approach, especially if it's a protocol like TLS that rekeys after a single MAC fail.
$endgroup$
– SEJPM♦
Dec 22 '18 at 15:05
$begingroup$
If you use AES-128 an attacker may find (in theory) brute-forcing the 128-bit key to be easier than trying the random forging approach, especially if it's a protocol like TLS that rekeys after a single MAC fail.
$endgroup$
– SEJPM♦
Dec 22 '18 at 15:05
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
Brute forcing ciphertext an offline attack, while attacking the authentication tag (the result of the CMAC-calculation) is an online attack: it requires an active oracle. That is: you can try and break the confidentiality of a message on your own PC network of computers. However, you need to send many ciphertext (including authentication tag) to a receiver to see if a guessed tag is correct or not and an invalid ciphertext is accepted (to test if a message is successfully forged). Generally you only get one oracle, and the speed of this oracle is usually limited (e.g. by networking speeds).
If an authentication tag is not accepted then that doesn't give any information to an attacker if the next message changes. This would for instance be the case if a unique sequence number is included in the messages (although usually the authentication tag is verified earlier, so oracle attacks would be possible). Furthermore, many protocols will break a session and re-establish the session keys if an incorrect authentication tag is received.
In conclusion: attacking an authentication tag is much harder than breaking a cipher, even if the order of the attack is the same. Because of this it makes sense to increase the key size even if the tag size stays the same.
If you need more than 128 bits of security is of course another question; 128 bits seems plenty as long as quantum computers are not available. 256 bit encryption should be considered for messages that require long-term protection.
$endgroup$
add a comment |
$begingroup$
From rfc4493 (The AES-CMAC Algorithm);
The security provided by AES-CMAC is built on the strong cryptographic algorithm AES. However, as is true with any cryptographic algorithm, part of its strength lies in the secret key, K, and the correctness of the implementation in all of the participating systems.
As the standard states; the longer key the harder to forgery. However, the standard is not mentioning about using the AES with 256-bit key.
Your suggestion to increase the key size to 256-bit will definitely make the brute-force infeasible for a long time.
To forge a message by trying every tag is measured by the tag space, in this case, the attacker needs to attack $128$-bit and this is always same for AES.
$endgroup$
$begingroup$
I'm finding your answer here a bit hard to follow. In particular, in the last paragraph you write about "the case of the brute force", even though both trying all $2^{256}$ keys and trying all $2^{128}$ tags would generally be considered brute force attacks.
$endgroup$
– Ilmari Karonen
Dec 22 '18 at 19:46
$begingroup$
@IlmariKaronen clear now?
$endgroup$
– kelalaka
Dec 22 '18 at 20:05
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%2f66050%2fany-point-using-cmac-with-aes-256%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$
Brute forcing ciphertext an offline attack, while attacking the authentication tag (the result of the CMAC-calculation) is an online attack: it requires an active oracle. That is: you can try and break the confidentiality of a message on your own PC network of computers. However, you need to send many ciphertext (including authentication tag) to a receiver to see if a guessed tag is correct or not and an invalid ciphertext is accepted (to test if a message is successfully forged). Generally you only get one oracle, and the speed of this oracle is usually limited (e.g. by networking speeds).
If an authentication tag is not accepted then that doesn't give any information to an attacker if the next message changes. This would for instance be the case if a unique sequence number is included in the messages (although usually the authentication tag is verified earlier, so oracle attacks would be possible). Furthermore, many protocols will break a session and re-establish the session keys if an incorrect authentication tag is received.
In conclusion: attacking an authentication tag is much harder than breaking a cipher, even if the order of the attack is the same. Because of this it makes sense to increase the key size even if the tag size stays the same.
If you need more than 128 bits of security is of course another question; 128 bits seems plenty as long as quantum computers are not available. 256 bit encryption should be considered for messages that require long-term protection.
$endgroup$
add a comment |
$begingroup$
Brute forcing ciphertext an offline attack, while attacking the authentication tag (the result of the CMAC-calculation) is an online attack: it requires an active oracle. That is: you can try and break the confidentiality of a message on your own PC network of computers. However, you need to send many ciphertext (including authentication tag) to a receiver to see if a guessed tag is correct or not and an invalid ciphertext is accepted (to test if a message is successfully forged). Generally you only get one oracle, and the speed of this oracle is usually limited (e.g. by networking speeds).
If an authentication tag is not accepted then that doesn't give any information to an attacker if the next message changes. This would for instance be the case if a unique sequence number is included in the messages (although usually the authentication tag is verified earlier, so oracle attacks would be possible). Furthermore, many protocols will break a session and re-establish the session keys if an incorrect authentication tag is received.
In conclusion: attacking an authentication tag is much harder than breaking a cipher, even if the order of the attack is the same. Because of this it makes sense to increase the key size even if the tag size stays the same.
If you need more than 128 bits of security is of course another question; 128 bits seems plenty as long as quantum computers are not available. 256 bit encryption should be considered for messages that require long-term protection.
$endgroup$
add a comment |
$begingroup$
Brute forcing ciphertext an offline attack, while attacking the authentication tag (the result of the CMAC-calculation) is an online attack: it requires an active oracle. That is: you can try and break the confidentiality of a message on your own PC network of computers. However, you need to send many ciphertext (including authentication tag) to a receiver to see if a guessed tag is correct or not and an invalid ciphertext is accepted (to test if a message is successfully forged). Generally you only get one oracle, and the speed of this oracle is usually limited (e.g. by networking speeds).
If an authentication tag is not accepted then that doesn't give any information to an attacker if the next message changes. This would for instance be the case if a unique sequence number is included in the messages (although usually the authentication tag is verified earlier, so oracle attacks would be possible). Furthermore, many protocols will break a session and re-establish the session keys if an incorrect authentication tag is received.
In conclusion: attacking an authentication tag is much harder than breaking a cipher, even if the order of the attack is the same. Because of this it makes sense to increase the key size even if the tag size stays the same.
If you need more than 128 bits of security is of course another question; 128 bits seems plenty as long as quantum computers are not available. 256 bit encryption should be considered for messages that require long-term protection.
$endgroup$
Brute forcing ciphertext an offline attack, while attacking the authentication tag (the result of the CMAC-calculation) is an online attack: it requires an active oracle. That is: you can try and break the confidentiality of a message on your own PC network of computers. However, you need to send many ciphertext (including authentication tag) to a receiver to see if a guessed tag is correct or not and an invalid ciphertext is accepted (to test if a message is successfully forged). Generally you only get one oracle, and the speed of this oracle is usually limited (e.g. by networking speeds).
If an authentication tag is not accepted then that doesn't give any information to an attacker if the next message changes. This would for instance be the case if a unique sequence number is included in the messages (although usually the authentication tag is verified earlier, so oracle attacks would be possible). Furthermore, many protocols will break a session and re-establish the session keys if an incorrect authentication tag is received.
In conclusion: attacking an authentication tag is much harder than breaking a cipher, even if the order of the attack is the same. Because of this it makes sense to increase the key size even if the tag size stays the same.
If you need more than 128 bits of security is of course another question; 128 bits seems plenty as long as quantum computers are not available. 256 bit encryption should be considered for messages that require long-term protection.
edited Dec 22 '18 at 17:13
answered Dec 22 '18 at 17:07
Maarten Bodewes♦Maarten Bodewes
55.1k679196
55.1k679196
add a comment |
add a comment |
$begingroup$
From rfc4493 (The AES-CMAC Algorithm);
The security provided by AES-CMAC is built on the strong cryptographic algorithm AES. However, as is true with any cryptographic algorithm, part of its strength lies in the secret key, K, and the correctness of the implementation in all of the participating systems.
As the standard states; the longer key the harder to forgery. However, the standard is not mentioning about using the AES with 256-bit key.
Your suggestion to increase the key size to 256-bit will definitely make the brute-force infeasible for a long time.
To forge a message by trying every tag is measured by the tag space, in this case, the attacker needs to attack $128$-bit and this is always same for AES.
$endgroup$
$begingroup$
I'm finding your answer here a bit hard to follow. In particular, in the last paragraph you write about "the case of the brute force", even though both trying all $2^{256}$ keys and trying all $2^{128}$ tags would generally be considered brute force attacks.
$endgroup$
– Ilmari Karonen
Dec 22 '18 at 19:46
$begingroup$
@IlmariKaronen clear now?
$endgroup$
– kelalaka
Dec 22 '18 at 20:05
add a comment |
$begingroup$
From rfc4493 (The AES-CMAC Algorithm);
The security provided by AES-CMAC is built on the strong cryptographic algorithm AES. However, as is true with any cryptographic algorithm, part of its strength lies in the secret key, K, and the correctness of the implementation in all of the participating systems.
As the standard states; the longer key the harder to forgery. However, the standard is not mentioning about using the AES with 256-bit key.
Your suggestion to increase the key size to 256-bit will definitely make the brute-force infeasible for a long time.
To forge a message by trying every tag is measured by the tag space, in this case, the attacker needs to attack $128$-bit and this is always same for AES.
$endgroup$
$begingroup$
I'm finding your answer here a bit hard to follow. In particular, in the last paragraph you write about "the case of the brute force", even though both trying all $2^{256}$ keys and trying all $2^{128}$ tags would generally be considered brute force attacks.
$endgroup$
– Ilmari Karonen
Dec 22 '18 at 19:46
$begingroup$
@IlmariKaronen clear now?
$endgroup$
– kelalaka
Dec 22 '18 at 20:05
add a comment |
$begingroup$
From rfc4493 (The AES-CMAC Algorithm);
The security provided by AES-CMAC is built on the strong cryptographic algorithm AES. However, as is true with any cryptographic algorithm, part of its strength lies in the secret key, K, and the correctness of the implementation in all of the participating systems.
As the standard states; the longer key the harder to forgery. However, the standard is not mentioning about using the AES with 256-bit key.
Your suggestion to increase the key size to 256-bit will definitely make the brute-force infeasible for a long time.
To forge a message by trying every tag is measured by the tag space, in this case, the attacker needs to attack $128$-bit and this is always same for AES.
$endgroup$
From rfc4493 (The AES-CMAC Algorithm);
The security provided by AES-CMAC is built on the strong cryptographic algorithm AES. However, as is true with any cryptographic algorithm, part of its strength lies in the secret key, K, and the correctness of the implementation in all of the participating systems.
As the standard states; the longer key the harder to forgery. However, the standard is not mentioning about using the AES with 256-bit key.
Your suggestion to increase the key size to 256-bit will definitely make the brute-force infeasible for a long time.
To forge a message by trying every tag is measured by the tag space, in this case, the attacker needs to attack $128$-bit and this is always same for AES.
edited Dec 22 '18 at 20:05
answered Dec 22 '18 at 16:11
kelalakakelalaka
8,14322351
8,14322351
$begingroup$
I'm finding your answer here a bit hard to follow. In particular, in the last paragraph you write about "the case of the brute force", even though both trying all $2^{256}$ keys and trying all $2^{128}$ tags would generally be considered brute force attacks.
$endgroup$
– Ilmari Karonen
Dec 22 '18 at 19:46
$begingroup$
@IlmariKaronen clear now?
$endgroup$
– kelalaka
Dec 22 '18 at 20:05
add a comment |
$begingroup$
I'm finding your answer here a bit hard to follow. In particular, in the last paragraph you write about "the case of the brute force", even though both trying all $2^{256}$ keys and trying all $2^{128}$ tags would generally be considered brute force attacks.
$endgroup$
– Ilmari Karonen
Dec 22 '18 at 19:46
$begingroup$
@IlmariKaronen clear now?
$endgroup$
– kelalaka
Dec 22 '18 at 20:05
$begingroup$
I'm finding your answer here a bit hard to follow. In particular, in the last paragraph you write about "the case of the brute force", even though both trying all $2^{256}$ keys and trying all $2^{128}$ tags would generally be considered brute force attacks.
$endgroup$
– Ilmari Karonen
Dec 22 '18 at 19:46
$begingroup$
I'm finding your answer here a bit hard to follow. In particular, in the last paragraph you write about "the case of the brute force", even though both trying all $2^{256}$ keys and trying all $2^{128}$ tags would generally be considered brute force attacks.
$endgroup$
– Ilmari Karonen
Dec 22 '18 at 19:46
$begingroup$
@IlmariKaronen clear now?
$endgroup$
– kelalaka
Dec 22 '18 at 20:05
$begingroup$
@IlmariKaronen clear now?
$endgroup$
– kelalaka
Dec 22 '18 at 20:05
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%2f66050%2fany-point-using-cmac-with-aes-256%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$
If you use AES-128 an attacker may find (in theory) brute-forcing the 128-bit key to be easier than trying the random forging approach, especially if it's a protocol like TLS that rekeys after a single MAC fail.
$endgroup$
– SEJPM♦
Dec 22 '18 at 15:05