Tag Info

Hot answers tagged

7

Differential cryptanalysis works on differences. Linear cryptanalysis works on linearity. Neat, isn't it ? Instead of speaking of how they differ, it is easier to list their common features. Both kinds of attacks: Use a lot of known pairs plaintext/ciphertext (many input messages encrypted with the same key, and, for each of them, the attacker knows both ...


6

Efficiently - no. However, the best attack on DES - linear cryptanalysis - works with known plaintexts, and theoretically may work slightly faster than the brute force even for small amounts of data. Computing linear relations between plaintext $P$ and ciphertext $C$, an attacker is able to enumerate all keys according to their likelihood. The PhD thesis by ...


6

Did you try Wikipedia? DES consists of 16 rounds of the form: $$L_{i+1} = R_{i}, \quad R_{i+1} = L_i \oplus F(R_i, K_i),$$ which are identical except for the round subkeys $K_i$. (The last round is slightly different, in that the half-blocks $L$ and $R$ are not swapped as they are after all other rounds, but that makes no cryptanalytic difference.) The ...


5

Given a function $F: A \rightarrow B$ and functions $R_1, R_2, \dots, R_k:B \rightarrow A$, we can create a chain of length $k$ from a starting point $a_0$ to an end point $a_k$ using $a_i = R_i(F(a_{i-1}))$. A rainbow table for $(F, R_1, \dots, R_k, k)$ is a collection of chains with end points $(a_0, a_k)$ organized so that searching for chains ending at ...


5

From Schneier's description of DES in Chapter 12 of Applied Cryptography (12.3): “DES with any number of rounds fewer than 16 could be broken with a known-plaintext attack more efficiently than by a brute-force attack.” This explains the "Why not less than 16". As for the "why not more than 16", that is a tradeoff for speed of execution (more rounds = less ...


4

