46
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 ...
44
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 ...
39
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 ...
37
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 ...
26
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 ...
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 ...
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 ...
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 ...
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
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.
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
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
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
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 ...
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
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 ...
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
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 ...
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 ...
11
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
