TrueCrypt encryption algorithms

I wonder what would happen in this hypothetical situation?

What if I create file containers with Serpent-AES and one day AES is broken?
Or, if I create file containers with AES-Twofish-Serpent. AES and Twofish become broken one day?

Or any other cascade example.

If I use cascade encryption will 1 broken algorithm make it possible for an adversary to have partial access to the container? Or they need to break every algorithm used to have any kind of access to the container?

Is it safer to use cascade, even if one of the used algorithms can get broken in near future? Or to choose a single algorithm which is highly unlikely to get broken during my lifetime?

 

The Truecrypt site states that it's best to use multiple encryption algorithms to prevent the problem you state, which is the possibility of one of the algorithms being cracked. They say that if you use two or even three of the algorithms, this ensures that if one is cracked, your data is still protected as the chances of having all three cracked is extremely slim.

 

The strongest of a crypto system is the cipher. It is the least likely to be broken. There may be little real benefit to adding more to the strongest part of the system. The more complex implentation has risks associated with it.

 

Not to mention the performance impact of having a double or triple cipher.

And if AES was broken in the next few months, then the gov't has a lot bigger problem since AES-256 is approved for Top Secret classified materials.

 

A few quick thoughts.

I'm running on fumes, time-wise, so I suggest taking a look at my posts; in that list, you'll find some discussions about this very thing. When I work with developers, I recommend sticking with a single primitive; this is because the likelihood of an implementation mistake is a stack of magnitudes greater than the likelihood of a practical cryptographic attack. I usually suggest the AES, and the AES alone; it receives more cryptanalytical attention than any other block cipher and can easily be used as the underlying primitive in IND-CCA2 /\ INT-CTXT secure authenticated encryption composite schemes.

IND-CCA2 /\ INT-CTXT provides you with the strongest notions of confidentiality and integrity we've got. There's no need for a horde of primitives or cascades; this doesn't make TrueCrypt better in any cryptographic sense. You might think, the more TrueCrypt offers, the more options we have; in reality, the more options you have, the more complexity you introduce to the implementation. Complexity is the bane of practical cryptography; it's almost always the reason it fails in practice.

Implementations should do a lot with a little. Don't minimize the least likely threat while maximizing the most likely threat; it's a ridiculous trade-off. Worry about the implementation -- not the cryptography. Assuming TrueCrypt implements its cascades properly, then using them won't hurt*; if you don't mind the overhead, then go for it. However, cascades isn't a character trait of TrueCrypt that I would recommend future cryptographic applications to be influenced by.

* Using code-based game-playing techniques, we know that for a cascade of n ≥ 3 block ciphers, security is improved significantly over single or double encryption; it is still, however, an open question as to whether or not security increases as n increases.

 

Thanks for all your posts Justin. I'm sure you haven't had an intention to promote any program when you were making your posts.

TrueCrypt indeed has a lot of complicity. But still, I doubt their developers are weaker in any way then developers of other popular encryption programs. And since TrueCrypt is very actively developed I doubt they can make mistakes which they wouldn't fix in the next version. X.0 versions are often buggy and even have a few flaws. But with X.1 it always looks very smooth and reliable. I figured out your point but cascade still looks much more better to me. Who knows what can happen tomorrow? And who knows what is going on behind closed doors?

 

Yea... But keep in mind that even TC can have a bug that it doesn't patch.

Starting with v6.0, it is impossible to make a backup of a header that uses keyfiles. It was not fixed in v6.0a. Hopefully it is by v6.1, but that was a big bug to slip through.

 

I could have sworn I just did this the other day, so I just made a test container with a keyfile, backed up the header, and restored it. It seemed to work ok.. Is there some known problem that I'm not aware of or am missing here?

 

Ok. I know people are having problems with this. Try it with a hidden volume. That may be the catch. I don't have access to the forums (been down for days) to get the details, but I know there is a problem with header backups that use keyfiles. I thought it was across the board, but try backing up a hidden container header that uses a keyfile.

 

That must be where the problem is... In my test it said I was giving the incorrect password/keyfile for the hidden container..

That's a good thing to know if I ever make a hidden volume...