# Tag Info

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

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

Actually, because of DESX works, the meet-in-the-middle attack can be optimized to take $2^{119}$ $DES$ (and no $DES^{-1}$ operations), and no additional storage. Here is how it works: let us assume that we have three known plaintext/ciphertext pairs $(P_1, C_1)$, $(P_2, C_2)$ and $(P_3, C_3)$. We know that: $$C_1 = K_2 \oplus DES( K, K_1 \oplus P_1 )$$ ...

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

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

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

It looks like there's an error in the test vector. The text of Appendix B.1 states: P1 = “The quic” = 5468652071756663 ... which is incorrect. The hex encoding of The quic is actually 5468652071756963 (note the transposition of the i/69 to an f/66 in the encoding. e.g. encrypting the test vector as intended: $echo -n 'The quick brown fox jump' | ... 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 Your problem is which part of the algorithm has to be transmitted (and you are missing an actual IV). Your encryption algorithm of using$TDEA(m)=E_{K_1}(D_{K_2}(E_{K_1}(m)))$is fine for encrypting a single block, and it can be used in CBC. However, in CBC with a message of 4 blocks$m=(m_1,m_2,m_3,m_4)$, you calculate this: Choose random$iv$. ... 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 ... 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 According to the following link (Slide 5) and to what I studied last semester, http://www.ee.ic.ac.uk/pcheung/teaching/ee4_network_security/L02DESIDESAES.pdf During the final round (Round 16) before the inverse permutation, the left and right halves of the bits will be swapped then the inverse permutation will be applied. 2 This is known as the "key complementation" property of DES; I had thought that it actually predated Biham and Shamir's work. In any case, your questions: Does this hold for only that particular combination of s box or it will be same for any S-box combination It'd remain even if you change the sbox's arbitrarily. The reason for this is that it is not ... 2 Put another way, you can say that the key is whatever information the recipient possesses which allows him to decrypt the message, and which must be kept secret from everybody else. Thus, "algorithm" and "key" are not mutually exclusive: if knowledge of the algorithm allows one to decrypt a message, then the algorithm is the key. 2 Picking up what has been said in the comments: to simplify: symmetric ciphers are like mathematical operations with 2 operands and 1 result. There is The plaintext message$m$and$k$as the key and they result in the ciphertext$c$. In your example, the algorithm can be cut down to a addition and modulo:$c = (m + k) \mod k_{max}$And of course there is ... 2 There are a couple of things going on: First of all, the DES key FF FF FF FF FF FF FF FF happens to be a "DES weak key"; by that, we mean that if you send a block through the cipher twice, it'll end up with the original value; that is: $$X = DES_{weak}( DES_{weak} ( X ))$$ You are obviously encrypting in CBC mode with a zero IV. So, let us look at what ... 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 The key space for DES is far too small (56 bits). Therefore, any use of DES is not secure. It doesn't matter what mode you use. If the attacker has one plaintext, ciphertext pair, they can brute force the key space and recover the key in a feasible amount of time (24 hours using the cloud). But most importantly, how it could be made secure? Will change ... 2 Yes, it would be more secure if they were used correctly. But as it would require a substantially different algorithm, you really would not be talking about DES anymore. Brute forcing usually scales exponentially with the size of the key. However, if the algorithm is substantially altered then it is required to analyze the algorithm again. Note that AES is ... 2 That's an optimization for the attack. It would work without it, but slower. To do a Meet-in-the-middle attack, we need to encrypt a known plaintext with every possible key and save the resulting text (with the used key) in a list. Now we decrypt a known ciphertext with every possible key and look if we got the resulting text in our list. We want to know ... 2 I understand that if a block cipher has$k$-bit keys and$n$-bit input/output blocks, then if$k>n$, we can expect one message-ciphertext pair to narrow us down (I think?) to$2^{k−n}$possible keys, right? That is approximately correct (if the block cipher with the wrong key acts like a random permutation; this is generally a safe assumption); if ... 2 Feistel networks were broken in DES but not triple DES. Some final AES candidates not approved also used Feistel networks$2^{36}$plain text attacks. Reduction of$2^{16}$possible keys for single DES:$4^{48/6} = 4^{8} = 2^{16}$. First for a one round Feistel network:$R_0$and$f (R_O, k_1) = R_1 \oplus L_0$,$k_1$becomes known. For two round Fiestel: ... 1 For 1) you need to show that$S(X)$is linear with respect to xor. We can define$S(X)$as:$S(X) = (x_{7}, x_{0}, x_{1}, x_{2}, x_{3}, x_{4}, x_{5}, x_{6})$And define$A \oplus B$as:$A \oplus B = (a_0 \oplus b_0, a_1 \oplus b_1,a_2 \oplus b_2,a_3 \oplus b_3,a_4 \oplus b_4,a_5 \oplus b_5,a_6 \oplus b_6,a_7 \oplus b_7,)$So we have:$S(A \oplus B) = ...

1

I think this would effectively make your cipher a single round. Key mixing is usually an XOR operation of the round key on the current state. XORing all of the round keys at once is effectively only xoring a single key. If you have an $n\times n$ bit s-box $s(x)$ (e.g. Rijndael's sbox), then $s(s(x))$ is just another sbox which can be expressed as a lookup ...

1

It is not at all secure if you fix the key and IV in the code, no matter what language you use. Ideally you should generate the key from a password based key derivative function like PBKDF2 or SCRYPT or provision the key from an external key management server. You also need to chose a encryption mode along with the scheme. The modes are picked based on the ...

1

In general, the key length and number of rounds are the dominant factors in deciding cipher strength. But you need to consider how the rounds are constructed and how the key is used. Substitution and permutation are the bread and butter of DES. That's literally all it is - substitution, permutation, and XOR. Here is a diagram of the DES fiestel function ...

1

I assume you are asking how the password a user enters to unlock their saved user data is translated into the keys used by 3DES? According to this link DES-EDE-CBC, which is only two-key 3DES. The first and third keys are set equal to each other, resulting in two keys of 56 bits or a total size of 112 bits. To get that key material from a password, a ...

1

Here is what I suspect is going on: The all-zero key in DES is a weak key; it has the property that encrypting a block twice will result in the original block; that is: $E_0(E_0(M)) = M$ for all blocks $M$. In PCBC, we encrypt a block $P_i$ by taking the previous plaintext blocks $P_{i-1}$ and the previous ciphertext block $C_{i-1}$, and computing the next ...

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