# Tag Info

23

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

In complete honesty: if you have to ask this question, it's overwhelmingly unlikely that you have actually succeeded in breaking the security of AES. At best, you may have discovered a well-known attack against misuse of particular block cipher modes; for instance, plaintext recovery with a chosen-ciphertext attack against ECB, or blind manipulation of 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

Yes, AFAIK the original TEA is safe and generally fine when keys are random (key change should be atomic and with a fresh random key); the 64-bit block size is not a concern (say, an operating mode other than ECB is used and the key is changed before a gigabyte worth of data); the relative slowness is not a show-stopper; side-channels are not an issue, or ...

9

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

8

Assuming you really had broken AES or another frequently used algorithm that is thought to be secure, the first step would be to prove it. Write the code for the attack. Verify that it works on randomly generated data of the kind it requires. If it can break some challenge (e.g. these), do it. Post the results to the challenger or show the results ...

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

If you use a key for close to $2^{n/2}$ blocks in CBC mode, then the chance of getting a collision in the ciphertext is getting rather high because of the birthday paradox. As the ciphertext is used as a vector for the next calculation, and since that vector should be unpredictable, you would likely lose confidentiality. Note that the author seems to have ...

7

One obvious thing that it is vulnerable to a known plaintext attack that truncates the known message. This attack is quite simple; suppose the attacker knows a message $(P_1, P_2, ..., P_n)$ and the corresponding ciphertext $(C_1, C_2, ..., C_n, T)$ (using some IV; we don't care what it is). Here is how the attacker can generate a ciphertext that would ...

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

6

The point of the IV is to prevent the same (key,IV) from ever being used for two different messages in practice. This is an absolute requirement for stream ciphers or block cipher modes such as CTR that are effectively stream ciphers, because re-using the same (key,IV) pair lets an eavesdropper trivially obtain the XOR of two plaintext messages, which means ...

6

No, that is impossible. The reason is simple: How would you decrypt this? If you input the ciphertext and the key into the decryption function, than you have to get exactly one output, not two. How would you decide which output is the correct one? The DES encryption and decryption functions are bijective under one given key. This means that for every ...

6

DES with 2 rounds is broken. It is trivial to find a way to get the key with much less work than for the full DES (and even that is broken). DES is a Feistel cipher, so we have two halves, the left and the right half. For every round, we do something with the one half and a subkey, and then XOR it with the other half. After that we switch both halves, ...

5

SHACAL-2 is a block cipher. One way compression functions are typically using block ciphers as a building block, but add some simple operation that make the function one way. In the case of SHA-256, the compression function is SHACAL-2 in Davies-Meyer mode. SHA-256 in turn, consists of this compression function with Merkle-Damgård padding and chaining. ...

5

Alternative 1, Interleave = ShiftRows Use a KDF for extending and splitting the input key into three keys $K_1, K_2, K_3$. Split the input into $A_0 = a_0..a_{15}, A_1 = a_{16}..a_{31},...,A_{16} = a_{240}..a_{255}$ AES-ECB encrypt using key $K_0$ so that $E_{K_0}(A_i) = B_i = b_{16i+0}..b_{16i+15}$ Interleave so that $c_{16i+j} = b_{16(i+j)+j \bmod 256}$ ...

4

Yes. The keys are indeed used in a linear manner. In particular, they are used in $E$-$D$-$E$ mode: encrypt using first 56 bits as key, decrypt using next 56 bits as key and then again encrypt using final 56 bits. This way its possible to use triple DES (which is officially called TDEA) for the DES, 2-DES and 3-DES variations. The first would use ...

4

You are quite correct. A PRP in counter mode is, in fact, distinguishable from a random sequence if you approach the "birthday bound". We get around this by never generating that much output at once. With a 128 bit block cipher, an output of $2^{40}$ bytes (which is a lot of output) gives us a distinguishing advantage of about $2^{-56}$ (the probability ...

4

What Stephen says in the comment is correct. It is safe to not use authenticated encryption whenever your adversary model assumes that the attacker does not have the ability to manipulate ciphertexts. I assumed hard drive volume encryption or per file encryption that is not transmitted over an insecure network should be considered safe to do without a ...

4

The permutations in your question are given in Cauchy's two-line notation, where the upper line gives the input index to the permutation function, and the lower line gives the resulting permuted index. For example, the definition $$\sigma = {1\ 2\ 3 \choose 3\ 1\ 2}$$ means the same as $$\sigma(1) = 3,\quad \sigma(2) = 1,\quad \sigma(3) = 2.$$ Thus, if we ...

4

You can get what you want programmatically. No special ciphers or modes needed. You say there is a single, continuous subset that needs to be encrypted. Thus, you could have a function where the programmer specifies the start of the portion of the plaintext that needs to be encrypted and the number of bytes to encrypt. The function could pull that part out, ...

4

A family of functions F is a pairwise independent permutation if: Each member of the family is itself a permutation, and For any fixed $A$, $B$ (with $A \ne B$, and both from the input set of the permutation), and $f$ is a random member from the family $F$, then the pair $f(A), f(B)$ is equidistributed over all distinct pairs from the output range of the ...

4

That definition is a standard definition which defines encryption as a function $E$. That function takes two inputs, a $\kappa$ bit key and a $n$ bit message. Hence it is defined over the cartesian product - denoted as $\times$ - over these two sets, i.e. all bitstring of length $\kappa$ and $n$ respectively. It maps - denoted as $\rightarrow$ - to an $n$ ...

4

Encrypting big amounts of data is no problem for block cipher - if you remember a few important things. You can't encrypt plaintext which is bigger than the block size. You need to do some addition work. Most cipher operation modes first divide the plaintext into blocks of the size of the cipher. Now you can do different things: How about just encrypting ...

4

Every paragraph ends with : "this operation is invertible", I suppose the whole salsa20 algorithm is. The Salsa20 quarterround, and thus rowround, columnround and doubleround are invertible. However, the whole Salsa20 core is not because the initial state is added to the state after iterating the rounds (cf. page 6 in the spec). If I use salsa20 ...

4

Such a weak key schedule was chosen since the key schedule "theory" was not well developed by that time. Designers just modified the key schedule of DES a bit. Remember that these key schedules had to be optimized for hardware, and any extra operation would cost something in terms of area.

4

Use format-preserving encryption. The current NIST standards-track mode FFX should be sufficiently fast for your purposes. For your domain size, you might also want to try the swap-or-not shuffle, a new construction which is also pretty fast and dead simple to implement. To get the absolute best speed form these schemes you should use a single AES call as ...

4

If you mean DES as block cipher without mode of operation then no, this is impossible. DES is a block cipher, and block ciphers are Pseudorandom Permutations (PRP). As permutations in turn are bijective functions of $\{0,1\}^n$ to $\{0,1\}^n$ there is always a one to one relationship between plaintext and ciphertext. If this wasn't the case then you would ...

4

Usually cryptographic strength is given as the effective strength in bits of a security primitive. This is related to the amount of tries necessary to break a primitive. So for AES-128 the effective strength is about 126 bits. The number of bits is of course directly related to the number of tries required to perform an attack. This is often given as a power ...

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

4

I should begin by noting that this seems like an unusual assignment. I'm not sure why someone would explicitly have a goal of combining block ciphers and stream ciphers. First, let's summarize the difference between block and stream ciphers, since this may be useful for future readers. Block ciphers are so called because they operate over fixed lengths of ...

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