85
GCM and CBC modes internally work quite differently; they both involve a block cipher and an exclusive-or, but they use them in different ways.
In CBC mode, you encrypt a block of data by taking the current plaintext block and exclusive-oring that wth the previous ciphertext block (or IV), and then sending the result of that through the block cipher; the ...
38
I wrote a rather lengthy answer on another site a few days ago. Bottom-line is that CTR appears to be the "safest" choice, but that does not mean safe. The block cipher mode is only part of the overall protocol. Every mode has its quirks and requires some extra systems in order to use it properly; but in the case of CTR, the design of these extra systems is ...
33
Caveat: as very rightly pointed in that other answer, using a fixed/no IV does make some attacks less difficult. I wish the following answer would have been less affirmative. I have accordingly made adjustments in italic.
There's no imperious need for an IV when unique keys are used. Given that a 256-bit key cipher is used, what's proposed is safe.
When ...
32
XTS vs. Undiffused CBC. The issue here is malleability. Both XTS and CBC prevent an attacker from learning information about encrypted data. However, neither one completely succeeds in preventing an attacker from tampering with encrypted data.
However, it's arguably easier to tamper with an (undiffused) CBC ciphertext than it is to tamper with an XTS ...
25
The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Nonetheless, here is what happened with SSL.
Basically they found two things:
A way to get the browser to encrypt data under the session key used by an existing SSL connection and
A mistake in the way SSL was ...
24
With CBC (Cipher block chaining) mode, before encryption, each block is XOR-ed with the ciphertext of the previous block, to randomize the input to the block cipher (and avoid encrypting the same block twice with the same key, as this would give the same output, and tell the attacker something about the plaintext).
As the first block has no previous block, ...
22
The CBC IV attack does more than that.
If I guess the plaintext corresponding to any ciphertext block I've seen before, and can predict a future IV, I can verify my guess by submitting a suitable message to be encrypted with that IV. Obviously, that could be bad if, say, I knew the plaintext to be either "yes" or "no", and only needed to find out which one ...
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 ...
17
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 ...
17
The security of that approach is equivalent to that of normal CBC.
Your scheme with first plaintext block $IV^\prime$ is clearly identical to normal CBC with $IV=AES(IV^\prime)$. Since a block cipher is a permutation over a block, a uniformly random first plaintext block will lead to a uniformly random IV for normal CBC.
A ciphertext produced with your ...
16
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. ...
15
TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch ...
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 ...
14
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 ...
13
First of all, you stated:
Because this message is encrypted using CBC mode, any modification of
the first block of cipher text would propagate throughout the message.
Actually, that's not true. Here's the CBC mode operation in the decryption direction:
(Public domain image from Wikimedia Commons.)
If you examine the process closely, you will see ...
13
Do not use a fixed IV. It can have seriously negative consequences. This is especially true for CBC mode.
That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.
12
After reading the paper How to Break XML Encryption (thanks to Krzysztof for the link), here are my two cents.
This attack relies on the fact that a CBC-ciphertext C = (IV, C1, ... Cd) can be decomposed into pairs of (IV, C1), (C1, C2), (C2, C3), ... (C(d-1), Cd), each of which is also a valid CBC ciphertext for the same key, relating to the corresponding ...
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
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 ...
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
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 ...
11
If (you suspect that) the (plaintext of the) encrypted data is ASCII text, you can check if the high bit of each decrypted byte is zero. As long as you have more than 24 bytes of data to check, the odds of that happening by chance are pretty low (given that you have a 24-bit keyspace).
UTF-8 text is also pretty easy to detect, since all bytes that do have ...
11
If you look at the CBC diagram, you'll see that having a fixed IV is equivalent to having the first ciphertext block become the IV. If your cipher is a good pseudorandom permutation, then what you are doing does work, if and only if all timestamps are unique such that the "new IV" is unique and unpredictable.
And in fact, if you do not use the decrypted ...
11
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 ...
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
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
Neither. It means that an attacker can decrypt all messages that have been encrypted using this standard.
The attack is a padding oracle attack. That means that, if the attacker has a ciphertext they want to decrypt, they can send several variations of the ciphertext to the server. By analyzing the server's responses (e.g., error messages returned), it ...
10
Not at all secure; generating preimages would be trivial. Here's a demonstration with a three-block message:
Here is your suggested method (limited to three block messages):
$E_0 = Encrypt( IV \oplus P_0 )$
$E_1 = Encrypt( E_0 \oplus P_1 )$
$E_2 = Encrypt( E_1 \oplus P_2 )$
$E_3 = Encrypt( E_2 \oplus 0 )$
$Hash = E_0 \oplus E_1 \oplus E_2 \oplus E_3$
...
Only top voted, non community-wiki answers of a minimum length are eligible
