# 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 ... 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 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 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 ... 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 ... 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 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 The -bf-ecb cipher is expanding the key to 128 bits by zero extending it. The output from -p is the telltale here:$ openssl enc -bf-ecb -e -in plaintext.txt -out ciphertext.txt -nosalt -K FFFFFFFFFFFFFFFF -p key=FFFFFFFFFFFFFFFF0000000000000000 Blowfish is defined for 32-448 bit keys, and it appears the OpenSSL implementation chose 128 bits as the size ...

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

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