Re: Reading the passphrase from a key-file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 14 May 2021 at 17:51, Milan Broz <gmazyland@xxxxxxxxx> wrote:
>
> On 14/05/2021 17:22, Clemens Fruhwirth wrote:
> > On Fri, 14 May 2021 at 15:44, Milan Broz <gmazyland@xxxxxxxxx> wrote:
>
> >>       From key file: The complete keyfile is read up to the compiled-in maximum size. Newline characters do not terminate the  input.  The  --keyfile-size
> >>       option can be used to limit what is read.
>
> > Did I chose this "up to the compiled-in maximum size" either
> > explicitly or implicitly back in the days? Checking get_key inside
> > lib/utils.c in the ancient release 1.0.6 from some time in 2007 looks
> > as if there was no such limit.
>
> Hard limit was patch that I added later (in 1.3.0) - and the default is 8MB for keyfiles.
>
> If you use /dev/urandom or something like that, it eats all your memory after some time and crashes.

I am not sure why anyone would ever read keys from /dev/urandom. Maybe
to create throw away encrypted swap partition, but supplying
--key-size should resolve this. In the LUKS case, I think that
/dev/urandom never makes sense as key material. I don't have strong
opinions on whether a tool should protect you against OOMs when you
give it an infinitely large file to read. Probably not.

> Also, with PBKDF2 there is nasty property, that you can hash input in advance,
> and the output is the same - so super-large keyfiles do not make much sense.
> (With Argon2 it is no longer the case.)

I think that precomputability is a desired property of an HMAC, and as
PBKDF2 uses it as a building block, we kind of inherit that.
Interestingly, with HMAC-SHAS1 we could support keys larger than our
memory, as with HMAC-SHA1(K,m) we don't need to ever keep K in memory
in full.[1] But that's really not a worthwhile goal to begin with.
Argon2 is certainly the better choice.

But I don't think that you can produce output that is "the same"
regardless of key size with PBKDF2 -- at least in theory -- as the
derived key is a concatenation of xor-ed PRF outputs. If you disagree,
maybe you want to elaborate on that :).

Best regards,
Clemens

[1] For HMAC-SHA1(K,m) = SHA1_outer((K ^ opad) || (SHA1_inner(K ^
ipad) || m)), we can iteratively compute SHA1_outer/SHA1_inner and
immediately discard K.
_______________________________________________
dm-crypt mailing list -- dm-crypt@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux