88
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 ...
34
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 ...
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 ...
23
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 ...
18
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 ...
15
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 ...
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
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
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
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
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$
...
10
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 ...
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
