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 21:16:16 +0200	[thread overview]
Message-ID: <20230824191615.GA904@tansi.org> (raw)
In-Reply-To: <ZOd9KJ6uLqlZFoLi@xed.ch>

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

  reply	other threads:[~2023-08-24 19:16 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 [this message]
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=20230824191615.GA904@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