# Tag Info

27

The main difference is that with two 56 bit keys the maximal security level is 112 bit, and thus an attack that has a cost of $2^{112}$ operations is no attack, whereas for three 56 bit keys the maximal security level is 168 bits, and an attack that has a cost of $2^{112}$ operations counts as an attack. This means that two-key 3DES is still a bit weaker ...

24

Well, the standard answer is to preserve compatibility with DES; a hardware circuit that implemented 3DES (with EDE) could also be used to do DES as well (by, say, making all three subkeys the same). Now, there is one slight problem with this straightforward argument; 3DES (EEE, that is, with three encrypt operations) would have this property as well; if we ...

13

This claim is bogus. DES itself has a 13-round differential with probability around $2^{-47}$, so TripleDES with its 48 rounds is resistant to any sort of differential attack. The paper authors are not really confident in the subject.

8

DES has a block size of 8 bytes. Two blocks therefore come to 16 bytes. It looks like Adbobe were encrypting passwords using two blocks of 3-DES in ECB mode. Because all these passwords are eight bytes long, the second block is empty and is just filled with zeros. The second block gets started at all because of the string-terminating NUL character at the ...

7

The article mentions that 3-DES was used to encrypt these passwords in ECB mode. DES has a 64-bit/8-byte block. So let's say you use ECB to encrypt a nine byte password. The first 8-bytes are encrypted using ECB. So far so good. But what happens when we come to the ninth byte? Well we're now in a new block but only the first byte is populated with any ...

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

6

There is a very interesting paper that relates to this exact question (but you wouldn't guess it from the title). The paper is titled Efficient Dissection of Composite Problems, with Applications to Cryptanalysis, Knapsacks, and Combinatorial Search Problems. In Section 3, the paper considers the multiple encryption problem and gives novel attacks that are ...

5

The computational complexity of the attack you describe is $2^{112}$, since that's how much work it takes to build the look-up table. In fact, for standard 2-key 3DES like you describe, an attacker capable of building such a look-up table could just as well store $C = E_{K_1}( D_{K_2}( E_{K_1}( P )))$ instead of just $D_{K_2}( E_{K_1}( P ))$ in the table, ...

5

Note: I'll disregard the base64 encoding in the following text; the base64 encoding does not change the properties of the generated ciphertext. What you are running into is padding together with ECB mode. This padding can be any static padding. Most common is PKCS#5 padding, but zero padding is also possible. It is not possible to test which padding is used,...

5

Well, whether $AES'$ is as secure as $AES$ depends on the length of $k_1, k_2$. If they are both 128 bit, then what you effectively have is a standard 128-bit AES, except that prior to round 6, you replace the running key with an independent key (and you tweaked the last round, but that's cryptographically harmless). Now, it is never a good idea to do ...

5

<------------- key -------------> <-- plaintext -> <- ciphertext -> E62CABB93D1F3BDC 524FDF91A279C297 DD16B3D004069AB3 8ADDBD2290E565CE B619F870574A9E80 DAE6AB34C22CD626 058B92A4B28FB4EB A53DDC6B3098008F 6132C42C3E5E94EF 7A5152BF19AB739D 91993307EFBFB13C D13105386083E517 0245EAFE62DF92BF E319C29E9E2C3EA1 58BAA732CF5DBD77 EF37441D1FE7B73A ...

5

3DES is a block cipher which processes "blocks" of 64 bits. A block cipher is not sufficient to encrypt a message, defined as a sequence of potentially many bytes. Hence the use of a mode of operation which organizes things; this may imply some padding, and an Initialization Vector. TripleDESCryptoServiceProvider can do all that: you specify the key, the ...

5

In two key 3DES two keys are equal so that key size is only 112 bits, compared to the 168 bits of full 3DES. The advantage is a smaller key size without a correspondingly large loss in security: both two and three key 3DES can be attacked in about $2^{112}$ time. With the encrypt-decrypt-encrypt construction it clearly must be the first and last key that ...

4

