All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris X Edwards <chris@xed.ch>
To: cryptsetup@lists.linux.dev
Subject: Can AddKey not use stdin for the new key?
Date: Thu, 24 Aug 2023 05:51:09 -0400	[thread overview]
Message-ID: <ZOcoDVa4p+vJfAm9@xed.ch> (raw)

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>

             reply	other threads:[~2023-08-24  9:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-24  9:51 Chris X Edwards [this message]
2023-08-24 10:51 ` Can AddKey not use stdin for the new key? 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

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=ZOcoDVa4p+vJfAm9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.