dm-crypt.saout.de archive mirror
 help / color / mirror / Atom feed
From: Clemens Fruhwirth <clemens@endorphin.org>
To: Milan Broz <gmazyland@gmail.com>
Cc: Volker Dormeyer <vd@d7informatics.de>, dm-crypt@saout.de
Subject: [dm-crypt] Re: Reading the passphrase from a key-file
Date: Fri, 14 May 2021 20:10:12 +0200	[thread overview]
Message-ID: <CAG6gW_tYoxYhww-3fpwvrUX25cH=03GU8sC=u+74jqbxVNetTQ@mail.gmail.com> (raw)
In-Reply-To: <4079c1f2-13c3-ead1-d0ed-3b4e446aa5cb@gmail.com>

On Fri, 14 May 2021 at 17:51, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 14/05/2021 17:22, Clemens Fruhwirth wrote:
> > On Fri, 14 May 2021 at 15:44, Milan Broz <gmazyland@gmail.com> 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@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

  reply	other threads:[~2021-05-14 18:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 11:51 [dm-crypt] Reading the passphrase from a key-file Volker Dormeyer
2021-05-14 13:41 ` [dm-crypt] " Milan Broz
2021-05-14 13:53   ` Arno Wagner
2021-05-14 14:12   ` Christoph Anton Mitterer
2021-05-14 15:22   ` Clemens Fruhwirth
2021-05-14 15:50     ` Milan Broz
2021-05-14 18:10       ` Clemens Fruhwirth [this message]
2021-05-14 20:43         ` Milan Broz
2021-05-15  7:08           ` Clemens Fruhwirth

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='CAG6gW_tYoxYhww-3fpwvrUX25cH=03GU8sC=u+74jqbxVNetTQ@mail.gmail.com' \
    --to=clemens@endorphin.org \
    --cc=dm-crypt@saout.de \
    --cc=gmazyland@gmail.com \
    --cc=vd@d7informatics.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;
as well as URLs for NNTP newsgroup(s).