[dm-crypt] --key-file size...
ms at citd.de
Fri Jan 25 00:28:49 CET 2013
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?
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
More information about the dm-crypt