Can AddKey not use stdin for the new key?

Can AddKey not use stdin for the new key?

[Chris X Edwards]

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>

Re: Can AddKey not use stdin for the new key?

[Arno Wagner]

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

Re: Can AddKey not use stdin for the new key?

[Chris X Edwards]

Hi,
Thanks for the reply. I did see this in the man page. Am I right to
assume this suggestion doesn't relate to the "how much time" aspect of
this passage? This leaves the much more treacherous formatting details
between the input modes. Certainly a cause for concern. The reason I
concluded this was an unlikely cause is that the Remove works as I
would imagine (with a piped key) and the Add does not. 

Another check is to go with a very simple passphrase key that can not
possibly have newline entanglements. (That's the goal, correct me if I'm
wrong.) We can start with a very simple key file.

    echo "simple" > simplekey

Let's try just the file.

    cryptsetup luksAddKey /dev/sdb --new-keyfile simplekey --new-key-slot 1
    Enter any existing passphrase: 

Works fine. (Passphrase to add is for existing slot 0 as desired.) Now
removing it.

    cat simplekey | cryptsetup luksRemoveKey /dev/sdb -

Works fine. Now try adding again but with piping instead of the file.

    cat simplekey | cryptsetup luksAddKey /dev/sdb --new-keyfile - --new-key-slot 1
    No key available with this passphrase.

And fail.

This may be a basic limitation of what is possible, but I'm just
trying to establish that fact clearly so I can give up on my dream of
using cryptsetup in the elegant way I imagine it can be used. :-)

Thanks,
Chris

On 2023-08-24 12:51 +0200, Arno Wagner wrote:
> the convengtion for reading passphrases from file and from stdin
> are different. 
> 
> Very likely your passphrase runs into these differences.
>
> 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>

Re: Can AddKey not use stdin for the new key?

[Arno Wagner]

Make that "echo -n" and try again ;-)

Arno


On Thu, Aug 24, 2023 at 17:06:33 CEST, Chris X Edwards wrote:
> Hi,
> Thanks for the reply. I did see this in the man page. Am I right to
> assume this suggestion doesn't relate to the "how much time" aspect of
> this passage? This leaves the much more treacherous formatting details
> between the input modes. Certainly a cause for concern. The reason I
> concluded this was an unlikely cause is that the Remove works as I
> would imagine (with a piped key) and the Add does not. 
> 
> Another check is to go with a very simple passphrase key that can not
> possibly have newline entanglements. (That's the goal, correct me if I'm
> wrong.) We can start with a very simple key file.
> 
>     echo "simple" > simplekey
> 
> Let's try just the file.
> 
>     cryptsetup luksAddKey /dev/sdb --new-keyfile simplekey --new-key-slot 1
>     Enter any existing passphrase: 
> 
> Works fine. (Passphrase to add is for existing slot 0 as desired.) Now
> removing it.
> 
>     cat simplekey | cryptsetup luksRemoveKey /dev/sdb -
> 
> Works fine. Now try adding again but with piping instead of the file.
> 
>     cat simplekey | cryptsetup luksAddKey /dev/sdb --new-keyfile - --new-key-slot 1
>     No key available with this passphrase.
> 
> And fail.
> 
> This may be a basic limitation of what is possible, but I'm just
> trying to establish that fact clearly so I can give up on my dream of
> using cryptsetup in the elegant way I imagine it can be used. :-)
> 
> Thanks,
> Chris
> 
> On 2023-08-24 12:51 +0200, Arno Wagner wrote:
> > the convengtion for reading passphrases from file and from stdin
> > are different. 
> > 
> > Very likely your passphrase runs into these differences.
> >
> > 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

Re: Can AddKey not use stdin for the new key?

[Chris X Edwards]

That is a sensible addition. I would have assumed that rather than
have some possibly randomly occurring newline (or whatever the problem
is) the straight echo would at least put the newline in a safe
(ignorable) place in my previous example. However, even using `-n` I
get the same situation.

    $ echo -n "simple" > simplekey
    $ cat simplekey |  cryptsetup luksAddKey /dev/sdb --new-keyfile - --new-key-slot 1
    No key available with this passphrase.

That's definitely a smart thing to try to rule out newline mischief
but the error message makes me think that it's just looking for the
authorizing passphrase using the new key I'm trying to add (which is
different behavior than when I actually specify a file). That may be
the case, but I'm not sure.

Thanks,
Chris


On 2023-08-24 17:23 +0200, Arno Wagner wrote:
> Make that "echo -n" and try again ;-)
> 
> Arno
> 
> 
> On Thu, Aug 24, 2023 at 17:06:33 CEST, Chris X Edwards wrote:
> > Hi,
> > Thanks for the reply. I did see this in the man page. Am I right to
> > assume this suggestion doesn't relate to the "how much time" aspect of
> > this passage? This leaves the much more treacherous formatting details
> > between the input modes. Certainly a cause for concern. The reason I
> > concluded this was an unlikely cause is that the Remove works as I
> > would imagine (with a piped key) and the Add does not. 
> > 
> > Another check is to go with a very simple passphrase key that can not
> > possibly have newline entanglements. (That's the goal, correct me if I'm
> > wrong.) We can start with a very simple key file.
> > 
> >     echo "simple" > simplekey
> > 
> > Let's try just the file.
> > 
> >     cryptsetup luksAddKey /dev/sdb --new-keyfile simplekey --new-key-slot 1
> >     Enter any existing passphrase: 
> > 
> > Works fine. (Passphrase to add is for existing slot 0 as desired.) Now
> > removing it.
> > 
> >     cat simplekey | cryptsetup luksRemoveKey /dev/sdb -
> > 
> > Works fine. Now try adding again but with piping instead of the file.
> > 
> >     cat simplekey | cryptsetup luksAddKey /dev/sdb --new-keyfile - --new-key-slot 1
> >     No key available with this passphrase.
> > 
> > And fail.
> > 
> > This may be a basic limitation of what is possible, but I'm just
> > trying to establish that fact clearly so I can give up on my dream of
> > using cryptsetup in the elegant way I imagine it can be used. :-)
> > 
> > Thanks,
> > Chris

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

