public inbox for dm-crypt@saout.de
 help / color / mirror / Atom feed
From: Felix Rubio <felix@kngnt.org>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] length of keyfiles
Date: Wed, 06 Jan 2021 12:17:30 +0100	[thread overview]
Message-ID: <4eecfe4743d91d6cc565a276776d1020@kngnt.org> (raw)
In-Reply-To: <3674619b2202e99b31fac7043e6edba5@kngnt.org>

Follow up question: right now I am generating the 4 kB keyfile using 
openssl rand 4096. Should the quality of the key, then, be the same if 
doing dd if=/dev/random bs=64 count=1?

Thank you!
Felix

On 2021-01-06 12:08, Felix Rubio wrote:
> Thank you for your answer Arno... and for confirming that I should
> finally get rid of those double density floppy disks and reader :-P
> 
> Regards!
> Felix
> 
> On 2021-01-06 11:47, Arno Wagner wrote:
>> Hi Felix,
>> 
>> I assume we are talking LUKS here, plain mode is different.
>> 
>> The longer length is both convenience and helps if you
>> use low-entropy input. The keyfile does not actually
>> hold a key (LUKS mode), but a passphrase. Passphrases
>> get hashed, and once you have maximum entropy, you
>> cannot get more. I would need to look up what length
>> is actually used, but it does not depend on the lenght
>> of the encryption key. That one is stored in the anti-forensic
>> stripes, protected with the hash from that passphrase.
>> 
>> So, to make this short, if you use LUKS with a keyfile,
>> putting in more entropy than used is meaningless.
>> If your random data is from /dev/random or (properly
>> initialized) /dev/urandom, 64 bytes are more than enough.
>> 
>> Also, the differences between an 8kB passphrase and a
>> 64B one in execution time should not be noticeable at all.
>> Unless you read it from floppy disk ;-)
>> 
>> Regards,
>> Arno
>> 
>> 
>> On Wed, Jan 06, 2021 at 10:17:22 CET, Felix Rubio wrote:
>>> Hi everybody,
>>> 
>>> I have seen that keyfiles can be used in cryptsetup up to 8 kB, but
>>> internally the master key is 512 bits at max.  Is there any 
>>> recommendation
>>> / increased security by using a random sequence of 8 kB w.r.t., let's 
>>> say,
>>> one of just 64 bytes?
>>> 
>>> I understand that using one of 8kB will require more time than one of 
>>> 64 B
>>> when unlocking the volume, but...  is the former really that much 
>>> more
>>> secure than the latter?
>>> 
>>> Regards!
>>> Felix
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> https://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

  reply	other threads:[~2021-01-06 11:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  9:17 [dm-crypt] length of keyfiles Felix Rubio
2021-01-06 10:47 ` Arno Wagner
2021-01-06 11:08   ` Felix Rubio
2021-01-06 11:17     ` Felix Rubio [this message]
2021-01-06 14:06       ` Arno Wagner

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=4eecfe4743d91d6cc565a276776d1020@kngnt.org \
    --to=felix@kngnt.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox