From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 19 May 2010 21:16:51 +0200 (CEST) Received: from [10.2.101.173] (turing.cv.nrao.edu [10.2.101.173]) by cv3.cv.nrao.edu (8.13.8/8.13.8/cv-ws-8.12) with ESMTP id o4JJGe9w008285 for ; Wed, 19 May 2010 15:16:40 -0400 Message-ID: <4BF43918.6060203@nrao.edu> Date: Wed, 19 May 2010 15:16:40 -0400 From: Dan Klopp MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dm-crypt] Cryptsetup Optimal Keyfile Size for a given Key Size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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