[dm-crypt] Reading the passphrase from a key-file

[dm-crypt] Reading the passphrase from a key-file

[Volker Dormeyer]

Hello,

today I have another question regading the key-file option. I am 
scripting something where the passphare is given by STDIN, with the 
following options:

cryptsetup luksOpen /dev/sde hdd --header header.img --key-file -

If I enter this line on a command line it prompts me with "Enter 
passphrase for /dev/sde", I was suspecting nothing. How can I make sure 
that the passphrase is being read form STDIN?

Thank  You!

Best Regards,
Volker



_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Milan Broz]

On 14/05/2021 13:51, Volker Dormeyer wrote:
> Hello,
> 
> today I have another question regading the key-file option. I am 
> scripting something where the passphare is given by STDIN, with the 
> following options:
> 
> cryptsetup luksOpen /dev/sde hdd --header header.img --key-file -
> 
> If I enter this line on a command line it prompts me with "Enter 
> passphrase for /dev/sde", I was suspecting nothing. How can I make sure 
> that the passphrase is being read form STDIN?

Cryptsetup checks if there is input from a real terminal (then displays this message)
or from a pipe. echo pwd | cryptsetup ... works.

But if the input is a binary file, it will stop on the first EOL (then you must use --keyfile-size).
Please read "NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the man page.

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Arno Wagner]

On Fri, May 14, 2021 at 15:41:31 CEST, Milan Broz wrote:
> On 14/05/2021 13:51, Volker Dormeyer wrote:
> > Hello,
> > 
> > today I have another question regading the key-file option. I am 
> > scripting something where the passphare is given by STDIN, with the 
> > following options:
> > 
> > cryptsetup luksOpen /dev/sde hdd --header header.img --key-file -
> > 
> > If I enter this line on a command line it prompts me with "Enter 
> > passphrase for /dev/sde", I was suspecting nothing. How can I make sure 
> > that the passphrase is being read form STDIN?
> 
> Cryptsetup checks if there is input from a real terminal (then displays this message)
> or from a pipe. echo pwd | cryptsetup ... works.
> 
> But if the input is a binary file, it will stop on the first EOL (then you must use --keyfile-size).
> Please read "NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the man page.
> 
> Milan

Was just about to point out the same thing.

"NOTES ON PASSPHRASE PROCESSING FOR LUKS" is towards the end of
the 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
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Christoph Anton Mitterer]

On Fri, 2021-05-14 at 15:41 +0200, Milan Broz wrote:
> But if the input is a binary file, it will stop on the first EOL
> (then you must use --keyfile-size).
> Please read "NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the man
> page.

The manpage might be a bit ambiguous there, it says:
>From key file: The complete keyfile is read up to the compiled-in
>maximum  size.  Newline  characters  do not terminate the input.


What exactly is a key file here?
I assume "luksFormat <device> [<key file>]" definitely counts to it.

Thus everyone who created his volumes like this, should be on the safe
side (an quickly notice in any other operations, if he doesn't use the
full key), right?

Same, when "--key-file=someActualFile luksFormat <device>" is used, I
guess.


But what about when --key-file=- is used?

That's kind of a mix between "key file" and stdin, the later which is
documented to end et EOL.
I strongly hope in that case it also read the *full* stdin?



Cheers,
Chris.

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Clemens Fruhwirth]

On Fri, 14 May 2021 at 15:44, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 14/05/2021 13:51, Volker Dormeyer wrote:
> > Hello,
> >
> > today I have another question regading the key-file option. I am
> > scripting something where the passphare is given by STDIN, with the
> > following options:
> >
> > cryptsetup luksOpen /dev/sde hdd --header header.img --key-file -
> >
> > If I enter this line on a command line it prompts me with "Enter
> > passphrase for /dev/sde", I was suspecting nothing. How can I make sure
> > that the passphrase is being read form STDIN?
>
> Cryptsetup checks if there is input from a real terminal (then displays this message)
> or from a pipe. echo pwd | cryptsetup ... works.
>
> But if the input is a binary file, it will stop on the first EOL (then you must use --keyfile-size).
> Please read "NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the man page.

Milan, could you help my memory here:

>       From key file: The complete keyfile is read up to the compiled-in maximum size. Newline characters do not terminate the  input.  The  --keyfile-size
>       option can be used to limit what is read.

Did I chose this "up to the compiled-in maximum size" either
explicitly or implicitly back in the days? Checking get_key inside
lib/utils.c in the ancient release 1.0.6 from some time in 2007 looks
as if there was no such limit.

