Hi, I recently came across some code that did this: cat binary_secret | cryptsetup luksFormat /dev/loop0 This appears to work (no message printed, exit status 0). What might not be obvious is that if binary_secret contains a '\n' character, input gets truncated at this point. This is different than cat binary_secret | cryptsetup luksFormat --key-file=- /dev/loop0 which will read all of binary_secret, regardless of whether there's a \n in it or not. This difference seems subtle and could lead to truncation of the secret. This should probably be clearer in the man page at a minimum (see patch), but I think a warning is appropriate too. Secret processing that stops at \n isn't appropriate for binary data. Thanks, Kent -- IBM LTC Security diff --git a/man/cryptsetup.8 b/man/cryptsetup.8 index b9298a5..f8d7abb 100644 --- a/man/cryptsetup.8 +++ b/man/cryptsetup.8 @@ -476,7 +476,8 @@ will quit with an error. If \-\-key-file=- is used for reading the key from stdin, no trailing newline is stripped from the input. Without that option, -cryptsetup strips trailing newlines from stdin input. +cryptsetup stops reading from stdin when it encounters a newline, +even if found in your binary key data! .SH NOTES ON PASSWORD PROCESSING FOR LUKS LUKS uses PBKDF2 to protect against dictionary attacks (see RFC 2898). _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