Re: Can AddKey not use stdin for the new key?

[Arno Wagner]

Ah, luksAddKey has two key arguments and you can only read
one from stdin. Somwetimes the most obvious mistakes are
hard to spot ;-)

You need: 
1. The existing passprase from --key-file or interactively
2. The new passprase from positional argument or interactively

That is why you can delete. Deletion has only the passphrase 
as input.

Hence you need one passprase from file, no matter
what, you can only have one from stdin. Workarounds, I 
can think of

1. Use a ramdisk to temporarily store the key and then wipe it
2. Use an encrypted volume to hold the existing pasprase(s) as
   described by Michael. Can be luks in a file via losetup.
3. Use libcryptsetup and write your own code.

Regards,
Arno


On Thu, Aug 24, 2023 at 17:54:16 CEST, Chris X Edwards wrote:
> That is a sensible addition. I would have assumed that rather than
> have some possibly randomly occurring newline (or whatever the problem
> is) the straight echo would at least put the newline in a safe
> (ignorable) place in my previous example. However, even using `-n` I
> get the same situation.
> 
>     $ echo -n "simple" > simplekey
>     $ cat simplekey |  cryptsetup luksAddKey /dev/sdb --new-keyfile - --new-key-slot 1
>     No key available with this passphrase.
> 
> That's definitely a smart thing to try to rule out newline mischief
> but the error message makes me think that it's just looking for the
> authorizing passphrase using the new key I'm trying to add (which is
> different behavior than when I actually specify a file). That may be
> the case, but I'm not sure.
> 
> Thanks,
> Chris
> 
> 
> On 2023-08-24 17:23 +0200, Arno Wagner wrote:
> > Make that "echo -n" and try again ;-)
> > 
> > Arno
> > 
> > 
> > On Thu, Aug 24, 2023 at 17:06:33 CEST, Chris X Edwards wrote:
> > > Hi,
> > > Thanks for the reply. I did see this in the man page. Am I right to
> > > assume this suggestion doesn't relate to the "how much time" aspect of
> > > this passage? This leaves the much more treacherous formatting details
> > > between the input modes. Certainly a cause for concern. The reason I
> > > concluded this was an unlikely cause is that the Remove works as I
> > > would imagine (with a piped key) and the Add does not. 
> > > 
> > > Another check is to go with a very simple passphrase key that can not
> > > possibly have newline entanglements. (That's the goal, correct me if I'm
> > > wrong.) We can start with a very simple key file.
> > > 
> > >     echo "simple" > simplekey
> > > 
> > > Let's try just the file.
> > > 
> > >     cryptsetup luksAddKey /dev/sdb --new-keyfile simplekey --new-key-slot 1
> > >     Enter any existing passphrase: 
> > > 
> > > Works fine. (Passphrase to add is for existing slot 0 as desired.) Now
> > > removing it.
> > > 
> > >     cat simplekey | cryptsetup luksRemoveKey /dev/sdb -
> > > 
> > > Works fine. Now try adding again but with piping instead of the file.
> > > 
> > >     cat simplekey | cryptsetup luksAddKey /dev/sdb --new-keyfile - --new-key-slot 1
> > >     No key available with this passphrase.
> > > 
> > > And fail.
> > > 
> > > This may be a basic limitation of what is possible, but I'm just
> > > trying to establish that fact clearly so I can give up on my dream of
> > > using cryptsetup in the elegant way I imagine it can be used. :-)
> > > 
> > > Thanks,
> > > Chris
> 
> -- 
> ++++++++++[>++++++++++++<-]>-...<++++++[>>+++++++<<-]>>++++.<+.<++++[>
> 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

Re: Can AddKey not use stdin for the new key?

[Milan Broz]

On 8/24/23 21:16, Arno Wagner wrote:
> Ah, luksAddKey has two key arguments and you can only read
> one from stdin. Somwetimes the most obvious mistakes are
> hard to spot ;-)
> 
> You need:
> 1. The existing passprase from --key-file or interactively
> 2. The new passprase from positional argument or interactively

Yes, the terminal input is tricky because it support
all compatible option since cryptsetup 1.x :)
(If you check tests in sourcecode, you will see various tricky options
we run in CI.)

For the second item there is also --new-keyfile option.

Initially, I thought you just need

cryptsetup luksAddKey <dev> --key-file /key [-q]

- that will ask for the new passphrase only.

You can also send both passphrases from pipe
(but note, this cannot be done for binary input as it rely on
processing \n - do not use "-" as keyfile spec as it switch
to binary processing!):

echo -e "$PWD1\n$PWD2" | cryptsetup luksAddKey <dev>

For LUKS2 you can also add token that will try to read it
from kernel keyring.

Milan

Re: Can AddKey not use stdin for the new key?

[Michael Kjörling]

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:
> 
>     dd if=/dev/urandom bs=512 count=1 | gpg --symmetric --output drivekey.gpg

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.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Can AddKey not use stdin for the new key?

[Chris X Edwards]

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>