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

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

[Andrea]

Hi all,
   and thanks a lot for your work.
   I'm a happy user of cryptsetup.
   I need to store hospital data, and I would like to use a big key
   file.
   Well, I checked for compile limits (Ubuntu 12.10)
   $ cryptsetup --help|grep -i maximum
     Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)

   Anyway, if I check with the simple script under, it seems cryptsetup ignore
   everything where $size > 32.

   What I am doing wrong?

Thanks a lot for your time,
A.

------------

#!/bin/bash

fdloopback="/tmp/loopback.dd"
fdkey="/tmp/key_master"
fdkeytmp="/tmp/key"
cryptname="keytest"

dd if=/dev/zero of=$fdloopback bs=1G count=0 seek=1
nettle-lfib-stream | dd of=$fdkey bs=1K count=8192 iflag=fullblock

losetup /dev/loop0 $fdloopback
  cryptsetup create $cryptname /dev/loop0 --key-file $fdkey
    mkfs.ext4 -q /dev/mapper/$cryptname -F
    sync
  cryptsetup remove $cryptname
losetup -d /dev/loop0

for size in $(seq 2 2 8192)
do
  dd if=$fdkey of=$fdkeytmp bs=1 count=$size
  losetup /dev/loop0 $fdloopback
    cryptsetup create $cryptname /dev/loop0 --key-file $fdkeytmp
      fsck /dev/mapper/$cryptname && echo "------> Good, " $size || echo "------> Bad, " $size
      sync
    cryptsetup remove $cryptname
  losetup -d /dev/loop0
  echo "Enter to go on";read trash
done

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

[Arno Wagner]

You are using plain dm-crypt (you really should use LUKS).
The man-page says this for key-files for plain mode:

 "From a key file: It will be truncated to the key size of the used
  cipher or the size given by -s and directly used as binary key. If
  the key file is shorter than the key, cryptsetup will quit with an 
  error."

So nothing wrong.

Arno


On Thu, Jan 24, 2013 at 01:34:42PM +0000, Andrea wrote:
> Hi all,
>    and thanks a lot for your work.
>    I'm a happy user of cryptsetup.
>    I need to store hospital data, and I would like to use a big key
>    file.
>    Well, I checked for compile limits (Ubuntu 12.10)
>    $ cryptsetup --help|grep -i maximum
>      Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
> 
>    Anyway, if I check with the simple script under, it seems cryptsetup ignore
>    everything where $size > 32.
> 
>    What I am doing wrong?
> 
> Thanks a lot for your time,
> A.
> 
> ------------
> 
> #!/bin/bash
> 
> fdloopback="/tmp/loopback.dd"
> fdkey="/tmp/key_master"
> fdkeytmp="/tmp/key"
> cryptname="keytest"
> 
> dd if=/dev/zero of=$fdloopback bs=1G count=0 seek=1
> nettle-lfib-stream | dd of=$fdkey bs=1K count=8192 iflag=fullblock
> 
> losetup /dev/loop0 $fdloopback
>   cryptsetup create $cryptname /dev/loop0 --key-file $fdkey
>     mkfs.ext4 -q /dev/mapper/$cryptname -F
>     sync
>   cryptsetup remove $cryptname
> losetup -d /dev/loop0
> 
> for size in $(seq 2 2 8192)
> do
>   dd if=$fdkey of=$fdkeytmp bs=1 count=$size
>   losetup /dev/loop0 $fdloopback
>     cryptsetup create $cryptname /dev/loop0 --key-file $fdkeytmp
>       fsck /dev/mapper/$cryptname && echo "------> Good, " $size || echo "------> Bad, " $size
>       sync
>     cryptsetup remove $cryptname
>   losetup -d /dev/loop0
>   echo "Enter to go on";read trash
> done
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

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

[Andrea]

On Thu, Jan 24, 2013 at 04:42:51PM +0100, Arno Wagner wrote:

Hi Arno,
   and thanks a lot for your quick reply.

> You are using plain dm-crypt (you really should use LUKS).

I really like the "stealth" mode of plain. With LUKS header they can see
there's encrypted stuff. Anyway, maybe I should just set an offset.

> So nothing wrong.

Yep. Is there a way for me to have a big key? Using LUKS? LoopaesOpen?
Does it worth it?
I mean, I am a little bit paranoid about leaking our patient info (they
are about AIDS and so on).

Thanks a lot for your time,
A.

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

[Matthias Schniedermeyer]

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

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

[Arno Wagner]

On Thu, Jan 24, 2013 at 05:36:24PM +0000, 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.
> 
> > You are using plain dm-crypt (you really should use LUKS).
> 
> I really like the "stealth" mode of plain. With LUKS header they can see
> there's encrypted stuff. 

The only stealthy thing between "plain" and LUKS is that with
LUKS there is an ambiguity between encrypted and "secure 
wiped", but that is all. 

> Anyway, maybe I should just set an offset.
> 
> > So nothing wrong.
> 
> Yep. Is there a way for me to have a big key? Using LUKS? LoopaesOpen?
> Does it worth it?

No. A good passphrase is enough. 

> I mean, I am a little bit paranoid about leaking our patient info (they
> are about AIDS and so on).

Go LUKS. More secure anyways. And you can have a recovery-passphrase 
in a sealed envelope in your safe. 

> Thanks a lot for your time,
> A.

No problem.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell