Tag Info

Hot answers tagged

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.


11

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


9

CBC mode encryption is defined as: $C_i = E_k(P_i\oplus C_{i-1})$ (with $P_i$ being the $i$th plaintext block, and $C_{i-1}, C_i$ being the ciphertext blocks. What might happen if we have a lot of ciphertext encrypted with the same key is if two ciphertexts happen to be the same, that is: $C_i = C_j$ If we see that, we can then immediately deduce that: ...


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


8

First of all, we need to review what they mean by "parity of a permutation"; they don't mean whether the input block had a even number of 1's. Instead, they view the $n$ bit cipher (with a specific key) as a permutation on $2^n$ objects; that is, it can be review as a way of rearranging that set of $2^n$ objects onto itself. Now, permutations on a finite ...


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


6

There are many well known and studied ways of constructing a hash function from a block cipher. A thorough (but reasonably readable for a beginner) treatment of many of the classic approaches, and the security properties of the various constructions, can be found in Black-Box Analysis of the Block-Cipher-Based Hash-Function Constructions from PGV, which is ...


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

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


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


5

Quite apart from the correction that Reid made (it takes $2^{127}$ attempts to achieve a probability of 50% of finding the right key; with $2^{64}$ attempts, the probability of success is $2^{-64}$), with AES, there is no known way to take advantage of known (or even chosen) plaintext to speed up any brute force search; even with $2^{64}$ chosen ...


5

It can't be achieved under the assumptions you are making, because the attacker can distinguish it by selecting an arbitrary $k'$, and checking if $E(k')$ commutes with the permutation in question. That is, to check a permutation $P$, we pick an arbitrary $x$, and check if: $E(k', P(x)) = P(E(k',x))$ This equation always holds if $P = E(k)$ for some value ...


5

Yes, we can build a hash function from a block cipher, and that's common, although with block ciphers designed for that purpose, when in the following I focus on AES, mentioned in the (different) question that motivated the present answer [which got moved here because said question was found to be a duplicate]. One classic method to obtain a hash function ...


5

By a generic attack we also understand an attack that with minimal corrections would apply to every block cipher. For example, suppose you have a (plaintext,ciphertext) pair and test keys by exhaustive search: you apply the keyed cipher $E_K$ to plaintext $P$ for every $K$ and check if you get ciphertext $C$ in response. Quite often, the ciphertext bits ...


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

Since for any fixed key the encryption algorithm is a bijection from the set of $n$-bit strings onto itself, the set of all possible ciphertexts is regardless of the key and algorithm always the set of all $n$-bit strings and does not provide any information.


4

As explained in a comment: A generic attack is one that works against all block-ciphers (with a given block and key size), without consideration about the structure of the block-cipher. One generic attack for a block cipher of a given block size $b$ bits builds a dictionary of input/output pairs (e.g. from past plaintext/ciphertext), for a fixed key. When ...


4

The two plaintexts are almost certainly identical. At the very least, any difference between them must be representable in 32 bytes, since that's as much information as the XOR of the encrypted files contains. Assuming that the plaintexts are indeed identical, we can also see that changing the encryption key has a very simple and predictable effect on the ...


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

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

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



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