Introducing a compile-time limit has the unfortunate property that two
cryptsetup binaries compiled with different settings won't be able to
produce compatible key slots when pointed to key files that exceed
this compiled-in limit.

Cheers,
-- 
Fruhwirth Clemens http://clemens.endorphin.org
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Milan Broz]

On 14/05/2021 17:22, Clemens Fruhwirth wrote:
> On Fri, 14 May 2021 at 15:44, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 14/05/2021 13:51, Volker Dormeyer wrote:
>>> Hello,
>>>
>>> today I have another question regading the key-file option. I am
>>> scripting something where the passphare is given by STDIN, with the
>>> following options:
>>>
>>> cryptsetup luksOpen /dev/sde hdd --header header.img --key-file -
>>>
>>> If I enter this line on a command line it prompts me with "Enter
>>> passphrase for /dev/sde", I was suspecting nothing. How can I make sure
>>> that the passphrase is being read form STDIN?
>>
>> Cryptsetup checks if there is input from a real terminal (then displays this message)
>> or from a pipe. echo pwd | cryptsetup ... works.

Just one note: handling of --key-file=- is backward compatible, that why
it behaves so strange (mainly in plain mode) - we have the whole test to not break this behavior
(tests/password-hash-test).

Many old distro scripts required that strange handling of \n...

>> But if the input is a binary file, it will stop on the first EOL (then you must use --keyfile-size).
>> Please read "NOTES ON PASSPHRASE PROCESSING FOR LUKS" in the man page.
> 
> Milan, could you help my memory here:
> 
>>       From key file: The complete keyfile is read up to the compiled-in maximum size. Newline characters do not terminate the  input.  The  --keyfile-size
>>       option can be used to limit what is read.
 
> Did I chose this "up to the compiled-in maximum size" either
> explicitly or implicitly back in the days? Checking get_key inside
> lib/utils.c in the ancient release 1.0.6 from some time in 2007 looks
> as if there was no such limit.

Hard limit was patch that I added later (in 1.3.0) - and the default is 8MB for keyfiles.

If you use /dev/urandom or something like that, it eats all your memory after some time and crashes.

Also, with PBKDF2 there is nasty property, that you can hash input in advance,
and the output is the same - so super-large keyfiles do not make much sense.
(With Argon2 it is no longer the case.)

> Introducing a compile-time limit has the unfortunate property that two
> cryptsetup binaries compiled with different settings won't be able to
> produce compatible key slots when pointed to key files that exceed
> this compiled-in limit.

For the terminal (interactive entry), the limit is 512 bytes, but there are many other
limits elsewhere, I think on some terminal you cannot even enter such long entry.

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Clemens Fruhwirth]

On Fri, 14 May 2021 at 17:51, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 14/05/2021 17:22, Clemens Fruhwirth wrote:
> > On Fri, 14 May 2021 at 15:44, Milan Broz <gmazyland@gmail.com> wrote:
>
> >>       From key file: The complete keyfile is read up to the compiled-in maximum size. Newline characters do not terminate the  input.  The  --keyfile-size
> >>       option can be used to limit what is read.
>
> > Did I chose this "up to the compiled-in maximum size" either
> > explicitly or implicitly back in the days? Checking get_key inside
> > lib/utils.c in the ancient release 1.0.6 from some time in 2007 looks
> > as if there was no such limit.
>
> Hard limit was patch that I added later (in 1.3.0) - and the default is 8MB for keyfiles.
>
> If you use /dev/urandom or something like that, it eats all your memory after some time and crashes.

I am not sure why anyone would ever read keys from /dev/urandom. Maybe
to create throw away encrypted swap partition, but supplying
--key-size should resolve this. In the LUKS case, I think that
/dev/urandom never makes sense as key material. I don't have strong
opinions on whether a tool should protect you against OOMs when you
give it an infinitely large file to read. Probably not.

> Also, with PBKDF2 there is nasty property, that you can hash input in advance,
> and the output is the same - so super-large keyfiles do not make much sense.
> (With Argon2 it is no longer the case.)

I think that precomputability is a desired property of an HMAC, and as
PBKDF2 uses it as a building block, we kind of inherit that.
Interestingly, with HMAC-SHAS1 we could support keys larger than our
memory, as with HMAC-SHA1(K,m) we don't need to ever keep K in memory
in full.[1] But that's really not a worthwhile goal to begin with.
Argon2 is certainly the better choice.

