Tag Info

Hot answers tagged

20

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


17

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


12

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


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


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


4

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


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


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


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

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


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

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


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


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


2

Short answer: (Probably) yes. Long answer: DES is a Feistel cipher, and therefore encryption and decryption are almost the same process. The only difference is the reverse order of the subkeys. There are theoretical attacks on DES, which might have to be adjusted if you use reverse order of subkeys for encryption. If these attacks target the subkeys ...


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

ECB leaks the identity of blocks. After padding some blocks on the end will be eminently predictable, for instance a block with a single 'e' and all zero padding.


2

To generate an IV securely for CBC mode, there are two obvious ways to do it (and both are cited by NIST): For each packet, select a nonce (the IPSec sequence number, padded out to 64 bits, works fine), encrypt that in ECB mode, and then use resulting ciphertext block as the IV. An equivalent way to do that is to take your 64 bit nonce, prepend that to ...


1

It is the case. All 8 character passwords in the leaked file end in "ioxG6CatHBw==" Source: http://pastebin.com/iDTFARwq


1

Knowing the check digit and the algorithm reduces the possible set of numbers from $10^8$ to under $10^6$. If there are other pieces of data available to the attacker (initials of the customer, ZIP code, etc.,) there could be enough information to correlate the customer with other sources of data without ever learning the account number. That may or may not ...


1

It's probably the generation of the IV that takes the time, not the 3DES encryption. 3DES encryption itself should indeed at least scale with the size of the plaintext.


1

One option is that your benchmarking code isn't exact enough to show the small differences. With long enough inputs the time should scale linearly with the number of 64-bit blocks. However, with small inputs, like your 1 vs. 125 blocks, it is possible to see the symptoms you describe – scaling decryption time, but approximately constant encryption time. You ...



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