# Tag Info

51

Well, yes and no. Triple DES using 3 different keys is still considered secure because there are no known attack which completely break its security to a point where it is feasible nowadays to crack it. The Triple DES algorithm provides around 112 bits of security against bruteforce attacks (when taking into account the meet-in-the-middle attack). For ...

34

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

33

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

24

In my opinion, there are no reason to choose 3DES over AES, ever. Especially if it is in software, since 3DES performances have always been terrible. Furthermore, most CPUs ship with AES accelerators nowadays, which means that AES is even faster. But, sadly, change management is hard, certain smart card or hardware module do not support AES, but support ...

14

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 competent in the subject.

11

There is none. All cryptography involves the number 2, which is prime, whenever dealing with information in strings of bits—or in esoteric cases like ROT13, well, there's a prime number right there, 13, not to mention that 26, the size of the alphabet on which ROT13 works, is the product of primes 2 and 13.

9

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

9

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

9

The triple DES (3DES) block cipher works by essentially running the block through DES three times. Triple DES is also known as "DES EDE" (encrypt-decrypt-encrypt) and under the name given by the standard document: "TDEA". The TDEA algorithm is described in FIPS NIST Special Publication 800-67 Revision 1 where paragraph 3.2 describes the TDEA Keying Options. ...

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

8

NIST just recently (11/27/2017) put out a bulletin that Triple-DES will be deprecated in the future, and will be disallowed in protocols like TLS and IPsec, with a future deprecation timeline to be released. NIST is urging vendors to transition TLS implementations to use AES as soon as possible. It will soon be removed from the set of FIPS approved ...

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

Three problems here: The online tool used expects a 24-byte (48 hex-character) key; thus you should enter E6F1081FEA4C402CC192B65DE367EC3EE6F1081FEA4C402C as the key, duplicating the first 8 bytes; this is the customary way to extend a two-block triple DES key of 16 bytes to a three-block triple DES key of 24 bytes. You gave 16 bytes (32 hex chars) as input,...

7

As far as I know your attack is the best attack known, unless something better has very recently been published. Please note that for DES as the basic cipher the chosen $A$ may not work, but you can choose another $A$ and try again Also, for a generic cipher with $k$ bit key, the complexity is $$2^{k+1}=2\times 2^k=O(2^k),$$ as $k$ increases.

6

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

6

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

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

6

EEE with $K_1$=$K_2$=$K_3$ is measurably less insecure than EDE with $K_1$=$K_2$=$K_3$, because the former has 48 rounds, but the later reduces to just one encryption E, thus 16 rounds. Two consequences: This makes brutes force require 3 times more rounds, thus adds about $\log_2(3)\approx 1.58$ bit of practical security against brute force (security in ...

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

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

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

5

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

5

I am learning the meet-in-the-middle on DES attack. I don't know of any meet-in-the-middle attack on DES; I'll assume you're talking about 2DES (where you apply DES with one key $k_1$, and then apply another iteration of DES (possibly in decrypt mode) with another key $k_2$. why can we guarantee to find one and only one pair of k1 and k2? We don't. In ...

4

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

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

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

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

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