public inbox for cryptsetup@lists.linux.dev
 help / color / mirror / Atom feed
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

  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