Cryptsetup Optimal Keyfile Size for a given Key Size

dm-crypt Dan Klopp 3 participants 3 messages May 19, 2010 – May 20, 2010

Share & tools

Dan Klopp

author

2010-05-19 19:16 UTC #0 lore raw

I wanted to generate a keyfile of the maximum size and no larger, as using a 512 bit keyfile on 256 bit encryption seems pointless. In so doing I seem to have encountered an error in the man page, and cannot answer my question from it or I have misunderstood the concept. My only question is, with a dm-luks key size fixed, at what point does a random keyfile of size X, offer no more protection than a random keyfile of size Y, when X > Y? Please read on for what I encountered and why the man page cannot seem to answer my question.

According to the man page 256 bits can be set as your key size (if it is good enough for classified material, it is good enough for me). Hence a keyfile larger than your key size would be pointless. Intriguingly, most online guides (including the official guide!) that generate a keyfile use the command dd if=/dev/random of=mykey bs=1 count=256 which is 256 bytes, not 256 bits. The correct command should be dd if=/dev/random of=mykey bs=1 count=32, am I right?

Naturally, I was curious what advantage 256 bytes versus 256 bits may entail. According to the man page, none:

From a key file: It will be cropped to the size given by -s. If
there
is insufficient key material in the key file, cryptsetup will
quit with
an error.

Fair enough, but curious, I tested this "cropping" by generating a 1024 byte key (way overkill) and adding it as a keyfile to a file container. I opened it to test it and it worked. Then I used the first half of the 1024 byte key to open it. I received an error message of an incorrect key. Therefore, it does not crop as I understand it, and it uses the entire key. But to what point? If you are only capable of 256 bit encryption, using a 4096 bit key seems...pointless?

My sample script is below for cryptsetup 1.0.3, Red Hat 5.5, 64 bit:

dd if=/dev/sda of=/dev/null &
dd if=/dev/random of=key-1024B bs=1 count=1024
kill pidof dd
dd if=/dev/zero of=cont.enc bs=4096 count=4096
losetup /dev/loop6 cont.enc || exit 1
cryptsetup luksFormat -s 256 -c aes-cbc-essiv:sha256 /dev/loop6 key-1024B cryptsetup --key-file ./key-1024B luksOpen /dev/loop6 test
# It works
cryptsetup luksClose /dev/mapper/test
dd if=key-1024B of=key-firsthalfof-1024B bs=1 count=512 cryptsetup --key-file ./key-firsthalfof-1024B luksOpen /dev/loop6 test # Invalid keyfile.
losetup -d /dev/loop6

Thank you for your time,
-Dan

Arno Wagner

2010-05-20 00:05 UTC #1 lore raw

I think the "keyfile" is really a passphrasefile and gets hashed. In that case you want some more bits in there to ensure maximum entropy.

Arno

Quoted 57 lines · Dan Klopp

I wanted to generate a keyfile of the maximum size and no larger, as using a 512 bit keyfile on 256 bit encryption seems pointless. In so doing I seem to have encountered an error in the man page, and cannot answer my question from it or I have misunderstood the concept. My only question is, with a dm-luks key size fixed, at what point does a random keyfile of size X, offer no more protection than a random keyfile of size Y, when X > Y? Please read on for what I encountered and why the man page cannot seem to answer my question.
According to the man page 256 bits can be set as your key size (if it is good enough for classified material, it is good enough for me). Hence a keyfile larger than your key size would be pointless. Intriguingly, most online guides (including the official guide!) that generate a keyfile use the command dd if=/dev/random of=mykey bs=1 count=256 which is 256 bytes, not 256 bits. The correct command should be dd if=/dev/random of=mykey bs=1 count=32, am I right?
Naturally, I was curious what advantage 256 bytes versus 256 bits may entail. According to the man page, none:
From a key file: It will be cropped to the size given by -s. If
there
is insufficient key material in the key file, cryptsetup will quit
with
an error.
Fair enough, but curious, I tested this "cropping" by generating a 1024 byte key (way overkill) and adding it as a keyfile to a file container. I opened it to test it and it worked. Then I used the first half of the 1024 byte key to open it. I received an error message of an incorrect key. Therefore, it does not crop as I understand it, and it uses the entire key. But to what point? If you are only capable of 256 bit encryption, using a 4096 bit key seems...pointless?
My sample script is below for cryptsetup 1.0.3, Red Hat 5.5, 64 bit:
dd if=/dev/sda of=/dev/null &
dd if=/dev/random of=key-1024B bs=1 count=1024
kill pidof dd
dd if=/dev/zero of=cont.enc bs=4096 count=4096
losetup /dev/loop6 cont.enc || exit 1
cryptsetup luksFormat -s 256 -c aes-cbc-essiv:sha256 /dev/loop6 key-1024B cryptsetup --key-file ./key-1024B luksOpen /dev/loop6 test
# It works
cryptsetup luksClose /dev/mapper/test
dd if=key-1024B of=key-firsthalfof-1024B bs=1 count=512 cryptsetup --key-file ./key-firsthalfof-1024B luksOpen /dev/loop6 test # Invalid keyfile.
losetup -d /dev/loop6
Thank you for your time,
-Dan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Signature · 7 lines

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Roscoe