Assuming the mod 11 check digit is among 0123456789X, disclosing it reduces the number of possible plaintexts among 8-digit numbers by a factor of about 11 (from 100000000 to about 9090909; exactly how much depends very slightly on the value of the check digit), thus reveals about $\log_2(11)$ bits of information about the plaintext, that is just a little ...

4

The answer is: Why do the encrypted files always start with "Salted__" ("U2FsdGVkX1" in base64)? Isn't giving away information like this insecure? The encrypted files must always start with "Salted_" to interoperate with OpenSSL. OpenSSL expects this. The 8 bytes that spell "Salted_" are always immediately followed by another random 8 bytes of salt. ...

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 $K_1$-$... 4 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. 4 My first thought was that I could set the IV to the first 8 bytes of the CT [and] decode the rest[.] This is exactly how CBC works. For all blocks but the first, encryption is defined by$C_n=E_K(C_{n-1}\oplus P_n)$and, therefore, decryption is achieved by$P_n=C_{n-1}\oplus D_K(C_n)$. Since there is no previous ciphertext for the first plaintext block (... 4 For high security applications using 3DES, NIST recommends using keying option 1 (all keys are different). This is simply because it's the safest. For any application, keying option 1 should be used. If you set K1==K3, then you are reducing your key size to 112 bits, which is less than the smallest key size for AES. Worse still, due to cryptanalysis done on ... 4 yes,it is possible because in meet in the middle attack on 3DES,see below with Complementation Property of DES in red arrow,you can search$2^{55}$key space instead of$2^{56}$,and for green arrow,you have$DEC_{K2}(ENC_{K1}(M))$that without key Complementation Property,you need$2^{112}$operations but with key Complementation Property of left ENC and ... 4 Definitely a mistake. The text clearly contradicts itself. ... 2DES has an effective key length of 57. And later... There does not appear to be a meet-in-the-middle attack on 3DES2 however, so that its key length of 112 is also its effective key length. which clearly contradicts 2DES, although having the same effective key length as 3DES2 ... 4 Yes, 3DES is a symmetric cipher and you use a secret key for both encryption and decryption with it. However, that is not the same thing as the keys used in RSA or other public key cryptography – you cannot (and should not) use either of them for 3DES. Since you are using S/MIME, you are actually using public key encryption. Any reference to 3DES is about ... 3 Yes. The following papers should be exactly what you are looking for. The following paper shows that the answer is "Yes" and provides evidence that 3-key Triple DES is more secure than single DES: Code-Based Game-Playing Proofs and the Security of Triple Encryption. Mihir Bellare, Phillip Rogaway. IACR ePrint 2004/331. (Full version of a paper ... 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 If you're asking why the X9.31 rng was designed the way it was, rather than some other way, I'm not certain if anyone other than the original authors could say. The core design dates back to at least 1985 (it was included in X9.17), and it originally used DES (and was later upgraded to use 3DES). I suspect that the original authors would not have been ... 3 I do not understand how can we decrypt a cypher which was encrypted with$K_1$, with$K_2$. Triple DES essentially involves three encryptions on the plain text. First is using$K_1$, second using$K_2$, and third using$K_3$. Now one may argue that$K_2$is not being used for encryption but decryption. Well, technically speaking, encryption and decryption ... 3 This is not a complete answer but it seems to me that it cannot be more secure than the original AES since otherwise it would mean that there is a serious weakness in the AES key schedule As far as being as secure there's at least one application in which it's a weakness : when you use AES inside a Davies-Meyer construction. An attacker has then more power ... 3 Yes, you can reasonably expect that these will provide equivalent security, if you choose all keys uniformly and independently at random. The decryption operation is basically the same as the encryption operation, so it would be extremely surprising if there was any significant difference in security among these. (Of course, if you don't generate the keys ... 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' | ...

3

No it does not affect the parity bits. The plaintext or ciphertext doesn't have any parity bits specified. The application key is just a input to the cipher, which is a Pseudo Random Permutation. Permutation means a 1:1 mapping from plaintext - including parity bits - to the ciphertext. If you perform the permutation in the opposite direction the plaintext -...

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