AES-CBC streaming configuration IV usageIs CBC mode with a fixed IV secure, if a counter is prepended to the plaintext?Implementing PKCS#7 Padding on a Stream of Unknown Length?AES: Is it safe to encrypt same cleartext with same key but with million diferent IV?Is it safe to AES-CBC and AES-CMAC both using the same key?Encryption(AES) and verification per messageSelecting an appropriate key for HMACUsing SHA512 (or other hash) for message authenticationWhat is the correct way to implement PBKDF2 + AES CBC + HMAC?Are tags longer than 128 bit possible for AES-256-CCM and AES-256-GCM?Deciding on an AES cipher mode for chunked dataAES CBC MAC Generation
How does the Moon's gravity affect Earth's oceans despite Earth's stronger gravitational pull?
Will some rockets really collapse under their own weight?
How do I pass a "list of lists" as the argument to a function of the form F[x,y]?
Is nullptr falsy?
Output with the same length always
What's the relationship betweeen MS-DOS and XENIX?
What are the advantages of this gold finger shape?
When does The Truman Show take place?
How to gracefully leave a company you helped start?
Are there liquid fueled rocket boosters having coaxial fuel/oxidizer tanks?
If a person claims to know anything could it be disproven by saying 'prove that we are not in a simulation'?
Output the list of musical notes
Short comic about alien explorers visiting an abandoned world with giant statues that turn out to be alive but move very slowly
Is this bar slide trick shown on Cheers real or a visual effect?
What does 〇〇〇〇 mean when combined with おじさん？
Is this really better analyzed in G minor than in Bb?
What would cause a nuclear power plant to break down after 2000 years, but not sooner?
What is the question mark?
Are there any cons in using rounded corners for bar graphs?
Why do so many people play out of turn on the last lead?
Problem with GFCI at start of circuit with both lights and two receptacles
global variant of csname…endcsname
What ways are there to share spells between characters, besides a Ring of Spell Storing?
Build a mob of suspiciously happy lenny faces ( ͡° ͜ʖ ͡°)
AES-CBC streaming configuration IV usage
Is CBC mode with a fixed IV secure, if a counter is prepended to the plaintext?Implementing PKCS#7 Padding on a Stream of Unknown Length?AES: Is it safe to encrypt same cleartext with same key but with million diferent IV?Is it safe to AES-CBC and AES-CMAC both using the same key?Encryption(AES) and verification per messageSelecting an appropriate key for HMACUsing SHA512 (or other hash) for message authenticationWhat is the correct way to implement PBKDF2 + AES CBC + HMAC?Are tags longer than 128 bit possible for AES-256-CCM and AES-256-GCM?Deciding on an AES cipher mode for chunked dataAES CBC MAC Generation
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
I am interested in the implications of using AES-CBC in a streaming configuration.
Reading the specifications of a few protocols I notice that when using AES-CBC
they include IV + ciphertext + HMAC in every frame of data sent.
If a stream of data is being sent would it be safe to instead send an IV initially,
but then simply continue using the existing CBC context for the data sent later in the stream?
For example:
context = createAESCBC(mySecretKey, myUniqueIV)
cipherText1 = context.encrypt(pkcs.pad("hello world!"))
// write cipherText1 and HMAC to socket
cipherText2 = context.encrypt(pkcs.pad("foo bar"))
// write cipherText2 and HMAC to socket
instead of:
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText1 = context.finalize(pkcs.pad("hello world!"))
// write perFrameIV and cipherText1 and MAC to socket
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText2 = context.finalize(pkcs.pad("foo bar"))
// write perFrameIV and cipherText2 and MAC to socket
I am aware of AES-CTR, and AES-GCM. I am interested specificially in CBC.
aes initialization-vector
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
$endgroup$
add a comment |
$begingroup$
I am interested in the implications of using AES-CBC in a streaming configuration.
Reading the specifications of a few protocols I notice that when using AES-CBC
they include IV + ciphertext + HMAC in every frame of data sent.
If a stream of data is being sent would it be safe to instead send an IV initially,
but then simply continue using the existing CBC context for the data sent later in the stream?
For example:
context = createAESCBC(mySecretKey, myUniqueIV)
cipherText1 = context.encrypt(pkcs.pad("hello world!"))
// write cipherText1 and HMAC to socket
cipherText2 = context.encrypt(pkcs.pad("foo bar"))
// write cipherText2 and HMAC to socket
instead of:
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText1 = context.finalize(pkcs.pad("hello world!"))
// write perFrameIV and cipherText1 and MAC to socket
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText2 = context.finalize(pkcs.pad("foo bar"))
// write perFrameIV and cipherText2 and MAC to socket
I am aware of AES-CTR, and AES-GCM. I am interested specificially in CBC.
aes initialization-vector
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
$endgroup$
add a comment |
$begingroup$
I am interested in the implications of using AES-CBC in a streaming configuration.
Reading the specifications of a few protocols I notice that when using AES-CBC
they include IV + ciphertext + HMAC in every frame of data sent.
If a stream of data is being sent would it be safe to instead send an IV initially,
but then simply continue using the existing CBC context for the data sent later in the stream?
For example:
context = createAESCBC(mySecretKey, myUniqueIV)
cipherText1 = context.encrypt(pkcs.pad("hello world!"))
// write cipherText1 and HMAC to socket
cipherText2 = context.encrypt(pkcs.pad("foo bar"))
// write cipherText2 and HMAC to socket
instead of:
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText1 = context.finalize(pkcs.pad("hello world!"))
// write perFrameIV and cipherText1 and MAC to socket
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText2 = context.finalize(pkcs.pad("foo bar"))
// write perFrameIV and cipherText2 and MAC to socket
I am aware of AES-CTR, and AES-GCM. I am interested specificially in CBC.
aes initialization-vector
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
$endgroup$
I am interested in the implications of using AES-CBC in a streaming configuration.
Reading the specifications of a few protocols I notice that when using AES-CBC
they include IV + ciphertext + HMAC in every frame of data sent.
If a stream of data is being sent would it be safe to instead send an IV initially,
but then simply continue using the existing CBC context for the data sent later in the stream?
For example:
context = createAESCBC(mySecretKey, myUniqueIV)
cipherText1 = context.encrypt(pkcs.pad("hello world!"))
// write cipherText1 and HMAC to socket
cipherText2 = context.encrypt(pkcs.pad("foo bar"))
// write cipherText2 and HMAC to socket
instead of:
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText1 = context.finalize(pkcs.pad("hello world!"))
// write perFrameIV and cipherText1 and MAC to socket
perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText2 = context.finalize(pkcs.pad("foo bar"))
// write perFrameIV and cipherText2 and MAC to socket
I am aware of AES-CTR, and AES-GCM. I am interested specificially in CBC.
aes initialization-vector
aes initialization-vector
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
asked Aug 5 at 2:05
UzomaUzoma
182 bronze badges
182 bronze badges
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation.
If you are having a sequential conversation, though, where each message has a unique number (maybe choose even numbers for one side of the conversation, and odd for the other side), then you don't need to transmit the IV each time: You could use $operatornameAES_k(n)$ as the IV for the $n^mathitth$ packet[1]. However, this only provides IND-CPA—that is, security against passive eavesdroppers on the network, not against forgers on the network.
Even better, you could use crypto_secretbox_xsalsa20poly1305 (or AES-GCM, if you insist on the notoriously side-channel-leaky AES) and use the message number as the nonce—then you have authenticated encryption which does defend against forgers, and you don't have to rely on a feathery pseudonymous carrion fowl on the internet for security analysis.
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
$endgroup$
1
$begingroup$
For clarity. In the above examplecreateAESCBCis likeEVP_EncryptInit_ex. Andencryptis likeEVP_EncryptUpdatesuch that callingencrypttwice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind?
$endgroup$
– Uzoma
Aug 5 at 3:30
1
$begingroup$
Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!'
$endgroup$
– dave_thompson_085
Aug 5 at 7:15
add a comment |
Your Answer
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%2f72377%2faes-cbc-streaming-configuration-iv-usage%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$
This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation.
If you are having a sequential conversation, though, where each message has a unique number (maybe choose even numbers for one side of the conversation, and odd for the other side), then you don't need to transmit the IV each time: You could use $operatornameAES_k(n)$ as the IV for the $n^mathitth$ packet[1]. However, this only provides IND-CPA—that is, security against passive eavesdroppers on the network, not against forgers on the network.
Even better, you could use crypto_secretbox_xsalsa20poly1305 (or AES-GCM, if you insist on the notoriously side-channel-leaky AES) and use the message number as the nonce—then you have authenticated encryption which does defend against forgers, and you don't have to rely on a feathery pseudonymous carrion fowl on the internet for security analysis.
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
$endgroup$
1
$begingroup$
For clarity. In the above examplecreateAESCBCis likeEVP_EncryptInit_ex. Andencryptis likeEVP_EncryptUpdatesuch that callingencrypttwice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind?
$endgroup$
– Uzoma
Aug 5 at 3:30
1
$begingroup$
Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!'
$endgroup$
– dave_thompson_085
Aug 5 at 7:15
add a comment |
$begingroup$
This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation.
If you are having a sequential conversation, though, where each message has a unique number (maybe choose even numbers for one side of the conversation, and odd for the other side), then you don't need to transmit the IV each time: You could use $operatornameAES_k(n)$ as the IV for the $n^mathitth$ packet[1]. However, this only provides IND-CPA—that is, security against passive eavesdroppers on the network, not against forgers on the network.
Even better, you could use crypto_secretbox_xsalsa20poly1305 (or AES-GCM, if you insist on the notoriously side-channel-leaky AES) and use the message number as the nonce—then you have authenticated encryption which does defend against forgers, and you don't have to rely on a feathery pseudonymous carrion fowl on the internet for security analysis.
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
$endgroup$
1
$begingroup$
For clarity. In the above examplecreateAESCBCis likeEVP_EncryptInit_ex. Andencryptis likeEVP_EncryptUpdatesuch that callingencrypttwice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind?
$endgroup$
– Uzoma
Aug 5 at 3:30
1
$begingroup$
Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!'
$endgroup$
– dave_thompson_085
Aug 5 at 7:15
add a comment |
$begingroup$
This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation.
If you are having a sequential conversation, though, where each message has a unique number (maybe choose even numbers for one side of the conversation, and odd for the other side), then you don't need to transmit the IV each time: You could use $operatornameAES_k(n)$ as the IV for the $n^mathitth$ packet[1]. However, this only provides IND-CPA—that is, security against passive eavesdroppers on the network, not against forgers on the network.
Even better, you could use crypto_secretbox_xsalsa20poly1305 (or AES-GCM, if you insist on the notoriously side-channel-leaky AES) and use the message number as the nonce—then you have authenticated encryption which does defend against forgers, and you don't have to rely on a feathery pseudonymous carrion fowl on the internet for security analysis.
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
$endgroup$
This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation.
If you are having a sequential conversation, though, where each message has a unique number (maybe choose even numbers for one side of the conversation, and odd for the other side), then you don't need to transmit the IV each time: You could use $operatornameAES_k(n)$ as the IV for the $n^mathitth$ packet[1]. However, this only provides IND-CPA—that is, security against passive eavesdroppers on the network, not against forgers on the network.
Even better, you could use crypto_secretbox_xsalsa20poly1305 (or AES-GCM, if you insist on the notoriously side-channel-leaky AES) and use the message number as the nonce—then you have authenticated encryption which does defend against forgers, and you don't have to rely on a feathery pseudonymous carrion fowl on the internet for security analysis.
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
answered Aug 5 at 2:26
Squeamish OssifrageSqueamish Ossifrage
30.4k1 gold badge52 silver badges131 bronze badges
30.4k1 gold badge52 silver badges131 bronze badges
1
$begingroup$
For clarity. In the above examplecreateAESCBCis likeEVP_EncryptInit_ex. Andencryptis likeEVP_EncryptUpdatesuch that callingencrypttwice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind?
$endgroup$
– Uzoma
Aug 5 at 3:30
1
$begingroup$
Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!'
$endgroup$
– dave_thompson_085
Aug 5 at 7:15
add a comment |
1
$begingroup$
For clarity. In the above examplecreateAESCBCis likeEVP_EncryptInit_ex. Andencryptis likeEVP_EncryptUpdatesuch that callingencrypttwice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind?
$endgroup$
– Uzoma
Aug 5 at 3:30
1
$begingroup$
Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!'
$endgroup$
– dave_thompson_085
Aug 5 at 7:15
1
1
$begingroup$
For clarity. In the above example
createAESCBC is like EVP_EncryptInit_ex. And encrypt is like EVP_EncryptUpdate such that calling encrypt twice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind?$endgroup$
– Uzoma
Aug 5 at 3:30
$begingroup$
For clarity. In the above example
createAESCBC is like EVP_EncryptInit_ex. And encrypt is like EVP_EncryptUpdate such that calling encrypt twice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind?$endgroup$
– Uzoma
Aug 5 at 3:30
1
1
$begingroup$
Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!'
$endgroup$
– dave_thompson_085
Aug 5 at 7:15
$begingroup$
Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!'
$endgroup$
– dave_thompson_085
Aug 5 at 7:15
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%2f72377%2faes-cbc-streaming-configuration-iv-usage%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