2010-05-20 10:04 UTC #2 lore raw

A close inspection of the man page agrees:

'''
luksFormat <device> [<key file>]
initializes a LUKS partition and sets the initial key, either via prompting or via <key file>. <options> can be [--cipher, --verify-passphrase, --key-size, --key-slot]
...
--key-file, -d
use file as key material. With LUKS, key material supplied in key files via -d are always used for existing passphrases. If you want to set a new key via a key file, you have to use a positional arg to luksFormat or luksAddKey.
'''

Quoted 79 lines · Arno Wagner

I think the "keyfile" is really a passphrasefile and gets hashed. In that case you want some more bits in there to ensure maximum entropy.
Arno
Quoted 50 lines · Dan Klopp
I wanted to generate a keyfile of the maximum size and no larger, as using a 512 bit keyfile on 256 bit encryption seems pointless. In so doing I seem to have encountered an error in the man page, and cannot answer my question from it or I have misunderstood the concept. My only question is, with a dm-luks key size fixed, at what point does a random keyfile of size X, offer no more protection than a random keyfile of size Y, when X > Y? Please read on for what I encountered and why the man page cannot seem to answer my question.
According to the man page 256 bits can be set as your key size (if it is good enough for classified material, it is good enough for me). Hence a keyfile larger than your key size would be pointless. Intriguingly, most online guides (including the official guide!) that generate a keyfile use the command dd if=/dev/random of=mykey bs=1 count=256 which is 256 bytes, not 256 bits. The correct command should be dd if=/dev/random of=mykey bs=1 count=32, am I right?
Naturally, I was curious what advantage 256 bytes versus 256 bits may entail. According to the man page, none:
From a key file: It will be cropped to the size given by -s. If there
is insufficient key material in the key file, cryptsetup will quit with
an error.
Fair enough, but curious, I tested this "cropping" by generating a 1024 byte key (way overkill) and adding it as a keyfile to a file container. I opened it to test it and it worked. Then I used the first half of the 1024 byte key to open it. I received an error message of an incorrect key. Therefore, it does not crop as I understand it, and it uses the entire key. But to what point? If you are only capable of 256 bit encryption, using a 4096 bit key seems...pointless?
My sample script is below for cryptsetup 1.0.3, Red Hat 5.5, 64 bit:
dd if=/dev/sda of=/dev/null &
dd if=/dev/random of=key-1024B bs=1 count=1024
kill pidof dd
dd if=/dev/zero of=cont.enc bs=4096 count=4096
losetup /dev/loop6 cont.enc || exit 1
cryptsetup luksFormat -s 256 -c aes-cbc-essiv:sha256 /dev/loop6 key-1024B cryptsetup --key-file ./key-1024B luksOpen /dev/loop6 test
# It works
cryptsetup luksClose /dev/mapper/test
dd if=key-1024B of=key-firsthalfof-1024B bs=1 count=512 cryptsetup --key-file ./key-firsthalfof-1024B luksOpen /dev/loop6 test # Invalid keyfile.
losetup -d /dev/loop6
Quoted 7 lines
Thank you for your time,
-Dan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected]
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt