4
$\begingroup$

I want to encrypt a small amount (few kilobytes) of data and be fairly confident it will be secure against brute force decryption and advances in cryptanalysis for at least a a few decades (or more). I am flexible on the amount of time it takes (even a minute is reasonable) to encrypt as this will run on the client machine, and not on a server.

My thought was to combine a few encryption algorithms over an iterative process - each iteration with a fresh key. The reasoning being:

  1. Multiple iterations increases the time necessary for each brute force attempt.
  2. Multiple algorithms means a failure in any one algorithm doesn't compromise the whole encryption.
  3. Multiple key effectively increases the key size to astronomical.

So it might look like this:

CipherText = AES(TwoFish(Serpent(PlainText)));

Except with many more layers of nesting (repeating the selected algorithms). Each layer will have a CSRNG generated Key and IV and use CBC.

  • Is this a good idea?
  • Does the nesting increase the security, or does it somehow introduce a new vulnerability?
  • If this is a good idea, which algorithms would be best to use?
  • Would it be better to use asymmetrical algorithms instead of symmetrical ones?
  • How many iterations is enough?

I'm fine with it being overkill. Just want to make sure it isn't going to make things worse.

Updated to specify resistance to cryptanalysis, use of CSPRNG for Key and IV and using CBC. Also removed references to outdated algorithms.

|improve this question
$\endgroup$
  • 1
    $\begingroup$ The main issue is, From where do you get the keys? Do you expect the user to enter 1000 key bits manually? If you use a normal password, that is most likely the weakpoint in your scheme. And you didn't specify a chaining mode, or if you're suing a MAC. $\endgroup$ – CodesInChaos Sep 2 '12 at 10:54
  • 1
    $\begingroup$ Do you want to be secure only from brute force (then everything with a 128 bit key size should be enough), or also save from advances in cryptanalysis? The latter is harder. $\endgroup$ – Paŭlo Ebermann Sep 2 '12 at 10:59
  • 3
    $\begingroup$ But where does your user keep the key? Does he print it? Does he memorize 1000 bits? $\endgroup$ – CodesInChaos Sep 2 '12 at 15:30
  • 2
    $\begingroup$ If you have a separate system that you trust to hold the keys, why don't you just put the plaintext on that system, and not bother publishing an encrypted version? This is provably secure against any cryptanalytic attack. $\endgroup$ – poncho Sep 2 '12 at 16:09
  • 3
    $\begingroup$ @JimMcKeeth: if that's the case, why not use a secret sharing scheme. In the specific case where there are two parties, and you need both to recover the text, you can do this simply by generating a truly random string $S$, and give one party $S$, and the other party $S \oplus Plaintext$. $\endgroup$ – poncho Sep 2 '12 at 16:25
6
$\begingroup$

Is this a good idea?

Not really.

It is rare to find attacks against vetted designs that allow a complete break with a tiny amount of cipher-text.

Assuming you plan to have a unique key (which isn't used anywhere else) for just this few kilobytes of plaintext, it's very unlikely any cryptographic attack could be mounted against any modern cipher that would recover the plain-text.

Honestly, your message is likely to be absolutely fine encrypted with AES.

It's very unlikely someone's missed a key-recovery attack on AES that can be conducted with a few kilobytes of cipher-text.

Does the nesting increase the security, or does it somehow introduce a new vulnerability?

It is possible to do this badly and introduce a new vulnerability, yes.

If this is a good idea, which algorithms would be best to use?

Just use AES in GCM mode.

Would it be better to use asymmetrical algorithms instead of symmetrical ones?

No.

How many iterations is enough?

One iteration of AES in GCM mode is enough.

|improve this answer
$\endgroup$
  • $\begingroup$ Thanks Simon. Good advice. Was not familiar with GCM but will do some research and see if I can find an implementation. Was going to use CBC. $\endgroup$ – Jim McKeeth Sep 3 '12 at 2:30
6
$\begingroup$

  1. Where are you going to keep the key for those decades? That is the point of attack.

  2. Regardless the answer to #1, for such a small amount of data use a one time pad. However you planned to keep the key secure for the intervening decades, use it to keep the pad safe.

|improve this answer
$\endgroup$
  • $\begingroup$ Ignoring that this "answer" reads more like a comment… please note OTPs are not a magic solution to crypto problems. In the case OP described, you'ld end up with a one time pad of a few KBs length (read: exactly the same length as the plaintext). Why on Earth would you want to do that when you can achieve the same with a 256 bit key (=32 bytes) and a well-vetted cryptographic encryption algorithm? Practically you're advising to trade 32 byte keys with much larger OTPs having a length of >= 1000 bytes. That's a pretty wasteful suggestion, and definitely not optimal for long-term key storage. $\endgroup$ – e-sushi Oct 21 '17 at 2:59
3
$\begingroup$

Serpent alone should be safe for a few decades, infact most of the last AES finalists will be secure for that amount of time. I would say you can be sure that the data would be secure with a combination of Serpent and Twofish, Twofish isn't even remotely theoretically broken and Serpent has had much juice over it saying how secure it is. Also, I wouldn't recommend using Blowfish and Triple-DES with the other ciphers due to their 64-bit block size, compared to the other's 128-bit block.

EDIT: Be careful how you generate the keys, use a CSPRNG, or even multiple CSPRNGs who's out put have been XOR'd with eachother. If the keys have any sort of obvious relationship, it will probably be drastically easier to crack the rest.

|improve this answer
$\endgroup$
  • $\begingroup$ "Serpent alone should be safe for a few decades" That's one bold claim, and past history doesn't really support this conclusion. Care for some references? As for CSPRNG's, it would be better to hash their outputs together, as XOR'ing them can destroy entropy and in general do more harm than good. $\endgroup$ – Thomas Sep 2 '12 at 12:11
  • 1
    $\begingroup$ Yes, I'd support the hashing idea. However, Serpent really is secure. Even the XLS attack won't weaken it much. After all, the AES submissions were expected to last for a long time, if I can remember right ( don't hold this against me, my memory is less effective than a goldfish's ) it was more than "a few decades". $\endgroup$ – Erkling Sep 2 '12 at 12:21
  • 1
    $\begingroup$ Also, the estimate of the time it would take to break Serpent came from an official document, it said that Rijndael would probably be secure for at least twenty years. Serpent, which is widely considered more secure than Rijndael as far as I can tell, would therefore ( according to common sense ) last longer, by how much, I am not sure. $\endgroup$ – Erkling Sep 2 '12 at 12:37
  • $\begingroup$ Like I said, I'm fine with overkill. Does combining Serpent and Rijndael like I'm describing improve the strength? $\endgroup$ – Jim McKeeth Sep 2 '12 at 15:31
  • 1
    $\begingroup$ When combining multiple ciphers, ( provided their keys do not have a strong linear relationship ) security increase greatly. Also, I thought about what I said with the two 64-bit block ciphers, and this might actually be a good idea to introduce more key material to the block, since Blowfish has a maximum of 448-bits ( I think? ) wide key. $\endgroup$ – Erkling Sep 3 '12 at 17:04

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.