48
Short: CBC mode in context of TLS protocol has had security issues, and would have had to be reworked.
AES-CBC mode combined with decent HMAC can be as secure as AES-GCM. However, combining the cipher and MAC securely has been in practice found to be much easier said than done. Also, padding that is required by AES-CBC mode complicates things.
In ...
47
This is expected behavior since 7zip uses Cipher Block Chaining (CBC) mode for encryption. For which you need the Initialization Vector (IV) to be unique and unpredictable.
It was using 64-bit IV but fortunately, that was changed to 128;
Encryption strength for 7z archives was increased: the size of random initialization vector was increased from 64-bit to ...
22
Why does "2xAES-256" provide "99.99%" security strength whereas "1xAES-128" provides "40%"? [closed]
It's meaningless nonsense. I would be inclined to avoid spending any money with these people. If you scroll down on this page, you'll find a table labelled key size vs. time to crack, according to which their $2 \times 256$ bit encryption takes $3.31 \times 10^{112}$ years to crack, making it (apparently) superior to ordinary $256$-bit encryption (which can ...
21
CBC does not perform authentication
This property makes it less suitable for places where authentication is required, basically any transport protocol. TLS uses CBC, but by default performs authentication over the plain text instead of the ciphertext, which opened up a host of attacks. CBC can be used here, but it is error prone and may require an ...
20
Encrypting the same input multiple times, normally, is supposed to produce different outputs each time. This is so that an eavesdropper not only cannot tell that the input was hello there, but cannot even tell that the two files were produced from the same input. So for example you could send Mary the first file and Bob the second one, and an eavesdropper ...
19
If your IV is predictable this is as (in)secure as assuming that you have a zero vector IV.
And a zero vector IV allows you to perform a so-called Adaptive Chosen Plaintext Attack (ACPA).
Why?
Assume that you have a encryption mechanism that works in CBC mode. This means, that on the first iteration the $IV$ is XORed with your input message (which is ...
18
So, I'll answer the theoretical part of your question, since we need a key to address the practical part.
Why is padding used in CBC?
Blockcipher such as AES are encrypting blocks of a fixed given size only, we call it the "blocksize". So, what if your data is smaller than the blocksize ? An easy solution is to add what we call "padding" to your plaintext ...
17
Authentication and probabilistic encryption are two desirable features which each take up a small amount of extra space. And you are absolutely right that the percentage of space consumed is of no concern in most scenarios.
But as the other answers also point out that means you can no longer fit a logical sector inside a physical sector of the same size. ...
17
TLS 1.3 is a reboot of the TLS protocol which focused on up to date cryptography rather than backwards compatibility.
Now CBC is not as secure as you make it to be, and the way that it was used in TLS made it particularly vulnerable. To note: in TLS the HMAC authentication tag was created over the plaintext rather than the ciphertext. This made TLS ...
15
The Bit Flipping attack
Decryption process in CBC mode is performed as
\begin{align}
P_1 =& Dec_k(C_1) \oplus IV\\
P_i =& Dec_k(C_i) \oplus C_{i-1},\;\; 1 < i \leq nb,
\end{align}
where $nb$ is the number of blocks.
If you know the position of the target byte, then you can modify the corresponding ciphertext position in the previous ciphertext ...
14
So, are there reasons for not using authentication that I'm missing?
I believe that the real reason is not actually space, but time.
As you said, storing the tags would not require that much space. However, the tags need to be stored somewhere, and whenever you read the sector, you also need to read the sector containing the tags as well. So, unless you ...
13
You should use random IV even when unique keys are used.
This prevents key-collision attack where the attacker collects number of cryptograms that have been encrypted with unique keys and brute-forces for key.
Using predictable IV will reduce security of your cryptosystem by a factor of N (where N is the number of ciphertexts created). The attack recovers ...
13
Key/IV pairs should not be reused for either AES-CTR and AES-CBC - or for any other symmetric cipher for that matter. As a cipher is a Pseudo Random Permutation (PRP) inserting the same input will result in identical output. If a key/IV pair is reused then information is leaked to an attacker; the attacker can distinguish data with the same contents.
CTR is ...
13
With CBC mode the initialization vector is referred to as IV, because it is not nonce. There are ways to construct nonce so that it does not meet the needs of CBC mode. Random IV is one generation choice which is usually fine.
Nonce can also be a counter, which is not ok here.
Definitions
Nonce means number used once.
IV means initialization vector.
CBC ...
13
With 4096-byte sectors, space is a complete non-issue, less than 1 %
Problem 1: 10GB per TB is not a "complete non-issue" for many people.
Problem 2:
If the checksums are inside of their data blocks, there is a huge compatibility problem. The data per block is less than 512/4096, but many (really many) programs and kernel parts of pretty much all ...
13
ECB benefits:
It's a tiny bit easier to implement.
It allows for parallel encryption and decryption (CBC only decryption).
A single corrupted cipher block corrupts only one block of plain text(in CBC it is 2)
It doesn't need an IV
ECB downsides:
In almost all cases it is insecure.
For comparison, CTR mode allows parallel encryption and decryption and ...
12
In CBC mode the decryption equation is $P_i = D_k(C_i) \oplus C_{i-1}$. If you received a corrupted $C_i$, $P_i$ and $P_{i+1}$ will be decrypted wrong, but $P_{i+2}$ no longer depends on $C_i$ and will be correct.
12
The MAC value should be calculated over all of the input, not just the first block. The chaining of CBC makes sure that the bits in the last block of ciphertext depends on all the previous blocks.
12
If a nonce $N_i$ is even, then the binary numeral for it its increment $N_{i+1} = N_i + 1$ differs from $N_i$ only in its least significant bit; and if $N_i$ is odd, its increment is even. This means we can adapt chosen-plaintext attacks against CBC with counter nonces (e.g., from section 4 of this Rogaway paper) to target your scheme. Given an block ...
12
You'll find there's a lot of splitting hairs regarding this topic, especially key derivation. But yes, your pseudocode is fine, although you may want to revise (0, 128) => (0, 127) and (129, 256) => (128, 255) ... (correct me if I'm wrong?). Also, you might want to implement a constant-time comparison function for verifying the mac.
Have I derived the ...
12
No, it will be insecure. There are two reasons;
Due to the smaller key size 56-bit; DES was tested for brute-force attack since published.
DES_CHALL, 96 days to find the CES challenge key in 1997.
EFF DES cracker 56 hours to find the CDES challenge key in 1997.
COPACOBANA, an FPGA hardware built for attacking by brute-force for DES, can successfully find ...
12
Padding is dangerous. CBC mode with padding is secure against chosen-plaintext attacks, where the adversary can convince the legitimate party to encrypt messages and obtain the ciphertexts. But it is usually not secure against chosen-ciphertext attacks, where the adversary can craft ciphertexts and obtain information about the corresponding plaintext. ...
answered May 23 at 16:32
Gilles 'SO- stop being evil'
15.4k3 gold badges40 silver badges79 bronze badges
11
The answer by mwhs is very wrong about CBC-MAC and its use of IV!! It is perfectly fine and secure to use the same IV for CBC-MAC! In fact, Jonathan Katz and Yehuda Lindell recommend using zero vector IV when invoking CBC-MAC because it saves storage and bandwidth in practical settings! (souce: Introduction to Modern Cryptography, Second Edition)
The ...
11
CBC mode encryption is defined as:
$C_i = E_k(P_i\oplus C_{i-1})$
(with $P_i$ being the $i$th plaintext block, and $C_{i-1}, C_i$ being the ciphertext blocks.
What might happen if we have a lot of ciphertext encrypted with the same key is if two ciphertexts happen to be the same, that is:
$C_i = C_j$
If we see that, we can then immediately deduce that:
...
11
In the padding oracle attack you have an oracle that only tells you whether a particular chosen ciphertext decrypts to a correctly padded plaintext. That oracle is used to build a last word oracle, which used iteratively can reveal a whole message.
The reason it works in CBC mode is that we can make predictable, arbitrary changes to the plaintext of the ...
11
The infinite garble extension makes sure that if a ciphertext block is changed that this block and each block after it doesn't decrypt correctly. The way that additional plaintext is affected when the ciphertext is changed is called error propagation. Error propagation over large parts of the plaintext is mainly interesting if you want to combine it with ...
11
From a theoretical point as a mode of operation ECB mode has only one advantage over all of the other modes: it doesn't require an IV. That means that the ciphertext doesn't expand if the message is a multiple of the block size or if ciphertext stealing is applied. This can be a benefit e.g. when wrapping another symmetric key (a high entropy message), for ...
10
In this answer I'm assuming that a key is used to encrypt more than one message.
The first weakness is that CBC with fixed IV leaks if messages share a common prefix.
The second weakness is that it makes a padding oracle attack much more severe. Consider a device that knows the key and decrypts a ciphertext you send to it. While it won't tell you the ...
10
I would pick e) none of the above. None of those modes offers integrity protection, so unless integrity is handled elsewhere, your application is wildly insecure. An attacker could modify bits in transit and do nefarious things.
Of the three, CFB and CTR are the worst for the application and should be very easy for an attacker to mount successful attacks, ...
10
You would not just need a mode of operation for what you're asking. What you need is a secure transport protocol. Probably the best well known one for TCP connections is TLS of course. For UDP connections you could use DTLS. If you have a shared key you could use one of the pre-shared key (PSK) variants.
If you want to create your own transport protocol you ...
Only top voted, non community-wiki answers of a minimum length are eligible