Tag Info

85

Why shouldn't I use ECB encryption? The main reason not to use ECB mode encryption is that it's not semantically secure — that is, merely observing ECB-encrypted ciphertext can leak information about the plaintext (even beyond its length, which all encryption schemes accepting arbitrarily long plaintexts will leak to some extent). Specifically, the ...

29

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}$ (source: xkcd.com) While there were several issues contributing to the scale of the compromise, one of them was that Adobe, instead of properly hashing ...

27

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

19

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

19

You should not use ECB mode because it will encrypt identical message blocks (i.e., the amount of data encrypted in each invocation of the block-cipher) to identical ciphertext blocks. This is a problem because it will reveal if the same messages blocks are encrypted multiple times. Wikipedia has a very nice illustration of this problem.

18

The Java algorithm string "RSA/ECB/PKCS1Padding", as you already found out, does not implement ECB; it only encrypts/decrypts a single block. The Bouncy Castle cryptographic security provider has a better named algorithm string, "RSA/None/PKCS1Padding", which better indicates that no mode of operation is used. It is likely that "/ECB" was just included to ...

15

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

15

Yes, you can do this. In fact, implementing other cipher modes is precisely what ECB mode is good for (and, indeed, just about all it is good for). To implement AES-CTR, simply fill an array of 128-bit blocks with increasing counter values, encrypt it with AES-ECB and XOR the resulting keystream with the plaintext (for encryption) or ciphertext (for ...

15

Assume I have a list of plaintext text and its corresponding ciphertext which was created using a specific key with AES in ECB mode. Can I recover that key? No. This is what is referred to as a known plaintext attack, and secure block ciphers are designed to prevent exactly this kind of attack. This answer on the Mathematics Stack Exchange goes into ...

13

It is highly misleading to call how RSA Encryption is used as 'ECB mode'. With ECB mode, we break the plaintext into N bit segments, and send each one through the block cipher separately. The block cipher is deterministic, and so if two plaintext blocks happen to be the same, so will the corresponding ciphertext blocks. Now, with RSA encryption, we take ...

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

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

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

10

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 \... 10 ECB leaks if blocks are identical. For uniformly random data identical blocks become likely when you encrypt about$2^{n/2}$blocks with an$n$bit block cipher. CBC and CTR mode develop similar weaknesses when they encrypt that much data. => As long as you encrypt reasonable amounts (up to a petabyte or so) of random data with a 128 bit block cipher, like ... 10 What is the simplest attack is the Brute Force Attack. However, it is infeasible to brute-force even AES-128 bit, AES also supports 192, and 256-bit keys sizes. To break the AES-128 with brute force, you need to execute$2^{128}$AES operations, today's top computers can reach$2^{63}$around one hour. However, reaching$2^{128}$is beyond classical ... 9 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 ... 9 Indeed, ECB is such that encrypting twice the same plaintext leads to the same ciphertext. Even worse, encrypting a plaintext containing twice the same plaintext block leads to a ciphertext containing twice the same ciphertext block. Either is a disadvantage because it goes against the ideal of a cipher: depriving the adversary from any knowledge about the ... 9 There is no good way to calculate a strength difference between ECB and CBC. ECB is broken as a generic cipher - it is not indistinguishable under chosen plaintext attack - as repeating blocks will confer information to an attacker. That particular piece of information doesn't let itself be quantified compared to the amount of bits within the key. It's even ... 9 Of course you can implement CTR mode if all you have is ECB. All you have to do is use ECB to encrypt the successive counter values and use the resulting ECB-ciphertext as the CTR keystream to xor with the actual plaintext you want to encrypt. So for example, the first few counter values to encrypt with ECB would be (where$N$is a 64 bit nonce / IV which ... 8 Better is a subjective term. However for the choice between ECB and CBC, the choice should be CBC for almost all situations. Although ECB and CBC are modes of operation of a block cipher, you could also turn this way of thinking around and see the block cipher as a configuration option for the mode of operation. The mode of operation has a big influence on ... 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 ... 8 In the padding oracle attack you have an oracle that only tells you whether a particular chosen ciphertext decrypts to a correctly padded plaintext. That oracle is used to build a last word oracle, which used iteratively can reveal a whole message. The reason it works in CBC mode is that we can make predictable, arbitrary changes to the plaintext of the ... 8 The modern trend for encryption-only modes is clearly CTR, which has a number of advantages over other modes: no padding is needed (contrary to CBC); the computationally-intensive part can be efficiently performed with the IV (and key) only, before the plaintext or ciphertext is available (contrary to CBC, CFB); the computationally-intensive part can be ... 8 The modes you are referencing are specifically modes of operations for block ciphers, and therefore are not directly applicable to hash functions. Block cipher operations take 2 inputs, the key and a block-sized input value, and output a block-sized keyed permutation of the input. Hash functions take a variable length input, and output a fixed length value. ... 8 Suppose we have a block cipher that takes a 16 byte plaintext and produces a 16 byte ciphertext (that is to say$\mathcal{Enc}: \{0,1\}^{128} \rightarrow \{0, 1\}^{128}$). We use this block cipher to encrypt two blocks worth of unknown data, call them$m1$and$m2$. Additionally we are allowed to prepend some data to these two blocks, let's call it$m0$(we ... 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 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 ... 7 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 ... 7 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 ...

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