Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Which is more secure:

  1. use one container encrypted with AES > Twofish > Serpent = 768bits key size
  2. make an AES container, and inside it make another Twofish container then inside it make a third Serpent container

Which is more secure and which is faster, or are the two ways the same fast 30Megabits/sec?

The goal is to have a secure backup to be placed on CD.

share|improve this question
5  
The entropy of you password is the most important thing to take care of. Make it really long and complex. –  CodesInChaos Mar 29 '12 at 20:40
1  
You should also never copy a container, only copy the content into a new container. i.e. an attacker should only have access to a single version of each container. –  CodesInChaos Mar 29 '12 at 20:42
    
ok after a little thinking and testing, i think that if i make a a three container a,b,c with size 1,2,3 MB and put the data in container a then copy the a to b then cope b to c... when some one break the container c he will fine another one b so he need to start again when he done with it he will find container a if he really hve the time to crack container a he could find more containers inside, so 3 containers inside each other with 3 passwords will be pretty madness secure than one container encrypted with one password, that what i think, if any one think different please join ;) –  rezx Apr 9 '12 at 12:15
    
I have already linked you to good answers which clearly illustrate that brute-forcing a 128 bit AES encrypted personal backup is ludicrous. Your convoluted scheme wrapping encryption inside encryption doesn't meaningfully improve security, but does make it more likely you'll forget something and be unable to restore your backup. Just use 128 bit AES (or 256 bit if you must), and make a good passphrase, keep that passphrase secure, but also be sure you can recall that passphrase years from now. And watch out for keyloggers / eavesdropping (which your scheme doesn't help against either). –  Jesper Mortensen Apr 9 '12 at 12:41
3  
A single container with a password of length 3*n is much more secure than three containers with length n each. Cracking the first has a complexity of base^(3*n), cracking the seconf a complexity of 3*base^n. –  CodesInChaos Apr 9 '12 at 19:39
show 2 more comments

3 Answers

You are looking in the wrong place. :-)

A basic dictum of security is to fix security issues which can be easily exploited before fixing issues that are hard to exploit -- which is just common sense.

The symmetric-key algorithms used in Truecrypt are already plenty strong. Look at this previous answer on AES before proceeding, please.

Your main concern should be key management, i.e. picking a good passphrase and keeping it secure. See here how an attacker would really go about attacking a Truecrypt volume.

From a typical security standpoint, it's senseless to use algorithms with a higher security margin than 128 bit AES unless your passphrase also provides sufficient (192 bit, 256 bit) security margin. See the handy table from Wikipedia to estimate how long a completely randomly chosen password or a Diceware based password would have to be to match 256 bits of entropy.

Creating, keeping and sharing high quality passphrases in a team is quite hard to do in practice. Focus your efforts there.

share|improve this answer
add comment

More secure: think both ways are secure in the same level. Each block will be encrypted with aes, then the result will be enc. with twofish, then with serpent.

I think the first alternative will be faster, since this cascade of encryption will be done in memory in the first case, and in the second case there'll be some volume management being done in the middle of each kind of encryption.

Note that even the hidden volume of the truecrypt isn't done using that cascade: you have two volumes, one inside the physical area of the other, and only that.

But are you sure you need that much encryption? Sometimes it might be better to spend the time / effort in other points of the security (like preventing some cold boot attack) than being too worry about cascading encryption and not taking care of the other links of the chain.

---- After comments ----

If you're worried about making a secure backup, you could have asked that, probably you'd get better answers. But to continue the Truecrypt use, I'd use something like that:

  • create a Truecrypt volume with aes;
  • inside it, create another volume with serpent, using a different password;
  • put all the files inside it;
  • take the truecrypt outer volume (aes), take a portable truecrypt (since you'll need it do decrypt in the future, who knows how long truecrypt will be available), and then Zip them together, using encryption. For example, use 7zip to do that, with encryption enable;
  • make sure to backup the volume and the 7zip executable (or a portable version), for the same reason...

That way you'll be usign two encryption algorithms (aes and serpent), three passwords (2 on truecrypt, 1 on the zip file), and finally two implementations of the aes (one in truecrypt, one in 7zip, who knows if any of them has a problem...)

share|improve this answer
    
aes is enough secure i use it as it more speed than others but i was thinking of making a backup putting there my personal stuff and may place it on cd and keep it and want it to be super secure so its not crack years later if i lost it or something –  rezx Mar 29 '12 at 17:19
    
ya that's better idea thanks for ur help –  rezx Mar 29 '12 at 18:23
    
all i can find is Was this post useful to you? and will just click yes, thanks –  rezx Apr 6 '12 at 12:15
add comment

Encrypting with cascading cypher is more secure than nested containers in terms of pure cryptography/methematics (i better not go into details). HOWEVER, encrypting two nested containers with two different passwords (your passwords, not different passwords derived by TC from your longer initial password) might prove more secure in case there is some bug in the implementation of TC (especially if you use different algorithms, which you should). MOREOVER..... if you are really paranoid, and if you assume that your backup CD is likely to be compromised, in this case, the chances of decrypting it, even 1 in a million will mean for you many sleepless nights (that i can understand). This is the worst case scenario and also very probable - your CD gets lost/stolen/confiscated.... and you have no idea who is working on it.... most probably it will be thrown away, but you never know, the NSA may get into action..... So my suggestion in this case:

  1. Create the internal container with TC, using 3 cascading cyphers and a really good password. For added security you might even consider keyfile(s), but mind the need to backup them too. You might even consider creating a hidden volume so in case you have to disclose the password you have some sort of solution.
  2. Create the outer container (where you should store the internal container) using DIFFERENT software (freeotfe, scramdisk, just to name a few) and different password. Use different encryption algorithm, if available, but dont use some self made algorithms, be sure to stick to the 4-5 really secure (for now).
  3. Store the 2 different encryption software programs into your CD (best to encrypt them in some self extracting archive, so you dont need another software to decrypt these). Thats it.... the biggest concern in my opinion is that TC (or any other software) might be corrupted, backdoor, bad implementation, any bug that may pop up in future. If your CD is stolen and the real chance of TC being weak is 1 to 10000, then i promise you many sleepless nights. If you use the above technique though, then your chances are 10000*10000 = 1 to 100 million -> much better i think.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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