Tag Info

Hot answers tagged

26

The really simple explanation for the difference between the two is this: ECB (electronic code book) is basically raw cipher. For each block of input, you encrypt the block and get some output. The problem with this transform is that any resident properties of the plaintext might well show up in the ciphertext – possibly not as clearly – that's what blocks ...


14

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, ...


14

There's no need for an IV when unique keys are used. When each key is used only to encipher a single message, it is safe (from a confidentiality standpoint) to use null IV for all messages. That's customary, for all common modes requiring an IV. It avoids the need to generate an IV, and transmit it, and (in the case of CBC) perform a XOR of the first block ...


12

The initialization vector is a property of the mode of operation (aka "chaining mode"), not of the block cipher itself. A block cipher does only one thing, which is mapping blocks (block size depends on the cipher, 64-bit for DES, 128-bit for AES) unto other blocks. The chaining mode is what says how input data should be transformed into block values, and ...


11

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, 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 ...


11

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 ...


11

ECB and CBC are only about encryption. Most situations which call for encryption also need, at some point, integrity checks (ignoring the threat of active attackers is a common mistake). There are combined modes which do encryption and integrity simultaneously; see EAX and GCM (see also OCB, but this one has a few lingering patent issues; assuming that ...


10

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 ...


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

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 ...


9

It depends on the chaining mode. With recent modes like EAX and GCM, the IV just needs to be non-repeating, so a timestamp is OK (as long as you take care never to issue two messages with the same timestamp: this can be a problem if you emit two messages in, say, the same millisecond, or if the sender clock is somehow reset through manual action or NTP; ...


9

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$ ...


9

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 ...


7

For TLS the IV for the first packet is generated from the shared secrets; quoting the RFC 2246: To generate the key material, compute key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); until enough ...


7

Cryptographically speaking, AesManaged uses AES in CBC mode. To ensure this operates securely, you need to choose the IV randomly, i.e. it should not be possible to predict the IV between iterations. This question has a discussion of non-random IVs: Using a Non-Random IV with modes other than CBC and this SO question: Why is using a Non-Random IV with CBC ...


7

Repeatedly encrypting the same message to the same ciphertext is full of practical attacks. Encryption is supposed to leak no information about the content of the message other than its length, and there are very real ways to exploit the information leakage you mention. Some of them have to do with the fact that plaintext domains are not always very large. ...


7

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 ...


7

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 ...


7

If you could use the same IV, then yes, you would need to rewrite everything after the modified block. But you shouldn't do that; every time the contents change, you should generate a new IV, which would require the whole file to be rewritten. Otherwise an attacker can learn more information than it should about how the file changed (precisely by checking ...


7

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: ...


6

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 ...


6

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 ...


6

The 16-byte IV and ciphertext (which together are part of the output of $e_m$) are assumed to be intercepted by an adversary. That reveals the number $b$ of 16-byte blocks in the ciphertext. With CBC and PKCS#7 padding, $b=\big\lceil{{n+1}\over16}\big\rceil$ where $n$ is the byte size of the plaintext (the file size). Putting $n$ itself in a header thus ...


6

In a scenario such as yours, where there is only one password/passphrase, but it is used as key material for the encryption of multiple CBC encrypted files, you will (as you noted yourself) obviously not make it any harder for an attacker to compute your password, should you use a salt. However, using a salt would mean that the encryption of each file is ...


6

In their 2012 paper "The Security of Ciphertext Stealing", Phillip Rogaway, Mark Wooding and Haibin Zhang prove that all the NIST-approved ciphertext stealing modes provide the same level of security as ordinary CBC mode, i.e. ciphertext indistinguishability under a chosen-plaintext attack. To quote their abstract: "Abstract. We prove the security of ...


6

As already given as partial answer in the comments, you would have to leak the second block as an IV is normally transmitted without confidentiality. You could of course retrieve it from initially decrypting the ciphertext without IV, and retrieve the first block value later on. But using an encrypted IV has got it's own vulnerabilities. The other issue is ...


5

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 ...


5

There is no "best" mode of operation, just modes more or less useful in different situations. CBC-mode requires an initialization vector which is unpredictable by the adversary (preferably random), especially if this adversary can mount a chosen plaintext attack. Up to TLS 1.0 (i.e. also in SSL 2.0 and 3.0), CBC was used with a "use last block of previous ...


5

You don't need to worry. There is no known weakness in CBC mode or AES which would mean that encrypting identical files (with different initialization vectors) makes it easier to retrieve the key, or decrypt the data. The different initialization vector for CBC makes it sure that even the same file results in different input to the block cipher, and thus ...


5

This is what ciphertext block chaining is about - each plaintext block is XORed ("chained") with the previous ciphertext block before encrypting (and after decrypting). The initialization vector then takes the place of the ciphertext block before the first block (since there is none). So, mistaking the initialization vector as a ciphertext block does ...



Only top voted, non community-wiki answers of a minimum length are eligible