Hi

I have set up an encrypted LVM volume with dm-crypt (with luks). When i do a "cryptsetup status <device name>" i see that the key-file seems to be pretty weak, its 128 bits (which is the default when the cryptsetup command is used to set up encryption).

When im creating keys for SSL certificates the key is also very weak by default, i think its 128 bits here too, so in the script i created that creates these keys i had to override this setting with 1024 bit. My questions are:

- Is 128 bit way too weak for disk encryption, should it also be set to 1024 bit instead ?
- Is "aes-cbc-essiv:sha256" a cipher that you can recommend and is it safe ?

How about when you are installing debian or ubuntu for example, you are getting the choice of setting up encrypted LVM partitions, is the default key-size used here as well or is it set to a higher size ?

All help is appriciated.

2^128=340282366920938463463374607431768211456

Crawling through a 128 bit key space using all CPU power available today (and in the foreseeable future) would take billions of years.

So I must ask: What makes you say a 128 bit key "seems to be pretty weak"?

It really depends on what you are talking about, 128 bit aes is pretty secure, 128 bit WEP is not, 128 bit RSA is not. Going to 1024 bit aes would be complete overkill and unnecessarily waste cpu cycles and kill your throughput. Take a look at the wikipedia entry for aes, especially the security of aes section, the US government is allowing top secret documents to be secured with 192 bit aes.

http://en.wikipedia.org/wiki/Advance...ecurity_of_AES

win32sux: when you say "using all the cpu power available today", do you mean all the cpu power of all computers in the world or just one cpu ? trying to crack an encryption with one cpu would take as long as you said i guess.. but people that try to crack encryption never do it with one (at least i cant imagine that)

estabroo: thats interesting, i didnt know there were differences like that. i use rsa on the ssl certificate keys, so thats probably why 1024 bit is used (ive been told that 128 was way too weak when using rsa and that 768 had been cracked).

win32sux: when you say "using all the cpu power available today", do you mean all the cpu power of all computers in the world or just one cpu ? trying to crack an encryption with one cpu would take as long as you said i guess.. but people that try to crack encryption never do it with one (at least i cant imagine that)

estabroo: thats interesting, i didnt know there were differences like that. i use rsa on the ssl certificate keys, so thats probably why 1024 bit is used (ive been told that 128 was way too weak when using rsa and that 768 had been cracked).

Make sure you don't throw symmetric and asymmetric keys into the same bag. A 128 bit symmetric key is serious business. A 128 bit asymmetric key (such as RSA) isn't. That said, once you've got a decent key size you still need to make sure the algorithm is solid. This basically boils-down to peer review by expert cryptanalysts. The point being, don't base the quality of an encryption scheme solely on the key size. By using a 128 bit symmetric key, you've made it economically infeasible for anyone to brute force your key. That's great, but you'll still be vulnerable to other forms of attack if you choose an algorithm that sucks.

I mean the combined CPU power of every CPU in the known universe.

I have been playing around with this too, using dm_crypt with luks and although I have heard it is secure, I really don't if it is. I mean I dont persoannly have anyway to test it. So i guess I have to rely on the experst that say it is secure and just trust them.

However, does it add at all to the security if you would do say....create a file container which is encrypted with dm_crypt with luks, and then within this file contain, you would have yet another file container that is also encrypted? Basically having a encrypted partition within a encrypted partition. Would this greatly increase the security??