# Tag Info

38

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

15

For a real-world example of precisely the same ECB weakness leading to a massive password compromise, see the Adobe password database leak, as memorably illustrated in the xkcd web comic: $\hspace{83px}$ While there were several issues contributing to the scale of the compromise, one of them was that Adobe, instead of properly hashing the passwords, ...

12

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

12

It illustrates the point that the same plaintext going in to the cipher will result in the same ciphertext. It just happens to be a lot better example than showing someone abc387af de7231ab abc387af abc387af a129867e Now, what does this mean in the real world? If I gave you an email encrypted with AES-128 ECB, could you look at it and figure out the ...

10

ECB is not secure, it leaks information. CBC is better. But if you need random access to your file Use CTR mode. For more information about Block cipher modes of operation see the Wikipedia article.

9

It is not secure, because an attacker can "mix and match" the output blocks from different authentication tags on different input messages, or repeat output blocks for repeated input blocks. For example, if the attacker knows the tag $F_k(m)$ for a one-block message $m$, then it can forge the correct tag $F_k(m) \mid F_k(m)$ for the two-block message $m ... 8 Never use ECB! It is insecure. I recommend an authenticated encryption mode, like EAX or GCM. If you can't use authenticated encryption, use CBC or CTR mode encryption, and then apply a MAC (e.g., AES-CMAC or SHA1-HMAC) to the resulting ciphertext. 8 DES has a block size of 8 bytes. Two blocks therefore come to 16 bytes. It looks like Adbobe were encrypting passwords using two blocks of 3-DES in ECB mode. Because all these passwords are eight bytes long, the second block is empty and is just filled with zeros. The second block gets started at all because of the string-terminating NUL character at the ... 7 As far as is publicly known, no, you can't. If you could, that would constitute a practical known-plaintext key recovery attack on AES, and the existence of such an attack would mean that AES would be considered totally insecure by modern cryptographic standards. If you do figure out how to do that, publish it and you'll be famous. (Or, if you'd prefer ... 7 Yes, simply encrypting each 16-byte block with AES-128 will insure their confidentiality if they are all different, w.r.t. to an adversary that can't break AES (nitpick: given that AES is an even permutation, we should also assume that more than two plaintext/ciphertexts pairs remain unknown, but that's a practical certainty). That use of AES can be named ... 7 Yes, this is one case where ECB mode is secure. It can be shown to be secure trivially from the indistinguishability assumptions of AES; that AES with an unknown key cannot be distinguished from a random permutation. If the plaintexts are all 16 bytes long, then in ECB mode, this directly means that the ECB mode encryption of those plaintexts are ... 7 The article mentions that 3-DES was used to encrypt these passwords in ECB mode. DES has a 64-bit/8-byte block. So let's say you use ECB to encrypt a nine byte password. The first 8-bytes are encrypted using ECB. So far so good. But what happens when we come to the ninth byte? Well we're now in a new block but only the first byte is populated with any ... 7 The other answer is correct in general. However, if your messages are all exactly one block long (or all one block after padding), ECB is a secure MAC. A PRP looks like a PRF up to half its bit length, i.e. up to$2^{64}$blocks for AES. A secure PRF is a secure MAC of the same size. Thus, AES ECB used on 128-bit messages is a secure MAC as long as you use ... 6 Use the master key in ECB mode. I have heard/read that this is cryptographically weak (Why?). The reason I include ECB mode here is that it could allow me to save half the storage space. Since the messages are only one block long, I suspect this may affect the 'traditional' arguments against ECB. Because any identical plaintexts will encrypt to the ... 6 While I'll try to answer your question at a theoretical level below, I'd like to first stress the following: It's a bad sign if, in the course of writing software, one is making such low-level decisions about encryption methods. Encryption security is extremely brittle, with seemingly insignificant details causing complete failure. With that said, the ... 6 I believe what you are seeing is that .NET automatically uses PKCS #7 padding. This will always add padding. Thus if your plaintext is a complete block length, one extra block of padding will be added. The reason the ciphertext ends up being the same in both of your test cases is that it is adding the same padding in both cases (see PaddingMode Enumeration ... 6 The capacity of AES in terms of file encryption is practically unlimited for the time being, especially in OFB or CTR mode. An 8 GB file comprises short of$2^{29}$128-bit AES blocks. If one uses CBC or OFB CFB mode, odds of a collision (that is, the same block appearing in ciphertext, which reveals 128 bit worth of potentially usable information about the ... 6 If you mean how much data can safely be encrypted by AES with a single key (and IV), AES is designed to encrypt up to$2^{64}$blocks of data before becoming susceptible to certain statistical attacks (in particular distinguishing the encrypted file from truly random data), because of its 128-bit block size. 8GB (=$2^{36}$bits =$2^{29}$blocks) is quite ... 5 A replay attack simply means that an attacker who intercepts a valid message can re-send that message as many times as they want. If there's nothing in the message that could not be legitimately repeated, then the recipient will have no reason not to accept it as a valid message. In general, all encryption modes are potentially vulnerable to replay ... 5 No for practical definitions of possible, assuming the key was chosen truly randomly, and no side-channel information is available (such as the power-consumption traces of the encrypting device, or the time it took, for many encryptions). The design of AES strives to be such that the best way to find the key from plaintext-ciphertext examples is to try keys ... 5 Note: I'll disregard the base64 encoding in the following text; the base64 encoding does not change the properties of the generated ciphertext. What you are running into is padding together with ECB mode. This padding can be any static padding. Most common is PKCS#5 padding, but zero padding is also possible. It is not possible to test which padding is ... 5 The reason why CBC is considered better than ECB has nothing to do with situations involving an attacker with a partial ciphertext; we always assume that any attacker has full access to the ciphertext. Instead, the problem with ECB is that it leaks information. Specifically, if you encrypt two messages which has two blocks of plaintexts in common, then ... 4 Well, assuming that you have a fixed block cipher (that is, you don't change the block cipher as the length of the message increases), then given a message of length$N$: Both ECB and OFB take$O(N)$time for both encryption and decryption. Both ECB and OFB take$O(1)$space in addition to the space to hold the encrypted/decrypted message (which is ... 4 A replay attack works by blindly re-using an earlier message or ciphertext, or fragment thereof, typically one that was encrypted or signed. A simple example would be a bunker which receive the encrypted message "I'm General X, open the door". Now if this encrypted message was captured a week earlier and replayed by some opponent, well you get the idea. ... 3 If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext. If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record ... 3 As CodesInChaos comments, your basic idea seems sound, although a 64-bit block size leaves you with a rather low security margin. Personally, I'd be more comfortable using a cipher with a 128-bit block size (like AES), zero-padding the IDs to 64 bits, appending 64 random bits and encrypting the resulting 128-bit block. This means that: even with the ... 3 I think what you are looking for is a Password-Based Key Derivation Function (PBKDF). You can take a moderately strong password, like 12-14 random letters and numbers (no dictionary words though!), and throw it into the PBKDF function together with some other parameters, e.g. salt, number of iterations and the desired key length. After that you have a ... 3 Assuming: the objective is to protect the confidentiality of the user names from an attacker having read access to the encrypted data, the ability to add usernames of her choice, and nothing else (in particular, no access to the key, even by proxy of a computer or device holding the key, or side channel); the IV is randomly chosen for each individual ... 3 OFB is a mode of operation to ensure confidentiality of messages a) longer than the block size of the encryption algorithm, and b) that can be re-broadcast. The motivation for these kinds of modes it to avoid the weaknesses that come from using plain ECB mode. To be precise, the typical attack on ECB mode involves analyzing the ciphertext and looking for ... 3 If there was a full 64-bit block of known plaintext, there would be a very fast attack using precomputation. You can build a precomputed table of all$2^{40}\$ ciphertexts. Once you've got the precomputed table, recovering a key (given a ciphertext) would require just a single lookup in the table, so recovering a key would be extremely fast. Storing that ...

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