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

$\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$ Commented Mar 11, 2013 at 20:43
  • 2
    $\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$ Commented Mar 11, 2013 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$ Commented Mar 11, 2013 at 20:50
  • 3
    $\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
    Commented Mar 12, 2013 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
    Commented Mar 12, 2013 at 8:48

3 Answers 3

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.

$\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$ Commented Jul 28, 2016 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.

$\endgroup$
2
  • 9
    $\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
    Commented Mar 12, 2013 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
    Commented Mar 12, 2013 at 3:19
-1
$\begingroup$

Key/IV chosen from private, secured pool of keys chosen based on a supplied date and time, never repeating the key and IV (Think TKIP). Old packet can be discarded and replay attacks are easy to detect.

x = AESEncrypt(RandomBlock1 + Hash(Input) + Input + RandomBlock2 + RandomPadding)

y = SerpentEncrypt(RandomBlock3 + Hash(Reverse(X)) + Reverse(x) + RandomBlock4 + RandomPadding)

z = AESEncrypt(RandomBlock5 + Hash(Reverse(Y)) + Reverse(y) + RandomBlock6 + RandomPadding)

Encrypted(Input) = FixedHeader + DateTime(source) + z

Private key/IV store on both ends must be secured.

RandomBlock# must encrypt to at least one encrypted block's length or more.

RandomPadding to ensure Input encrypts to exactly block size.

$\endgroup$
3
  • 1
    $\begingroup$ Please do not answer without understanding it. I can't make sense of your answer from the context of this question. $\endgroup$
    – DannyNiu
    Commented Aug 2, 2022 at 5:50
  • $\begingroup$ Can you elaborate on this more? It's unclear what you're trying to say and if/how this addresses the concerns in the question. $\endgroup$ Commented Aug 3, 2022 at 16:32
  • $\begingroup$ That's probably true. Plus there's a couple things to add. Think of it as a triple AES with randomized blocks of inserted data and making sure the final decrypted block contains exactly enough to fill the block. Finally a hash to try to make sure the encrypted content has not changed. Anyway. Probably not a good answer, just how I tackle encryption when it really, really matters. Also, the question says it should be as paranoid as possible which this set of steps achieves. $\endgroup$ Commented Aug 11, 2022 at 1:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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