# Tag Info

22

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

14

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.

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 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 ... 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 ... 7 In the first block, the IV provides the "randomness", and in subsequent blocks you just use the previous block of ciphertext instead. Based on the assumption, that the cipher is not weak and behaves like a pseudorandom permutation, this is basically the same: You XOR something unpredictable on the plaintext, and then encrypt. As long as the IV is chosen ... 4 All modern block ciphers are supposed to be pseudorandom permutations, meaning that they cannot be efficiently distinguished from a truly random permutation without knowledge of the key. (If a practical distinguisher were to be found for a particular cipher, that cipher would be considered broken by modern standards.) This also implies that no two secure ... 3 As long as the IV is chosen correctly, every individual block of the encrypted output will be uniformly random over the set of all bit-patterns of the given size. Each block is independent from the clear text, but they are not independent from each other. The first block contains the IV itself, which by construction is uniformly random and independent from ... 3 What you have devised is no longer ECB. ECB encrypts multiple blocks using the same key. The reason we have modes of operation is so that we can encrypt multiple blocks using the same key in a way that is secure, that is identical blocks of plaintext do not encrypt to the same ciphertext block, among other properties. What you have devised uses a different ... 3 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 ... 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 …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 ... 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 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 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

Yes there is a significant difference concerning brute-force. ECB suffers from multi target attacks whenever you encrypt the same message block. This is always possible in a chosen-plaintext attack and often possible in practice with a known-plaintext attack. With CBC the IV means that the plaintexts passed to the blockcipher are almost certainly unique ...

2

As Maarten Bodewes already wrote in a comment, if you ignore the computational overhead of XOR, then there is essentially no difference in CBC and ECB for a bruteforce attack. However, the question is actually mixing oranges and apples (and it is not obvious), because the security weakness of modes of operation has nothing to do with the underlying ...

2

In short, yes. The complementation property of DES states that if $DES_K(P) = C$, then $DES_{\overline{K}}(\overline{P}) = \overline{C}$, where $\overline{X}$ is the complement of a string $X$. ECB with DES takes a message $M_1M_2\cdots M_\ell$ and computes $C_1C_2\cdots C_\ell$, where $C_i = DES_K(M_i)$, for $1\le i\le\ell$. Therefore, if you encrypt ...

2

Commandline openssl enc normally does Password Based Encryption which derives the actual key, and IV (although IV is ignored for ECB), from the password or passphrase you enter, using a variant of PBKDF1. To get "raw" encryption you must specify the key in hex with -K (uppercase), in which case -nosalt is irrelevant (because it applies only to PBKDF). Except ...

2

This is off-topic, but arbitrary binary data can be read as image data using for example the Netpbm family of file formats. For example, here's how to read 10000 bytes of random data as a 100x100 grayscale image: $cat > image.pgm P2 100 100 255 ^C$ dd if=/dev/urandom of=image.raw bs=10000 count=1 1+0 records ...

2

First lets acknowledge this is a horrible hack - you really should find a way to do what you want more directly or risk code maintenance issues and likely bugs in the future. Second, while the question isn't about your key strengthening step it seems like you should ask about the security. There are lots of good key derivation methods out there and I don't ...

1

Perhaps. You indicate this is from an embedded device. This strongly implies everything the device needs to decrypt it is already present in the firmware of the machine, including both the algorithm and the key. Here is a blog post on how a talented engineer accomplished a similar feat through reverse engineering. Note that this was not a cryptographic ...

1

This is why we use random initialization vectors (IVs) for all such algorithms.

1

It's not ECB, but you "invited" another mode of operation. The best idea to describe your algorithm is as a stream cipher with an other function than XOR to interleave your key stream with the plaintext: The "IV key hash" generates a key stream like a good stream cipher should, and encrypting the plaintext with the key stream block is like XOR in a normal ...

1

To simulate $n$ times iterated ECB encryption, you can set your input plaintext block as the IV, encrypt a "plaintext" consisting of $n$ all-zero blocks using either CBC or CFB mode (which are identical for all-zero plaintext), and take the $n$-th block of the resulting ciphertext (discarding the rest of the output). Note that, if your CBC mode ...

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