All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Klopp <dklopp@nrao.edu>
To: dm-crypt@saout.de
Subject: [dm-crypt] Cryptsetup Optimal Keyfile Size for a given Key Size
Date: Wed, 19 May 2010 15:16:40 -0400	[thread overview]
Message-ID: <4BF43918.6060203@nrao.edu> (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

             reply	other threads:[~2010-05-19 19:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 19:16 Dan Klopp [this message]
2010-05-20  0:05 ` [dm-crypt] Cryptsetup Optimal Keyfile Size for a given Key Size Arno Wagner
2010-05-20 10:04   ` Roscoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF43918.6060203@nrao.edu \
    --to=dklopp@nrao.edu \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.