Hacker News new | past | comments | ask | show | jobs | submit login

Would this suggest that 3DES with a sufficiently long password is still safe for now?





This suggests you don't understand how DES-based crypt() worked, so let's take both angles here:

1. Would it be safe to build a password hash like crypt() based on 3DES today?

Maybe, kind of, it depends, don't do this. "Based on" is key here. You'd have to come up with some way to try to use 3DES in this fashion, just as the developers of Unix crypt() used DES. Basically you're trying to build a cryptographic hash out of a primitive that's not really intended for that purpose, you also need to add more salt than the Unix team did back then, and then you need it to run very slowly, preferably on everybody's hardware not just the generic (likely x86-64) general purpose CPU you're using. Lots of people already built _good_ ways to do password hashing in the 21st century, and if none of those are available somehow you should just use PBKDF2 with SHA256 and a nice big iteration count and that'll be tolerable.

2. Oh, I didn't realise, I just meant is 3DES fine for encryption?

You should not do this. The main thing wrong with DES is the key size is too small, which 3DES fixes (effective key size with full 3DES is 112 bits, which is very short today but probably not the biggest hole in whatever security system you're building). But the next biggest thing wrong with it is that it's a block cipher with a small block size, 64-bits. 64-bits is small enough that bad guys may be able to collide your blocks and set fire to everything. To avoid this: Don't use 64-bit block ciphers, go get a real cipher like AES that uses 128-bit blocks. Done. Why are you still here? Could it be secure if you can defuse the collision risk (e.g. you only encipher very small amounts of data)? Sure, but now you're defining the problem to make the choice of primitive look safe, which is always a terrible idea.


Thanks for the great answer. I am not familiar with DES but the reason I wondered about this is because I saw that some VPN hardware devices still has 3DES as an option and even as the default encryption algorithm. I was really baffled by this because I had assumed that 3DES has completely fallen out of favor. So I guess the company isn't choosing sensible defaults. But at the time, I thought maybe they knew something I didn't (although I still switched the algorithm to AES since there's no reason not to).

Doubt it. It took 4 days for just one top of the line GPU. Any dedicated attacker will have farms to parallelize it even further. It’s not exactly linear, but with just 4 GPUs (~$4000; well within the reach of any dedicated attacker), that’s one day. Not to mention the fact that GPUs have still been roughly following Moore’s Law in terms of performance.

It’s probably safe from the casual attacker who just downloads a password list and runs a one word dictionary attack, but for a dedicated attacker, let alone a nation state, it’s not secure.

TL;DR: Just use AES. Even an ASIC isn’t powerful enough for that. Searching the entire key space would take more energy than the universe has. Compare that to DES that can have its entire key space searched in a few days.[0]

Edit: you said triple DES, not single. My point still stands. DES, even 3DES, is not secure. If I can crack a DES password in 4 days, I can crack a 3DES password in 12. AES with a strong password is virtually uncrackable.

[0]: https://en.wikipedia.org/wiki/EFF_DES_cracker


> If I can crack a DES password in 4 days, I can crack a 3DES password in 12

It's multiplicative, not additive. 3DES is about 2^56 times as difficult to crack as DES. (Not 2^112 times because there is an attack that effectively limits it to twice the effective bits of DES, rather than the three times you might expect at first).


> there is an attack that effectively limits it to twice the effective bits of DES

* Meet-in-the-Middle attack.

https://en.wikipedia.org/wiki/Meet-in-the-middle_attack

This attack is surprisingly simple, if you encrypt the message twice by

    ciphertext = encrypt(encrypt(message, key1), key2)
Then,

    decrypt(ciphertext, key2) == encrypt(message, key1)
An important security property all symmetric ciphers should offer is immunity to chosen-plaintext attack, if the attacker controls "message", it shouldn't make the cipher more easy to crack.

But in this case, the attacker can obtain all the 2^56 possible encryption of message by enumerating key1, put it in a lookup table (assume the table-lookup time is O(1)) , then we can try all possible decryption of ciphertext by enumerating key2. Then compare it with the lookup-table for a match, bingo!

If key is 56-bit, the attacker gets 2^56 outputs for the left side, 2^56 outputs for the right side, total number of operations is 2 x 2^56 == 2^57, not 2^112.

To increase the security claim to 2^112, we need triple encryption, not double encryption, thus 2DES is never used.

The idea that simple double-encryption doesn't work because of such a simple attack shocked a lot of newcomers.


This is mostly irrelevant in the context of password hashing however. We're simply feeding passwords into a blackbox at X/s until we get a match. 3DES runs at approximately X/3 compared to DES. If it takes 4 days to feed a bajillion passwords into DES, it takes 12 days to feed the same number into 3DES.

It might be relevant, because the original asker said "with a sufficiently long password". (Implicitly: with a password longer than 8 characters that the original DES scheme would allow.)

It's more complicated than this, because there are known attacks against 3DES. It's at most 2^28 times more complex, AFAIK, but there are probably better attacks than the few I know.

Are any of these attacks relevant to password cracking?

> It's multiplicative, not additive. 3DES is about 2^56 times as difficult to crack as DES. (Not 2^112 times because there is an attack that effectively limits it to twice the effective bits of DES, rather than the three times you might expect at first).

If you’re using 3 different keys, yes, that makes sense. But if you’re just keystretching one key, wouldn’t it just take 3 times as long because you encrypt, decrypt, encrypt (3 processes)?


3DES is a little more secure than plain DES (but still worse than AES)



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: