On 14/05/2021 17:22, Clemens Fruhwirth wrote: > On Fri, 14 May 2021 at 15:44, Milan Broz <gmazyland@xxxxxxxxx> 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@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
