7

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.

Mamsaac
  • 343
  • 3
  • 7

3 Answers3

3

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.

Oleksi
  • 1,018
  • 12
  • 23
3

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.

Mikero
  • 14,908
  • 2
  • 35
  • 58
-1

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.

William M. Rawls
  • 1
  • 2