# Tag Info

30

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

16

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.

10

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

9

It is usually assumed that the length of the message is not secret. Even with padding the approximate length is usually leaked, and necessarily any encryption reveals a maximum length (or at least information content) because the ciphertext cannot in general be shorter than the message. NaCl secretbox does not use a block cipher, but a stream cipher ...

8

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

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

8

That statement is ambiguous, so I'll list a couple of limitation of block ciphers and cryptography in general: A raw blockcipher by itself only permutes a fixed size block (128 bits for AES). You need to add a mode of operation (together with IVs and possibly padding) to make it flexible enough for practical use. There are many modes to choose from, ...

7

I've checked out the source code (well, more or less, it's not that well designed, the main crypto class is 1600 lines) and as Richie guessed, the algorithm is stored together with the ciphertext. Pretty gruesome stuff, but it does do EAX mode for text strings to my surprise. It probably only uses it for text strings originating from the password vault code ...

7

Indeed, ECB is such that encrypting twice the same plaintext leads to the same ciphertext. Even worse, encrypting a plaintext containing twice the same plaintext block leads to a ciphertext containing twice the same ciphertext block. Either is a disadvantage because it goes against the ideal of a cipher: depriving the adversary from any knowledge about the ...

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

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

XTEA is a block cipher. It requires a block cipher mode of operation to work. Together with a block cipher mode of operation you can generate something that is secure. For this you require at least an IV, as you may otherwise encrypt identical passwords (for different users) to identical values. Or, if you encrypt each character separately, the same ...

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

6

A symmetric cipher design contest was started in Ukraine around 2006, and this cipher (in Ukrainian and Russian: Мухомор) was there. For specifications, look for "Applied Radioelectronics" journal "Прикладная радиоэлектроника", 2007, No 2. http://anpre.org.ua/?q=pre_2007_2 http://dspace.nbuv.gov.ua/bitstream/handle/123456789/61794/06-Dolgov.pdf

5

Dedicated stream ciphers typically are, or at least can be, somewhat faster than constructions based on block ciphers. (If they weren't, there would be no point in using them, since a block cipher can do everything a dedicated stream cipher can.) What you gain in speed (and possibly code size), however, you lose in versatility: A block cipher (in CTR / ...

5

You might consider using TEA or its successor, XTEA. Here's the complete C source code for XTEA, taken from the Wikipedia article: #include <stdint.h> /* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */ void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { unsigned int i; uint32_t v0=v[0], ...

5

I believe that, in this specific case, you are correct; it would appear to take $2^{60}$ effort to find a collision in the above function. On the other hand, there is one nit with this approach: this makes stronger assumptions on the block cipher than is typically assumed. A block cipher behaves as a random permutation if it is keyed by a random unknown ...

5

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

5

First of all, there's no such thing as a secure 8-bit block cipher, at least not as such things are conventionally used. That's because there are only 256 possible values for an 8-bit byte, and a block cipher will map each of these values to a different fixed value. Thus, an attacker who can even occasionally guess the unencrypted value of some bytes (or, ...

5

AES has a block-size of 128 bits in all its variants. The number in AES-128/192/256 is the key-size. Rijndael, the block-cipher that became AES, also supports 256 bit blocks, but that part was not standardized as AES. Since the block-size is 128 bits, GCM works exactly the same way for AES-256 as it does for AES-128.

4

It is certainly wrong to state that "MAC can only be produced with AES in CBC and CFB mode", but there seems to be a simple reason that people were inspired by these modes when thinking up possible MAC constructions: They carry along some state that incorporates information from the message while traversing the input blocks. In both modes, encrypting a block ...

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

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

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

4

Yes, EME is a wideblock cipher. Theorem 1 (in Section 4, top of page 5) states that EME is secure as a wideblock (tweakable) cipher under the assumption that AES (or whatever blockcipher you use) is secure. Specifically, to someone who doesn't know the key, EME will look like a set of random, independent permutations (one for each tweak). This is true even ...

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

4

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 Suppose you do CTR mode as:$E(k,nonce+1) \oplus m_1$,$E(k,nonce+2) \oplus m_2$,$E(k,nonce+3) \oplus m_3$, etc. The wikipedia page is talking about a non-random nonce, with a specific example of a packet counter. So suppose$nonce$is a packet counter and in each packet you encrypt several blocks. You might end up with the following: In packet #$p$: ... 4 Actually, Maarten isn't quite correct; in most cases, the counter doesn't have to be updated in constant time (because it's not secret); however in one case it does: GCM with an IV size that's not 12 bytes. The reason the counter needs to be secret in this case is not because how it is used, but how it is generated. It is initialized to ... 3 As I understand, your question is about using an involutive function$F$as a block cipher. This function is constructed as$F(x) = D(P(E(x)))$, for some (let's assume secure) block cipher represented by$(E, D)$. I will assume the encryption and decryption keys are equal such that the same holds for$F\$. Below is a generic attack that only uses the ...

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