Security of AES after key expansion 4-MB with ECB and CBC
up vote
2
down vote
favorite
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 at 13:19
kelalaka
4,62921837
asked Nov 27 at 13:07
barium borat
111
add a comment |
up vote
2
down vote
favorite
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 at 13:19
kelalaka
4,62921837
asked Nov 27 at 13:07
barium borat
111
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 at 14:36
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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 at 13:19
kelalaka
4,62921837
asked Nov 27 at 13:07
barium borat
111
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 at 13:19
kelalaka
4,62921837
asked Nov 27 at 13:07
barium borat
111
edited Nov 27 at 13:19
kelalaka
4,62921837
asked Nov 27 at 13:07
barium borat
111
edited Nov 27 at 13:19
kelalaka
4,62921837
edited Nov 27 at 13:19
kelalaka
4,62921837
edited Nov 27 at 13:19
kelalaka
4,62921837
4,62921837
asked Nov 27 at 13:07
barium borat
111
asked Nov 27 at 13:07
barium borat
111
asked Nov 27 at 13:07
barium borat
111
111
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 at 14:36
add a comment |
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 at 14:36
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 at 14:36
Related: crypto.stackexchange.com/questions/30251/…
– Ilmari Karonen
Nov 27 at 14:36
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
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 at 13:20
Maarten Bodewes
52.1k676190
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 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 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 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 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 at 15:22
|
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
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 at 13:20
Maarten Bodewes
52.1k676190
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 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 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 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 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 at 15:22
|
show 1 more comment
up vote
3
down vote
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 at 13:20
Maarten Bodewes
52.1k676190
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 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 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 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 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 at 15:22
|
show 1 more comment
up vote
3
down vote
up vote
3
down vote
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 at 13:20
Maarten Bodewes
52.1k676190
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 at 13:20
Maarten Bodewes
52.1k676190
edited Nov 27 at 13:40
answered Nov 27 at 13:20
Maarten Bodewes
52.1k676190
answered Nov 27 at 13:20
Maarten Bodewes
52.1k676190
answered Nov 27 at 13:20
Maarten Bodewes
52.1k676190
52.1k676190
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 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 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 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 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 at 15:22
|
show 1 more comment
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 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 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 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 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 at 15:22
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 at 14:13
If a new key generated for every video stream (file), does ECB still problematic?
– kelalaka
Nov 27 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 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 at 14:25
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 at 15:05
@kelalaka Have you looked at the penguin? That Maarten linked to?
– Martin Bonner
Nov 27 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 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 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 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 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 at 14:36