From: Arno Wagner <wagner@arnowagner.info>
To: cryptsetup@lists.linux.dev
Subject: Re: Can AddKey not use stdin for the new key?
Date: Thu, 24 Aug 2023 12:51:55 +0200 [thread overview]
Message-ID: <20230824105155.GA24581@tansi.org> (raw)
In-Reply-To: <ZOcoDVa4p+vJfAm9@xed.ch>
Hi Chris,
the convengtion for reading passphrases from file and from stdin
are different.
Very likely your passphrase runs into these differences.
Regards,
Arno
---
From "man cryptsetup":
NOTES ON PASSPHRASE PROCESSING FOR LUKS
LUKS uses PBKDF2 to protect against dictionary attacks and to give some
protection to low-entropy passphrases (see RFC 2898 and the cryptsetup
FAQ).
From a terminal: The passphrase is read until the first newline and
then processed by PBKDF2 without the newline character.
From stdin: LUKS will read passphrases from stdin up to the first new‐
line character or the compiled-in maximum key file length. If --key‐
file-size is given, it is ignored.
From key file: The complete keyfile is read up to the compiled-in maxi‐
mum size. Newline characters do not terminate the input. The --key‐
file-size option can be used to limit what is read.
Passphrase processing: Whenever a passphrase is added to a LUKS header
(luksAddKey, luksFormat), the user may specify how much the time the
passphrase processing should consume. The time is used to determine the
iteration count for PBKDF2 and higher times will offer better protec‐
tion for low-entropy passphrases, but open will take longer to com‐
plete. For passphrases that have entropy higher than the used key
length, higher iteration times will not increase security.
The default setting of one second is sufficient for most practical
cases. The only exception is a low-entropy passphrase used on a device
with a slow CPU, as this will result in a low iteration count. On a
slow device it may be advisable to increase the iteration time using
the --iter-time option in order to obtain a higher iteration count.
This does slow down all later luksOpen operations accordingly.
On Thu, Aug 24, 2023 at 11:51:09 CEST, Chris X Edwards wrote:
> Hi,
>
> I'm looking for some clarification into why what I'm attempting does
> not work.
>
> What I'd like to do is have a large number of (e.g. regular backup)
> drives all encrypted with the same key; I don't want to type a
> password every time I connect one so it would be great if I could have
> some kind of SSH-like agent. I believe GPG has such a thing. So...
>
> I create an encrypted secret that I only have to unlock once:
>
> dd if=/dev/urandom bs=512 count=1 | gpg --symmetric --output drivekey.gpg
>
> Now I'd like to add that to a LUKS keyslot so that the following
> works.
>
> gpg --decrypt drivekey.gpg | cryptsetup luksOpen --key-file=- /dev/sdb backup
>
> When I add the key like this, it (this luksAddKey command and the
> previous luksOpen) does all work.
>
> gpg --decrypt drivekey.gpg > INSECUREdrivekey
> cryptsetup luksAddKey /dev/sdb --new-keyfile INSECUREdrivekey --new-key-slot 1
> rm INSECUREdrivekey
>
> This asks for a passphrase for one of the existing slots as I'd
> expect. However, I'd like to avoid that insecure part with something
> like this.
>
> gpg --decrypt drivekey.gpg | cryptsetup luksAddKey /dev/sdb --new-keyfile - --new-key-slot 1
>
> This does not work. I was hoping it would still ask for a passphrase
> of an existing slot. But it just complains of "No key available with
> this passphrase."
>
> What's also interesting is that _removing_ the key works exactly how I
> think it should.
>
> gpg --decrypt drivekey.gpg | cryptsetup luksRemoveKey /dev/sdb -
>
> Am I misunderstanding the syntax? Is there a way to have the
> `luksAddKey` command accept the new key on stdin while verifying that
> it can be added by typing a passphrase? Maybe manual passphrase and
> stdin mixing is too confusing. Obviously I can work around it but I'm
> now curious.
>
> Thanks!
>
> --
> ++++++++++[>++++++++++++<-]>-...<++++++[>>+++++++<<-]>>++++.<+.<++++[>
> Chris X Edwards-----<-]>+.- Have a nice day. >.<-.+++++><chris@xed.ch>
--
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
next prev parent reply other threads:[~2023-08-24 10:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 9:51 Can AddKey not use stdin for the new key? Chris X Edwards
2023-08-24 10:51 ` Arno Wagner [this message]
2023-08-24 15:06 ` Chris X Edwards
2023-08-24 15:23 ` Arno Wagner
2023-08-24 15:54 ` Chris X Edwards
2023-08-24 19:16 ` Arno Wagner
2023-08-25 7:51 ` Milan Broz
2023-08-24 17:27 ` Michael Kjörling
2023-08-24 18:35 ` Chris X Edwards
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=20230824105155.GA24581@tansi.org \
--to=wagner@arnowagner.info \
--cc=arno@wagner.name \
--cc=cryptsetup@lists.linux.dev \
/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