# Tag Info

They're both broken under known plaintext attack, where attacker knows two (plaintext, ciphertext) pairs, $(m_1,c_1)$ and $(m_2,c_2)$: $E'_1(k_1,k_2) := k_1 \oplus E(k_2,m)$ $E'_1(k1,m_1) \oplus E'_1(k1,m_2)=E(k1,m_1) \oplus E(k1,m_2)$ The attacker simply computes $E(k1,m_1) \oplus E(k1,m_2)$ for every possible value of $k_1$ and compares it with $c_1 ... 4 There are two well-known Encryption modes, that can construct a$mn$-bit tweakable blockciphers from a$n$-bit blockcipher ($n=64$for DES) with$1\le m\le n$. The older one is CMC, being not parallelizable. It was superseeded by Encrypt-Mix-Encrypt (EME), which is parallelizable. The basic idea of the two algorithms is to encrypt each block of input data ... 3 In addition to the tweakable enciphering schemes in the comments, I'll leave this reference here: https://eprint.iacr.org/2009/356.pdf It essentially shows (in the ideal cipher model) that using an n-bit block cipher in a three-round Feistel construction gives you a 2n-bit block cipher. 3 You cannot encrypt 720 bits plaintext using just AES-128. AES is a 128 bit block cipher. Such a block cipher has an input of 128 bits of plaintext and an output of 128 bits ciphertext; and that's it. You need some kind of construction to make block ciphers encrypt larger or smaller plaintext. Such constructions are known as (block cipher) modes of ... 3 I can make a few comments regarding points 1 and 3: If you are going to encrypt only one block, your first assumption is not that misled. However, you will almost always need to encrypt a file longer (maybe way longer) than the key length (let's say 128 bits). Without considering encryption modes, that means that for every block of 128 bits, you will ... 2 Regarding points 2 and 3, cipher designers want to ensure that the relationship between the plaintext, the ciphertext, and the key are complex, so that no attacker can efficiently untangle them. If the ciphertext can be expressed as a linear or sufficiently low-degree system of functions of the plaintext and key then attackers can use efficient algebraic ... 2 I will specifically address your question 3; that is, quite a lot of block ciphers (and hash functions) consist of a regular round structure (where you repeatedly do the same thing over and over); why is this? Well, one incentive for doing that is that it makes the cipher easier to analyze; we can study the round function in depth; once we've done that, we ... 2 XTS has been designed for disk encryption, where an attacker typically has access to the disk only a single time (when they steal/confiscate the device). When an attacker sees several ciphertexts encrypted using the same key, they can tell which blocks differ between the versions, but not the content of the blocks. Compare this with CTR mode, which leaks ... 2 To emphasize that this isn't a generically good construction, we can show that AES with that tweak method is insecure (!). This observation is based on a simple 1 round differential characteristic; it starts off with a differential in one of the bytes, and a carefully chosen differential in the tweak. With this initial differential, after the AddRoundKey ... 2 This construction isn't generically secure, you need to analyze it for each blockcipher you want to use it with to see if it's secure. For example, consider a block cipher that simply xors the key into the state between rounds. In that case your construction is equivalent to xoring the tweak into the key. This has several consequences: Since we generally ... 2 I know that all the subkeys$k_i$are derived from the main key$K\$, but how? However the cipher designer feel like. The Feistel design gives guidance as to how the block is processed (and in a way to make inverting the cipher easy), however it gives no guidance as to actually generate the subkeys. The designers can do anything they like, and still ...