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

[Chris X Edwards <chris@xed.ch>]

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>