Password hash as LUKS key

Password hash as LUKS key

[Martin Olsson]

Hey,

I want to encrypt drives for users. I want to avoid having their password sent to me in clear text. 
I was thinking of having them use a tool like mkpasswd to create a password hash and then 
pipe the generated hash into cryptsetup luksAddKey.

Unfortunately that didn't work when I tried it. 

So I guess it's not supported right? Maybe you know some other way to achieve what I want to accomplish?

BR,
Martin

Re: Password hash as LUKS key

[Arno Wagner]

You probably have an issue with line endings. In priciple,
this works and is supported, but interactive, pipe and 
read-from-file are all a bit different.

The man-page has more info on this. Best try it out with a
really simple password like "test".

Regards,
Arno


On Thu, Mar 09, 2023 at 15:35:28 CET, Martin Olsson wrote:
> Hey,
> 
> I want to encrypt drives for users. I want to avoid having their password sent to me in clear text. 
> I was thinking of having them use a tool like mkpasswd to create a password hash and then 
> pipe the generated hash into cryptsetup luksAddKey.
> 
> Unfortunately that didn't work when I tried it. 
> 
> So I guess it's not supported right? Maybe you know some other way to achieve what I want to accomplish?
> 
> BR,
> Martin

-- 
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: Password hash as LUKS key

[Martin Olsson]

 On Fri 10, Mar 10, 2023 at 02:19:54 CET, Arno Wagner <arno@wagner.name> wrote: 

>You probably have an issue with line endings. In priciple,
>this works and is supported, but interactive, pipe and 
>read-from-file are all a bit different.

I see maybe it's something wrong with the way I'm going about this. The following
are the commands I'm running:

mkpasswd (asks me to enter a password, I enter test)
Password:
$y$j9T$35ITJ7yCc3kFUsasf3QDa/$n.HqacKYHPIEE6VxIHhT2vW8.7vfh.fn008SQS5ETb9

printf "%s\n%s\n%s\n" "12345" "$y$j9T$35ITJ7yCc3kFUsasf3QDa/$n.HqacKYHPIEE6VxIHhT2vW8.7vfh.fn008SQS5ETb9"| sudo /sbin/cryptsetup luksAddKey /dev/sda3

(12345 is an existing key, and the password hash is test)

printf "test" | sudo cryptsetup luksOpen --test-passphrase /dev/sda3 && echo "There is a key available with this passphrase."
No key available with this passphrase.

