Tag Info

Hot answers tagged

27

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


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

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

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

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

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


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

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

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

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

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

Actually, s is in CFB mode to handle transmission channels for the encrypted data that can add or drop individual bytes. In the olden times (say, the 70's), it was common to transmit data over serial channels, for example, RS-232. These channels were not perfect, and one common error we see is that if the transmitter sent 7 bytes, the receiver might get ...


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

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

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


3

The formal definition of a block cipher is a function $$ E_K(P) := E(K, P): \{0,1\}^k \times \{0,1\}^n \rightarrow \{0,1\}^n $$ The input and output spaces are by definition n-bit blocks, so the operation of the cipher in Electronic Code Book (ECB) mode is technically "format preserving". That is not however what "Format Preserving Encryption" (FPE) ...


3

I explain, criticize and try to improve the technique in the question (which asks for speed by using cryptographic techniques for arguably satisfactory functionality in a statistical simulation). Shuffling, and full-blown Format-Preserving Encryption aim at perfect or demonstrable cryptographic security, a different goal. Under the assumption that the ...


3

The first application is for decryption on a multicore processor. I assume any of ECB, CBC, CFB or CTR would be suitable since decryption would be faster when performed in parallel, but are any of them significantly more suitable than the others and how? CTR, CBC and CFB all allow parallel decryption. CTR allows you to decrypt any ciphertext block ...


3

How does Salsa20 work? The basic building block of salsa20 is a fixed 512 bit permutation. This is similar to a block cipher with a fixed and publicly know key (or a zero bit key if you prefer). Since it has no key input, you can't use it with block cipher modes of operation. The next step in Salsa20 is a feed-forward by adding the input into the output, ...


3

Yes, it is possible to implement the primitive asked, with a 32-bit block cipher that is secure (indistinguishable from a random permutation) no matter how many input-output pairs are known, keyed with a fixed secret randomly-chosen key. That's a standard building block in Format Preserving Encryption. One such block cipher is: Louis Granboulan and Thomas ...



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