From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Cryptsetup FAQ is confusing re: key-file length and newlines
Date: Thu, 16 Jul 2020 17:08:59 +0200 [thread overview]
Message-ID: <20200716150859.GA6794@tansi.org> (raw)
In-Reply-To: <269697254.1965946.1594846149229@mail.yahoo.com>
Hi John,
On Wed, Jul 15, 2020 at 22:49:09 CEST, John Wiersba wrote:
> The FAQ as of today (2020/7/15) states
>
> Make sure no trailing newline (0x0a) is contained in the input key
> file, or the passphrase will not work because the whole file is used as
> input.
>
> But then a few lines later it suggests
>
> head -c 256 /dev/random > keyfile
>
> Obviously if /dev/random is used, it's possible that the keyfile will
> end with a trailing newline.
> I think you're trying to distinguish between
> 1. A file which contains a human-readable passphrase which could also
> be entered interactively, and
> 2. A file which contains random bytes.
You are overthinking this, I think.
If you create the keyfile via a text-editor, make sure you have no
trailing newling (unless you _want_ that traling newline to be part
of the passphrase). Many UNIX editors add that trailing newline
when saving a file automatically and then you have a character in
there you do not see but which is part of the passphrase.
This comment just simplifies debugging the problem.
If you create a new random keyfile, whatever bytes are in
there are fine. A random keyfile will contain (almost certainly ;-)
a lot of characters you cannot enter interactively anyways,
hence this does not have "interactive entry" as use-case.
[...]
> Additionally, I see lots of guidance on the length of a keyfile which
> uses magic numbers, both on the internet and also in the FAQ. Examples
> are the value 256 above, and the parameters bs=512 count=8 for dd. If
> I understand the FAQ correctly, the actual advice is
>
> Plain dm-crypt: Use > 80 bit. ... If paranoid, add at least 20 bit.
>
> This implies (taking the worst case) that
>
> head -c 13 /dev/random
>
> should be sufficient (13 * 8 bytes = 104 bits > 81+20 bits), and 256
> bytes is "overkill". I do understand that some reasonable amount of
> overkill is essentially "free" and therefore can be used "just in
> case".
Yes. When it costs you nothing, use more. When it costs you something,
what you quoted gives you a generally reasonable trade-off.
Regards,
Arno
> Did I understand these two concepts correctly, and if so, could you
> clarify the FAQ?
> Thanks!
> -- John Wiersba
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
prev parent reply other threads:[~2020-07-16 15:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <269697254.1965946.1594846149229.ref@mail.yahoo.com>
2020-07-15 20:49 ` [dm-crypt] Cryptsetup FAQ is confusing re: key-file length and newlines John Wiersba
2020-07-16 15:08 ` Arno Wagner [this message]
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=20200716150859.GA6794@tansi.org \
--to=arno@wagner.name \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).