# Tag Info

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

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

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 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 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 ... 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 ... 3 If the protocol doesn't provide authentication, an attacker can probably mount replay attacks or make deterministic changes to messages. If the nonces in different blocks are not compared in any way, they can just take the ID block of a previous message and use it with a new one, to forge it being from that device. If nonces are required e.g. to be equal in ... 3 As poncho said in his comment, you added padding before decryption as well, which is not correct. AES encryption and decryption are both permutations, so if you decrypt data with a key, it will "look" random (at least, if AES is secure). Instead of adding padding, you need to remove the padding from the already decrypted text: from Crypto.Cipher import AES ... 3 Yes, this is easy enough to exploit. Start by sending any 15-byte message$m$, and then 256 different 16-byte messages consisting of$m$followed by each of the 256 possible values of the last byte. One of the encrypted 16-byte messages will have the same first ciphertext block as the encryption of$m$. Find out which, and you've found the first byte of ... 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 ... 2 ECB leaks the identity of blocks. After padding some blocks on the end will be eminently predictable, for instance a block with a single 'e' and all zero padding. 2 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 ... 2 …are any other modes of operation vulnerable to padding oracle attacks? Nope, it’s purely restricted to CBC. A padding oracle attack, also known as “Vaudenay attack” because it was originally published by Serge Vaudenay in 2002 and introduced at EUROCRYPT 2002, is an attack against cipher-block chaining. The attack works against any block cipher in ... 2 It is not practically possible. There are several attacks that are slightly faster than bruteforcing$2^{112}$key candidates, but this is only a small factor. In some sense, they are bruteforce-like, since they require$2^{113}$smaller steps. 2 There are a couple of things going on: First of all, the DES key FF FF FF FF FF FF FF FF happens to be a "DES weak key"; by that, we mean that if you send a block through the cipher twice, it'll end up with the original value; that is: $$X = DES_{weak}( DES_{weak} ( X ))$$ You are obviously encrypting in CBC mode with a zero IV. So, let us look at what ... 1 I understand that, for a block cipher that receives a key of k bits and processes blocks of n bits (n>k), on ECB mode, Oscar would find false keys and because of that he would need to check more than one pair (i.e. two or three for DES). That doesn't sound right; if you are assuming that the attacker (Oscar) has a plaintext block$P\$ and a ciphertext ...

1

It is the case. All 8 character passwords in the leaked file end in "ioxG6CatHBw==" Source: http://pastebin.com/iDTFARwq

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