Re: [dm-crypt] --key-file size...

[Matthias Schniedermeyer <ms@citd.de>]

On 24.01.2013 17:36, Andrea wrote:
> On Thu, Jan 24, 2013 at 04:42:51PM +0100, Arno Wagner wrote:
> 
> Hi Arno,
>    and thanks a lot for your quick reply.
> 
> > So nothing wrong.
> 
> Yep. Is there a way for me to have a big key? Using LUKS? LoopaesOpen?

If you want the biggest key, AFAIK that would be loopaes in AES256-mode.
That uses 64 different 256bit keys and a 65th to encrypt the IVs.

A slight drawback is that it is slower, but with a CPU that has AES-NI i 
benchmarked about 400MB/s, which is fast enough for me.

> Does it worth it?

It depends.

A big key isn't everything. The best encryption is worthless when the 
key-management is flawed or the wrong attack-model is assumed, like 
assuming there aren't inside-attackers. Protecting against an attacker 
that has legitimate access to a system is not easy.

As for key-management. You have to store the key somewhere and maybe 
encrypt is someway. Commonly you encrypt the key with gpg, so you have a 
key-file that contains 65 keys with an entrophy of at least 256 bits per 
key (one key per line), that is then encrypted with a single key. So 
optimally you have used 1/65th of the entrophy used for encrypting the 
data to encrypt the encryption key. But as brutce-forcing even a single 
AES256 key is to the best of my knowledge impossible in practice you 
have to ask yourself if you really need 65 times impossible if one time 
impossible is all you really need.

Then you have to decrypted the keyfile for a moment to set up the 
encryption. If an attacker can get inbetween this process the whole 
excercise was for naught.

And there is this latent futilty of encryption, the cold-boot attack 
problem. If an attacker can get physical access to the system while the 
encrypted filesystem is mounted, an attacker can extract the encryption 
keys directly from the RAM of the machine in several different ways 
depending on circumstance. Firewire and/or Thunderbolt makes this real 
easy, you just dump the RAM of the running machine by connecting a 
second computer. So a computer handling sensitive data shouldn't have 
either and restricting physical access to the machine is suggest too, so 
that nobody can for e.g. attach a keylogger or plug in a Firewire card.

The same problem is if an attacker can get remote-access to the computer 
and can escalate his/her privileges to root, then an attacker can 
determine the encryption key or just copy the data. Same goes for the 
"inside attacker" that can either escalate to root or has 
root-privileges to begin with.

So called offline-security (a.k.a "data at rest") is easy. A properly 
encrypted HDD laying deattached on a shelf is perfectly secure. Even if 
stolen there is pratically no risk of anybody beeing able to decrypt the 
HDD, if the thief can't get access to all material needed for 
decryption. In the loop-aes model you have 2 or 3 parts, the keyfile 
itself and usually the passphrase to protect the keyfile or the private 
key to the public-key that was used to encrypt the keyfile with in turn 
should have a password. An attacker needs all 2 (keyfile/password) or 3 
parts (keyfile/private key/password)s for a successfull decryption.

The problem starts when you want to work, online-security is hard. 
Really hard depending on the attack-model you have or want to protect 
yourself against.





-- 

Matthias