Security of AES after key expansion 4-MB with ECB and CBC
My question is,
how does the security depend or change if I encrypt with AES-128 in total 4-MB of Data?
- With Electronic Code Book Mode and
- Cipher Block Chaining Mode ?
- Does an adversary still need $2^{126}$ tries (like Wikipedia suggests) to guess the key or is it less (which in my opinion it should)?
The encrypted data would be a videostream.
encryption aes symmetric cbc ecb
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
asked Nov 27 '18 at 13:07
barium borat
161
add a comment |
My question is,
how does the security depend or change if I encrypt with AES-128 in total 4-MB of Data?
- With Electronic Code Book Mode and
- Cipher Block Chaining Mode ?
- Does an adversary still need $2^{126}$ tries (like Wikipedia suggests) to guess the key or is it less (which in my opinion it should)?
The encrypted data would be a videostream.
encryption aes symmetric cbc ecb
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
asked Nov 27 '18 at 13:07
barium borat
161
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 '18 at 14:36
add a comment |
My question is,
how does the security depend or change if I encrypt with AES-128 in total 4-MB of Data?
- With Electronic Code Book Mode and
- Cipher Block Chaining Mode ?
- Does an adversary still need $2^{126}$ tries (like Wikipedia suggests) to guess the key or is it less (which in my opinion it should)?
The encrypted data would be a videostream.
encryption aes symmetric cbc ecb
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
asked Nov 27 '18 at 13:07
barium borat
161
My question is,
how does the security depend or change if I encrypt with AES-128 in total 4-MB of Data?
- With Electronic Code Book Mode and
- Cipher Block Chaining Mode ?
- Does an adversary still need $2^{126}$ tries (like Wikipedia suggests) to guess the key or is it less (which in my opinion it should)?
The encrypted data would be a videostream.
encryption aes symmetric cbc ecb
encryption aes symmetric cbc ecb
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
asked Nov 27 '18 at 13:07
barium borat
161
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
asked Nov 27 '18 at 13:07
barium borat
161
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
edited Nov 27 '18 at 13:19
kelalaka
5,57722040
5,57722040
asked Nov 27 '18 at 13:07
barium borat
161
asked Nov 27 '18 at 13:07
barium borat
161
asked Nov 27 '18 at 13:07
barium borat
161
161
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 '18 at 14:36
add a comment |
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 '18 at 14:36
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 '18 at 14:36
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 '18 at 14:36
add a comment |
1 Answer
1
active
oldest
votes
A videostream should probably not be encrypted with either ECB or CBC.
ECB is insecure for almost anything and it should not / can not be used to turn a block cipher in a secure cipher. This is clearly shown even in the Wikipedia description of the mode: find the penguin.
CBC is secure to keep data confidential. It is, however, susceptible to padding oracle attacks when not used correctly - especially in real time communication. It also doesn't allow e.g. caching of the key stream or parallel encryption, so the performance may be subpar as well. And although it does support seeking, it does require the user to retrieve the ciphertext block before the one that needs decryption.
This is why commonly CTR mode is used instead. Sometimes CTR mode is used in combination with a MAC to offer fast authentication and integrity of the ciphertext. , e.g. GCM mode. GCM mode, however, does undo some of the benefits of CTR mode.
However, probably the most common methods of wrapping a stream is to perform TLS. It does have some overhead, but at least well reviewed implementations exists. It depends if it fits your need.
The amount of tries to get to the key will always be in the neighborhood of $2^{127}$ tries for a (largely) unbroken cipher such as AES. The key is protected by the block cipher itself, rather than the mode of operation.
However, the security of the key only is only part of the security of the cipher. It is perfectly possible for a mode of operation to leak information on the plaintext even if the key is kept perfectly secure. The ECB penguin is a prime example of that. Another is CTR mode with a repeated IV, which turns the cipher into a "many-time pad".
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 '18 at 14:13
4
@kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.)
– DRF
Nov 27 '18 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 '18 at 15:05
1
@MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem?
– kelalaka
Nov 27 '18 at 15:17
4
@kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case.
– Martin Bonner
Nov 27 '18 at 15:22
|
show 1 more 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%2f64351%2fsecurity-of-aes-after-key-expansion-4-mb-with-ecb-and-cbc%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
A videostream should probably not be encrypted with either ECB or CBC.
ECB is insecure for almost anything and it should not / can not be used to turn a block cipher in a secure cipher. This is clearly shown even in the Wikipedia description of the mode: find the penguin.
CBC is secure to keep data confidential. It is, however, susceptible to padding oracle attacks when not used correctly - especially in real time communication. It also doesn't allow e.g. caching of the key stream or parallel encryption, so the performance may be subpar as well. And although it does support seeking, it does require the user to retrieve the ciphertext block before the one that needs decryption.
This is why commonly CTR mode is used instead. Sometimes CTR mode is used in combination with a MAC to offer fast authentication and integrity of the ciphertext. , e.g. GCM mode. GCM mode, however, does undo some of the benefits of CTR mode.
However, probably the most common methods of wrapping a stream is to perform TLS. It does have some overhead, but at least well reviewed implementations exists. It depends if it fits your need.
The amount of tries to get to the key will always be in the neighborhood of $2^{127}$ tries for a (largely) unbroken cipher such as AES. The key is protected by the block cipher itself, rather than the mode of operation.
However, the security of the key only is only part of the security of the cipher. It is perfectly possible for a mode of operation to leak information on the plaintext even if the key is kept perfectly secure. The ECB penguin is a prime example of that. Another is CTR mode with a repeated IV, which turns the cipher into a "many-time pad".
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 '18 at 14:13
4
@kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.)
– DRF
Nov 27 '18 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 '18 at 15:05
1
@MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem?
– kelalaka
Nov 27 '18 at 15:17
4
@kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case.
– Martin Bonner
Nov 27 '18 at 15:22
|
show 1 more comment
A videostream should probably not be encrypted with either ECB or CBC.
ECB is insecure for almost anything and it should not / can not be used to turn a block cipher in a secure cipher. This is clearly shown even in the Wikipedia description of the mode: find the penguin.
CBC is secure to keep data confidential. It is, however, susceptible to padding oracle attacks when not used correctly - especially in real time communication. It also doesn't allow e.g. caching of the key stream or parallel encryption, so the performance may be subpar as well. And although it does support seeking, it does require the user to retrieve the ciphertext block before the one that needs decryption.
This is why commonly CTR mode is used instead. Sometimes CTR mode is used in combination with a MAC to offer fast authentication and integrity of the ciphertext. , e.g. GCM mode. GCM mode, however, does undo some of the benefits of CTR mode.
However, probably the most common methods of wrapping a stream is to perform TLS. It does have some overhead, but at least well reviewed implementations exists. It depends if it fits your need.
The amount of tries to get to the key will always be in the neighborhood of $2^{127}$ tries for a (largely) unbroken cipher such as AES. The key is protected by the block cipher itself, rather than the mode of operation.
However, the security of the key only is only part of the security of the cipher. It is perfectly possible for a mode of operation to leak information on the plaintext even if the key is kept perfectly secure. The ECB penguin is a prime example of that. Another is CTR mode with a repeated IV, which turns the cipher into a "many-time pad".
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 '18 at 14:13
4
@kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.)
– DRF
Nov 27 '18 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 '18 at 15:05
1
@MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem?
– kelalaka
Nov 27 '18 at 15:17
4
@kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case.
– Martin Bonner
Nov 27 '18 at 15:22
|
show 1 more comment
A videostream should probably not be encrypted with either ECB or CBC.
ECB is insecure for almost anything and it should not / can not be used to turn a block cipher in a secure cipher. This is clearly shown even in the Wikipedia description of the mode: find the penguin.
CBC is secure to keep data confidential. It is, however, susceptible to padding oracle attacks when not used correctly - especially in real time communication. It also doesn't allow e.g. caching of the key stream or parallel encryption, so the performance may be subpar as well. And although it does support seeking, it does require the user to retrieve the ciphertext block before the one that needs decryption.
This is why commonly CTR mode is used instead. Sometimes CTR mode is used in combination with a MAC to offer fast authentication and integrity of the ciphertext. , e.g. GCM mode. GCM mode, however, does undo some of the benefits of CTR mode.
However, probably the most common methods of wrapping a stream is to perform TLS. It does have some overhead, but at least well reviewed implementations exists. It depends if it fits your need.
The amount of tries to get to the key will always be in the neighborhood of $2^{127}$ tries for a (largely) unbroken cipher such as AES. The key is protected by the block cipher itself, rather than the mode of operation.
However, the security of the key only is only part of the security of the cipher. It is perfectly possible for a mode of operation to leak information on the plaintext even if the key is kept perfectly secure. The ECB penguin is a prime example of that. Another is CTR mode with a repeated IV, which turns the cipher into a "many-time pad".
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
A videostream should probably not be encrypted with either ECB or CBC.
ECB is insecure for almost anything and it should not / can not be used to turn a block cipher in a secure cipher. This is clearly shown even in the Wikipedia description of the mode: find the penguin.
CBC is secure to keep data confidential. It is, however, susceptible to padding oracle attacks when not used correctly - especially in real time communication. It also doesn't allow e.g. caching of the key stream or parallel encryption, so the performance may be subpar as well. And although it does support seeking, it does require the user to retrieve the ciphertext block before the one that needs decryption.
This is why commonly CTR mode is used instead. Sometimes CTR mode is used in combination with a MAC to offer fast authentication and integrity of the ciphertext. , e.g. GCM mode. GCM mode, however, does undo some of the benefits of CTR mode.
However, probably the most common methods of wrapping a stream is to perform TLS. It does have some overhead, but at least well reviewed implementations exists. It depends if it fits your need.
The amount of tries to get to the key will always be in the neighborhood of $2^{127}$ tries for a (largely) unbroken cipher such as AES. The key is protected by the block cipher itself, rather than the mode of operation.
However, the security of the key only is only part of the security of the cipher. It is perfectly possible for a mode of operation to leak information on the plaintext even if the key is kept perfectly secure. The ECB penguin is a prime example of that. Another is CTR mode with a repeated IV, which turns the cipher into a "many-time pad".
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
edited Nov 27 '18 at 13:40
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
answered Nov 27 '18 at 13:20
Maarten Bodewes♦
53k677191
53k677191
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 '18 at 14:13
4
@kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.)
– DRF
Nov 27 '18 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 '18 at 15:05
1
@MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem?
– kelalaka
Nov 27 '18 at 15:17
4
@kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case.
– Martin Bonner
Nov 27 '18 at 15:22
|
show 1 more comment
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 '18 at 14:13
4
@kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.)
– DRF
Nov 27 '18 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 '18 at 15:05
1
@MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem?
– kelalaka
Nov 27 '18 at 15:17
4
@kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case.
– Martin Bonner
Nov 27 '18 at 15:22
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 '18 at 14:13
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 '18 at 14:13
4
4
@kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.)
– DRF
Nov 27 '18 at 14:25
@kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.)
– DRF
Nov 27 '18 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 '18 at 15:05
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 '18 at 15:05
1
1
@MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem?
– kelalaka
Nov 27 '18 at 15:17
@MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem?
– kelalaka
Nov 27 '18 at 15:17
4
4
@kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case.
– Martin Bonner
Nov 27 '18 at 15:22
@kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case.
– Martin Bonner
Nov 27 '18 at 15:22
|
show 1 more 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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.
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%2f64351%2fsecurity-of-aes-after-key-expansion-4-mb-with-ecb-and-cbc%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
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 '18 at 14:36