(this shows that test doesn't work to unlock the encrypted partition)


>The man-page has more info on this. Best try it out with a
>really simple password like "test".

Could you point me to what section I should look at? The man page does mention hash
options but they relate to the encryption of the partition rather than the password I input
to cryptsetup.

BR,
Martin

Re: Password hash as LUKS key

[Grzegorz Szymaszek]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

Hi,

On Wed, Mar 15, 2023 at 03:11:18PM +0000, Martin Olsson wrote:
> printf "%s\n%s\n%s\n" "12345" "$y$j9T$35ITJ7yCc3kFUsasf3QDa/$n.HqacKYHPIEE6VxIHhT2vW8.7vfh.fn008SQS5ETb9"| sudo /sbin/cryptsetup luksAddKey /dev/sda3

 1. The format string contains three %s conversion specifications, but
    you provide printf with only two operands. Please try something like
    the following in your shell:

        printf '1. %s 2. %s 3. %s\n' FIRST SECOND

    This is probably not an issue since IIRC luksAddKey only asks for
    the new passphrase once, so it should ignore the next empty line.

 2. In double quotes, a dollar denotes a variable name. For example, in
    "$y$j9T", the shell replaces $y and $j9T with the values of the
    respective variables. Since they are probably not defined, they are
    replaced with empty strings instead. I think the actual password you
    set with the above command is
    "5ITJ7yCc3kFUsasf3QDa/.HqacKYHPIEE6VxIHhT2vW8.7vfh.fn008SQS5ETb9".

Good luck!

-- 
Grzegorz Szymaszek

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Password hash as LUKS key

[Michael Kjörling]

On 15 Mar 2023 15:11 +0000, from martinolsson311@yahoo.com (Martin Olsson):
> I see maybe it's something wrong with the way I'm going about this. The following
> are the commands I'm running:
> 
> mkpasswd (asks me to enter a password, I enter test)
> Password:
> $y$j9T$35ITJ7yCc3kFUsasf3QDa/$n.HqacKYHPIEE6VxIHhT2vW8.7vfh.fn008SQS5ETb9
> 
> printf "%s\n%s\n%s\n" "12345" "$y$j9T$35ITJ7yCc3kFUsasf3QDa/$n.HqacKYHPIEE6VxIHhT2vW8.7vfh.fn008SQS5ETb9"| sudo /sbin/cryptsetup luksAddKey /dev/sda3

Aside from that already mentioned by Grzegorz Szymaszek, a more
general question: what leads you to believe that you can give the
output from mkpasswd (which at least on Debian is provided by the
"whois" package) to cryptsetup (provided by the "cryptsetup-bin"
package) and have the mkpasswd output be recognized by cryptsetup as
being somehow special?

A quick web search for the two didn't reveal anything obvious
connecting the two; and the cryptsetup man page does not mention
mkpasswd.

When I try what you're doing on my system, there is no indication that
cryptsetup recognizes the $y$j... string as in any way special; in
fact, quite the opposite. I also don't see why cryptsetup _should_
recognize it as being somehow special, as you are just providing a
string to the luksAddKey operation to use as a keyslot passphrase.

Example:

# truncate -s 1G ~/tmpluks
# losetup -f --show ~/tmpluks
/dev/loop0
# cryptsetup luksFormat /dev/loop0
...
Enter passphrase for /root/tmpluks: <enter 12345>
Verify passphrase: <enter 12345>
# printf '%s\n%s\n%s\n' '12345' '$y$j9T$35ITJ7yCc3kFUsasf3QDa/$n.HqacKYHPIEE6VxIHhT2vW8.7vfh.fn008SQS5ETb9' | cryptsetup luksAddKey /dev/loop0
# cryptsetup luksOpen /dev/loop0 devloop0
Enter passphrase for /root/tmpluks: <enter 12345>
# cryptsetup luksClose devloop0
# cryptsetup luksOpen /dev/loop0 devloop0
Enter passphrase for /root/tmpluks: <enter test>
No key available with this passphrase.
Enter passphrase for /root/tmpluks: <enter $y$j...Tb9>
# cryptsetup luksClose devloop0
# losetup -D /dev/loop0
# rm ~/tmpluks 

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

Re: Password hash as LUKS key

[Martin Olsson]

On Wed, Mar 15, 2023 at 08:35:05PM +0000, Michael Kj�rling wrote:
> Aside from that already mentioned by Grzegorz Szymaszek, a more
> general question: what leads you to believe that you can give the
> output from mkpasswd (which at least on Debian is provided by the
> "whois" package) to cryptsetup (provided by the "cryptsetup-bin"
> package) and have the mkpasswd output be recognized by cryptsetup as
> being somehow special?

> A quick web search for the two didn't reveal anything obvious
> connecting the two; and the cryptsetup man page does not mention
> mkpasswd.

Oh, I was pretty certain that it wasn't going to work since like you
said it isn't documented anywhere. So I just assumed it wasn't supported
but then Arno replied:

>In priciple,
>this works and is supported, but interactive, pipe and
>read-from-file are all a bit different.

So I decided to give it another try. But I'm pretty sure now that Arno
misunderstood what I wanted to accomplish.

I want to encrypt the password before piping it to cryptsetup.
mkpasswd was just an example of that operation. You can also use python
for example:

python3 -c 'import crypt,getpass; print(crypt.crypt(getpass.getpass(), crypt.mksalt(crypt.METHOD_SHA512)))

But as you pointed out there is nothing in cryptsetup that recognizes
the encrypted string as anything other than a normal password. I was
hoping there was an option somewhere that I could add as an argument
to my cryptsetup command.

As there is no such option I am wondering if there is another solution
to my use case:

"I want to encrypt a drive for a user and I don't want the user to send me
their password in clear text."

Re: Password hash as LUKS key

[Arno Wagner]

On Mon, Mar 20, 2023 at 18:06:42 CET, Martin Olsson wrote:
[...]
> >In priciple,
> >this works and is supported, but interactive, pipe and
> >read-from-file are all a bit different.
> 
> So I decided to give it another try. But I'm pretty sure now that Arno
> misunderstood what I wanted to accomplish.
> 
> I want to encrypt the password before piping it to cryptsetup.
> mkpasswd was just an example of that operation. You can also use python
> for example:

As long as you pipe in the same thing on slot password setup and 
on slot unlock, it should work. Does not matter what it looks
like. So using an encrypted password works as long as it is
encrypted the same way each time and the rules for giving
it to cryptsetup are observed.

> "I want to encrypt a drive for a user and I don't want the user to send me
> their password in clear text."

Sure. See above. You may want to have a look at the section
"NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the cryptsetup
man page.

Regards,
Arno 

-- 
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: Password hash as LUKS key

[Michael Kjörling]

On 20 Mar 2023 19:53 +0100, from arno@wagner.name (Arno Wagner):
> As long as you pipe in the same thing on slot password setup and 
> on slot unlock, it should work. Does not matter what it looks
> like. So using an encrypted password works as long as it is
> encrypted the same way each time and the rules for giving
> it to cryptsetup are observed.
> 
>> "I want to encrypt a drive for a user and I don't want the user to send me
>> their password in clear text."
> 
> Sure. See above. You may want to have a look at the section
> "NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the cryptsetup
> man page.

But then the encrypted or hashed value corresponding to the passphrase
_becomes_ the container passphrase, and the plaintext passphrase that
was used to generate that value never figures into container creation
or usage.

If I understand correctly what Martin is trying to do, it is more
along the lines of:

1. Alice picks a secret LUKS container passphrase x.

2. Alice generates value x' = f(x), for some f(), such that x cannot
be derived from x'.

3. Alice provides Bob with the value x'.

4. Bob somehow uses the value x' to create a LUKS container and
ideally also populates the container with data based on plaintext data
provided by Alice.

5. Bob provides Alice with the container created in step 4.

6. Alice uses the secret value x to open the container and use it.

7. Eve, having seen the value x' and the full LUKS container
ciphertext including the LUKS header, is unable to use this knowledge
to access the plaintext contents of the LUKS container. (Eve may be
Bob.)

The question then boils down to: is there a way to provide especially
luksFormat with _something_ that is _not_ itself the passphrase, and
from which the desired passphrase cannot be derived (because if the
passphrase can be derived from what's provided, then there's really no
point to all this), yet which results in a known passphrase being
usable for unlocking the resultant LUKS container?

My gut feeling is that no, there isn't. The closest I can come up with
which _might_ be possible to press into service for this usage is to
create a container with a specific master key and grafting a different
header onto the container after the fact, which would be a relatively
complex and fairly risky operation that a user who isn't able/willing
to encrypt their own data probably shouldn't be undertaking.

Since this user clearly already trusts Martin with access to the
plaintext data, maybe the easiest way is to set up a container with an
empty (or trivial) password, and provide the user with a command to
change the passphrase and provide the user with clear instructions
that THIS MUST BE DONE before doing anything else with the drive. If
there is physical delivery involved, Martin could even hook up the
drive containing the container, start the password change process, and
walk out of the room as the user enters their actual desired passphrase.

Martin could still have a copy of the master key, including through a
header backup with the known passphrase; this can be worked around by
the user reencrypting the container, since that changes the master
key. LUKS 2's restartable reencryption might come in handy here.

Martin could have copied the user's data in plaintext and thus retain
access to it indefinitely; this is clearly a risk that this user is
willing to accept.

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

Re: Password hash as LUKS key

[Arno Wagner]

On Mon, Mar 20, 2023 at 21:38:56 CET, Michael Kjörling wrote:
> On 20 Mar 2023 19:53 +0100, from arno@wagner.name (Arno Wagner):
> > As long as you pipe in the same thing on slot password setup and 
> > on slot unlock, it should work. Does not matter what it looks
> > like. So using an encrypted password works as long as it is
> > encrypted the same way each time and the rules for giving
> > it to cryptsetup are observed.
> > 
> >> "I want to encrypt a drive for a user and I don't want the user to send me
> >> their password in clear text."
> > 
> > Sure. See above. You may want to have a look at the section
> > "NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the cryptsetup
> > man page.
> 
> But then the encrypted or hashed value corresponding to the passphrase
> _becomes_ the container passphrase, and the plaintext passphrase that
> was used to generate that value never figures into container creation
> or usage.
> 
> If I understand correctly what Martin is trying to do, it is more
> along the lines of:
> 
> 1. Alice picks a secret LUKS container passphrase x.
> 
> 2. Alice generates value x' = f(x), for some f(), such that x cannot
> be derived from x'.
> 
> 3. Alice provides Bob with the value x'.
> 
> 4. Bob somehow uses the value x' to create a LUKS container and
> ideally also populates the container with data based on plaintext data
> provided by Alice.
> 
> 5. Bob provides Alice with the container created in step 4.
> 
> 6. Alice uses the secret value x to open the container and use it.
> 
> 7. Eve, having seen the value x' and the full LUKS container
> ciphertext including the LUKS header, is unable to use this knowledge
> to access the plaintext contents of the LUKS container. (Eve may be
> Bob.)
> 
> The question then boils down to: is there a way to provide especially
> luksFormat with _something_ that is _not_ itself the passphrase, and
> from which the desired passphrase cannot be derived (because if the
> passphrase can be derived from what's provided, then there's really no
> point to all this), yet which results in a known passphrase being
> usable for unlocking the resultant LUKS container?
> 
> My gut feeling is that no, there isn't. 

Ah. If that is the intent, no there very likely is not. As 
the container is created by Bob and hence the container 
needs to be written by Bob and the container uses symmetric 
crypto, Bob can read it now and in the future, unless 
the master-key gets changed after Bob passes the container 
onwards. I sort-of ruled this use-case out as it is likely 
impossible to implement. 

This use-case would need a public-key scheme right at the 
base of the encryption (no symmetric layer) and that would be 
a different thing than the dm-crypt base used by LUKS and it
would have absolutely horrible performance.

The only way I see here is to create a setup-program that 
Alice can run at her site to create the container. Of course
if Bob does that program, he can still include various forms
of backdoors. If Bob is honest at container creation, he can
just forget the passwords handed to him. And if this is about
transport security during passphrase transfer, use any of the 
established solution for that.

Bottom line: You typically do not get any security against the
person creating your encrypted containers.

Regards,
Arno

-- 
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