But I don't think that you can produce output that is "the same"
regardless of key size with PBKDF2 -- at least in theory -- as the
derived key is a concatenation of xor-ed PRF outputs. If you disagree,
maybe you want to elaborate on that :).

Best regards,
Clemens

[1] For HMAC-SHA1(K,m) = SHA1_outer((K ^ opad) || (SHA1_inner(K ^
ipad) || m)), we can iteratively compute SHA1_outer/SHA1_inner and
immediately discard K.
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Milan Broz]

On 14/05/2021 20:10, Clemens Fruhwirth wrote:
> On Fri, 14 May 2021 at 17:51, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 14/05/2021 17:22, Clemens Fruhwirth wrote:
>>> On Fri, 14 May 2021 at 15:44, Milan Broz <gmazyland@gmail.com> wrote:
>>
>>>>       From key file: The complete keyfile is read up to the compiled-in maximum size. Newline characters do not terminate the  input.  The  --keyfile-size
>>>>       option can be used to limit what is read.
>>
>>> Did I chose this "up to the compiled-in maximum size" either
>>> explicitly or implicitly back in the days? Checking get_key inside
>>> lib/utils.c in the ancient release 1.0.6 from some time in 2007 looks
>>> as if there was no such limit.
>>
>> Hard limit was patch that I added later (in 1.3.0) - and the default is 8MB for keyfiles.
>>
>> If you use /dev/urandom or something like that, it eats all your memory after some time and crashes.
> 
> I am not sure why anyone would ever read keys from /dev/urandom. Maybe
> to create throw away encrypted swap partition, but supplying
> --key-size should resolve this. In the LUKS case, I think that
> /dev/urandom never makes sense as key material. I don't have strong
> opinions on whether a tool should protect you against OOMs when you
> give it an infinitely large file to read. Probably not.

There was some real issue with that, but really, it was introduced in 2011
and I already forgot details.
Limiting maximal keyfile size to some reasonable value makes sense to me.
(You can set the limit during compilation time anyway.)

>> Also, with PBKDF2 there is nasty property, that you can hash input in advance,
>> and the output is the same - so super-large keyfiles do not make much sense.
>> (With Argon2 it is no longer the case.)
> 
> I think that precomputability is a desired property of an HMAC, and as
> PBKDF2 uses it as a building block, we kind of inherit that.
> Interestingly, with HMAC-SHAS1 we could support keys larger than our
> memory, as with HMAC-SHA1(K,m) we don't need to ever keep K in memory
> in full.[1] But that's really not a worthwhile goal to begin with.
> Argon2 is certainly the better choice.
> 
> But I don't think that you can produce output that is "the same"
> regardless of key size with PBKDF2 -- at least in theory -- as the
> derived key is a concatenation of xor-ed PRF outputs. If you disagree,
> maybe you want to elaborate on that :).

What I meant is that HMAC property in PBKDF2-HMAC, if the input is longer
than internal block size of used hash (for SHA1 64 bytes), then it uses hash of input.

So both input and SHA1(input) in PBKDF2-HMAC-SHA1 will produce the same derived key.
https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions

It was only problem when we did not run this optimization then PBKDF2 code actually calculates
a lot of unneeded work (while attacker running brute force can just hash it in advance).
(Older cryptsetup release has this problem, now it uses crypto library for PBKDF2 anyway.)

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Reading the passphrase from a key-file

[Clemens Fruhwirth]

On Fri, 14 May 2021 at 22:43, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 14/05/2021 20:10, Clemens Fruhwirth wrote:
> > On Fri, 14 May 2021 at 17:51, Milan Broz <gmazyland@gmail.com> wrote:
> > But I don't think that you can produce output that is "the same"
> > regardless of key size with PBKDF2 -- at least in theory -- as the
> > derived key is a concatenation of xor-ed PRF outputs. If you disagree,
> > maybe you want to elaborate on that :).
>
> What I meant is that HMAC property in PBKDF2-HMAC, if the input is longer
> than internal block size of used hash (for SHA1 64 bytes), then it uses hash of input.
>
> So both input and SHA1(input) in PBKDF2-HMAC-SHA1 will produce the same derived key.
> https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions

Thank you, Milan, I wasn't aware of that property! TIL.

Best Regards, Clemens
-- 
Fruhwirth Clemens http://clemens.endorphin.org
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de