Well, one assumption you appear to be making is that, with 2DES, there will be approximately $2^{56}$ possible key matches. Actually, there are an expected $2^{48}$ possible key matches; here's why: Let us assume we're running the meet-in-the-middle attack on 2DES, and consider an arbitrary incorrect encryption trial (that is, we try an encryption key that ...


4

In "Applied Cryptography" — Chapter 12, , Bruce Schneier writes: The final permutation is the inverse of the initial permutation and is described in Table 12.8. Note that the left and right halves are not exchanged after the last round of DES; instead the concatenated block $R$16$L$16 is used as the input to the final permutation. There’s nothing going ...


4

To answer your last question first, Triple DES does not need a longer key because it has more rounds than plain DES — rather, Triple DES needs more rounds than plain DES because it has a longer key (and because it aims to offer a security level appropriate for that key length). To be more specific, plain DES only has a 56-bit key, meaning that it can ...


4

Modes of operation are generally supposed to be independent of the underlying block cipher. They generally have a proof of security showing that the security of a system using said mode reduces to the security of the block cipher. However some modes, such as CTR, don't work well with block ciphers of short length (aka, old ciphers) and can leak information. ...


4

You need to split up your key into eight 7 bit pieces, and put these 7 bits into a byte each. The parity is in the least significant bit on most platforms, so the 7 bits need to go into the most significant bits. Of course, as the key is probably in bytes, you need to shift and combine the values in the bytes to retrieve the 7 bits. It's possible the ...


3

If we talk about key search attacks (rather than key compromise or/and side-channel attacks), the answer must be no, for the best known method is impractical. On the other hand there has been numerous successful key-recovery attacks against devices using TDES, including on some that try hard to avoid it. One example here, another there.


3

Each half of the key is 28 bits long, so there will be $2^{28}$ possible choices for each of them. In the first part of your attack, you start with the known block of plaintext and encrypt it for the first 8 rounds using each possible left half of the key. This gives you $2^{28}$ "half-encrypted" 64-bit blocks. This is less than the birthday bound, so ...


3

No. This is known as a known-plaintext attack, and AFAIK no such attack is faster than bruteforce for DES. However, DES only uses a keyspace of $2^{56}$, so you could theoretically still bruteforce it.


3

We are talking about attacking double-DES here, which encrypts a 64-bit block $P$ with two 56-bit keys $K_1,K_2$ as $C = E_{K_2}(E_{K_1}(P))$. As noted by Diffie and Hellman already in late 70s, to attack it with a one or two plaintexts as follows. Suppose we know that $P_0$ is encrypted to $C_0$, then for all possible $K_1$ compute $E_{K_1}(P)$ (partial ...


3

In contrast to asymmetric schemes (notably RSA and El Gamal) which require some sort of computation to generate the key, the only constraint one has when selecting a key for DES or AES (or 3DES) is to make it look indistinguishible from a random stream. That said both El Gamal and RSA require some randomness in key generation, but that phase does not depend ...


3

The de-facto answer to any question about increasing the AES rounds is that as yet there doesn't appear to be any need, and any time you do so involves implementing at least some of it in custom code, which is inherently risky. As far as running AES twice goes, have a look at Meet in the Middle (MITM) attacks. I don't know how relevant these will be to your ...


3

One simple approach is to truncate the output to 56 bits. I believe this was considered in Hellman's original paper on time-space tradeoffs. Sometimes people get all excited by rainbow tables (partly because it has a cool name, maybe) but forget about Hellman's original paper on the time-space attack. Hellman's paper is very much worth reading, especially ...


3

It seems to me you can do everything as when calculating a rainbow table for a hash function, except that choosing a good reduction function is very easy. For example, define a chain starting from $k$ as: $$c_k(0) = T(E_k(0))$$ $$c_k(i) = T(E_{c_k(i-1) \oplus i}(0)),$$ where $T$ truncates its input to 56 bits. Now you can create a rainbow table with $n$ ...


3

If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext. If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record ...


3

Actually, there's no known way (assuming practical amounts of computing power) to distinguish keying methods 1 and 2. You mention a "brute-force attack of complexity $O(2^{56})$ followed by a chosen plaintext attack of complexity $O(2^{57})$", there's no obvious way to frame an attack against either of the first two options in this matter; you can't do a ...


3

You have a ciphertext (or maybe multiple), a list of possible plaintexts, but no key. Therefore, your process would be Generate random decryption key Decrypt ciphertext with that key (base64 decode CT first) See if result appears in your list of possible plaintexts If it does, return that plaintext; otherwise goto 1 This is a basic brute force attack and ...


2

Adding my 2 cents, I would like to point out that many published methods for white-box cryptography have been broken. This includes… white-box AES white-box DES … which have been crypto-analyzed and are known to be insecure ever since. On the other hand, as long as you just plan to study implementation to learn about the techniques and not plan to ...


2

Applied Cryptography mentioned this. With 17 or 18 rounds a differential attack is about as costly as brute-force. And 19 rounds or more makes differential attack impossible since it requires more than 2^64 chosen plaintexts, which is impossible since the DES block size is 64 bits.


2

DES is based on a Feistel construction - while the one-way function used is.. well.. one-way, you don't need to reverse it at all to "decrypt" (otherwise you are correct we would have a problem). Look at this diagram, specifically the decryption one: As you can see, even though one half of the ciphertext is passed through the one-way function, there's ...


2

The attacker splits the range of $2^{56}$ keys for the first DES into $2^{17}$ ranges of size $2^{39}$. He will then run $2^{17}$ times the following meet-in-the-middle attack, once for each range: For all the keys in the range, the attacker computes the first DES on the known plaintext, yielding $2^{39}$ 64-bit words, for a total size of $2^{45}$ bits. ...


2

It is not practically possible. There are several attacks that are slightly faster than bruteforcing $2^{112}$ key candidates, but this is only a small factor. In some sense, they are bruteforce-like, since they require $2^{113}$ smaller steps.


2

As fgrieu already pointed out, using a OWF in the way you describe would make the key schedule not efficiently invertible (or even not invertible at all), meaning you would need more memory/chip space to store the user-input key in order to efficiently encrypt more than one block. In terms of other implications, if the key-state update function $e_n(\cdot)$ ...


2

Your Formulas are alright, but there is some additional information from the exercise/setup: The exercise states, that $F$ should be considered as a blackbox (otherwise you could use the internal stages of $F$, as poncho already suggested). However, as I understand it you can stil evaluate $F$ on any input of your choice. At this point, you can do a couple ...


2

After base64 decoding we get (hex) 5d f8 be 87 82 2b ea 5e f3 5c 23 fe 37 81 0f bd which has a size of two blocks. Of your small word-list, only marketing has so many letters that it needs two blocks: m a r k e t i n as the first, g 07 07 07 07 07 07 07 as the second (or another padding, but this is a common one), and so can correspond to this ciphertext. ...


2

See the Wikipedia article on 3DES: http://en.wikipedia.org/wiki/Triple_DES#Algorithm First of all, you are only using 2 keys, so you may want to follow a hybrid technique like this: encrypted = eK1( dK2( plainText ) ) plainText = eK2( dK1( encrypted ) ) However, because I'm not familiar with the DES algorithm, I can't guarentee that this approach is even ...



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