public inbox for cryptsetup@lists.linux.dev
 help / color / mirror / Atom feed
From: Chris X Edwards <chris@xed.ch>
To: cryptsetup@lists.linux.dev
Subject: Re: Can AddKey not use stdin for the new key?
Date: Thu, 24 Aug 2023 14:35:30 -0400	[thread overview]
Message-ID: <ZOei8rjDNiJwnHbr@xed.ch> (raw)
In-Reply-To: <f28150bc-89d0-4998-95b4-a4509d3a0624@home.arpa>

Hi,
These are two very interesting suggestions! I think you're right that
decrypting a volume that contains the secrets is a pretty rational
approach. The Bash process redirect looks fun but I couldn't get it to
work and it would be pretty extraordinary if the options parsing
handled that well.

Another approach I thought might work is to set up the second slot
with luksAddKey and just put in a nonce passphrase normally; then
immediately try a luksChangeKey to swap it for a file. 

The cryptsetup-luksChangeKey 8 man page (under -d option) says:

  If you want to set a new passphrase via key file, you have to use a
  positional argument or parameter --new-keyfile.

And that would be exactly what would be required. Unfortunately, I
think this might be a man page error since that option produces:

    cryptsetup: Option --new-keyfile is not allowed with luksChangeKey action

It definitely seems like all the options are kind of in place to do
this (especially `--new-keyfile=-` in luksAddKey) but they're just not
quite doing what I'd hope. Not a big deal. Just thought I'd run it by
this list and see if anyone could spot an obvious error in my
thinking. 

Thanks for all the suggestions!
Cheers,
Chris

On 2023-08-24 17:27 +0000, Michael Kj??rling wrote:
> On 24 Aug 2023 05:51 -0400, from chris@xed.ch (Chris X Edwards):
> > I create an encrypted secret that I only have to unlock once:
> > 
> If you are willing to unlock once, you can also use a small LUKS
> container to hold a file system holding passphrase or key files for
> other LUKS containers. Or you can derive further keys from contents or
> metadata of another LUKS container; I've seen suggestions for how to
> do this scattered about the Web.
> 
> 
> > 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
> 
> Assuming bash, you might want to try:
> 
>     cryptsetup luksOpen --key-file=<(gpg --decrypt drivekey.gpg) /dev/sdb backup
> 
> and corresponding variations of your other commands as well.

-- 
++++++++++[>++++++++++++<-]>-...<++++++[>>+++++++<<-]>>++++.<+.<++++[>
Chris X Edwards-----<-]>+.- Have a nice day. >.<-.+++++><chris@xed.ch>

      reply	other threads:[~2023-08-24 18:35 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
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 [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=ZOei8rjDNiJwnHbr@xed.ch \
    --to=chris@xed.ch \
    --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