6
$\begingroup$

The system requires to be as paranoid as possible regarding security. One of the few contemplated changes to the current design is to use multiple encryption. First proposal was to use Serpent on top of AES-256, but after looking into it, it seems like a triple AES could also serve the purpose.

So the options are:

Encrypted(Input) = AES256(key2, Serpent(key1, Input))

And

Encrypted(Input) = AES256Encrypt(key3, AES256Decrypt(key2, AES256Encrypt(key1, Input)))

Where all keys are independent and randomly generated.

In performance tests with input that is supposed to be representative of what I would find in production second option (a triple AES) outperforms using Serpent, being around 20% faster.

As far as I'm aware, even though DES is completely broken, Triple DES still sustains a moderately safe resistance, even though one can use theoretical meet-in-the-middle attacks. So, even though I haven't spent much time on this, even if AES was somehow broken within the next 15 years, this would still offer a significant protection to the data (I would be expecting around 512 bits). Is this a correct assumption?

I've normally just gone standard in the past (sha256 with salts for stored passwords, aes 256 with secure random keys and ivs, and 4k rsa when asymmetric encryption is possible), so I never explored more complex escenarios until the past few days, so I apologize for my probable incorrect conclusions.

Improve this question
$\endgroup$
6
  • 5
    $\begingroup$ DES is broken because its key is small, not because cryptoanalysis advanced so much. An AES256 key is large enough. So the analogy isn't that useful. While it's likely that 3AES will be stronger that AES, I'd prefer a different algorithm, since you're trying to guard against cryptoanalysis of AES. $\endgroup$ – CodesInChaos Mar 11 '13 at 20:43
  • 1
    $\begingroup$ sha256 with salts for stored passwords <- that's weak. You need some iterated scheme, like PBKDF2, bcrypt or scrypt. See How to securely hash passwords? $\endgroup$ – CodesInChaos Mar 11 '13 at 20:45
  • 1
    $\begingroup$ If were were to use double encryption, I'd go with AES xor ChaCha (or Salsa20). Tahoe-LAFS will use some variant of this for its 100 year crypto. $\endgroup$ – CodesInChaos Mar 11 '13 at 20:50
  • 2
    $\begingroup$ No system is such that it "requires to be as paranoid as possible regarding security"; proof: any system only requires to be as paranoid as necessary, and it is possible to be more paranoid than that, e.g. by adding another encryption layer. Real threats are side-channel leakage, fault injection, system compromise, not AES-256 key size. Other from these, the only practically exploitable weakness of 3DES is its block size, not its 168-bit key length; even 2-key 3DES (112 bits) remains quite secure w.r.t. key recovery, see this. $\endgroup$ – fgrieu♦ Mar 12 '13 at 4:16
  • 5
    $\begingroup$ Something more useful than increasing AES's key width would be increasing AES's block width; that's a must e.g. to achieve $1−2^{−30}$ confidence (1 chance in a billion of the contrary) that an adversary can't distinguish if 16PiB of CTR-encrypted data is operational data or all-zero (notice that no two blocks can be identical in the later case). One solution for this is Rijndael with 256-bit block and key. $\endgroup$ – fgrieu♦ Mar 12 '13 at 8:48
3
$\begingroup$

It really depends on what sort of break AES would suffer. The primary issue with DES was that it's key length was too small (56-bits). Multiple encryption can help here because it increases the effective key length of the whole operation. The meet-in-the-middle attack on DES takes about 2^112 operations, which is infeasible to brute force anytime soon.

AES doesn't have an issue with keysize, so multiple encryption won't really help you that much in that sense. It really depends on what sort of attacks emerge on AES so it's hard to tell if multiple encryption will be better. It might be more secure, but it won't be a "huge" improvement and it's hard to judge.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Doesn't a successful attack basically just "decrease the strength (related to keysize)" of an algorithm? Wouldn't having 3AES still greatly increase the strength, no matter what the breakthrough is? $\endgroup$ – Florian Wendelborn Jul 28 '16 at 17:57
3
$\begingroup$

Your first option:

Encrypted(Input) = AES256(key2, Serpent(key1, Input))

suffers from a textbook meet-in-the-middle attack. It only gives you one additional bit of security over AES alone / Serpent alone. Not a good choice if you're aiming for extra paranoia.

Improve this answer
$\endgroup$
2
  • 8
    $\begingroup$ Well, it rather depends on what security vulnerabilities he's worried about. If he's worried about a brute force attack, you have a valid point -- however, with 256 bit keys, brute force is the last thing we need to worry about. If he is worried about a cryptographical breakthrough, then with this construction, a break of this would require a breakthrough against both AES and Serpent; less likely. On the other hand, what is almost certainly more vulnerable are the keys; this construction doesn't help that. $\endgroup$ – poncho Mar 12 '13 at 2:30
  • $\begingroup$ What poncho indicated is pretty much the argument in favor of using the first option (still upvoted both, your answer and his comment). 256 bits should be enough until we have some powerful quantum computing. The idea is that if either algorithm is ever broken (as poncho described "a cryptographical breakthrough"), the other still provides the protection. So "the level of security is at least as good as one of the two ciphers used". Protecting the keys is usually more important. Keys are (pseudo)randomly generated and are independent, so I trust them as much as I can. $\endgroup$ – Mamsaac Mar 12 '13 at 3:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.