Hi, On 19/02/2020 17:05, Quentin Lefebvre wrote: > Dear cryptsetup maintainer, > > I discovered a functional bug in the recently added BitLocker support > (thanks by the way!) > Not sure whether it is the place to report it... The best is to report issue here https://gitlab.com/cryptsetup/cryptsetup/issues but this list works as well. > > Summary: > cryptsetup 2.3.0 cannot open a bitlk device when I provide a file > containing its password (fails with error -2). > > Command failing: > > cryptsetup open --type bitlk --key-file <my_password_file> > /dev/<bitlocker_device> bitlocker_mapping > > It is very easy to reproduce, so I don't copy paste the --debug output. The debug output provides information of all subsystem versions, this could be important. This is why I require it on all reports. > > I digged in the source code and found the problem in > src/cryptsetup.c:543-545, where opt_keyfile_size is used when calling > tools_get_key(). And default is 0, so the full keyfile is read (limited by maximal keyfile size). So it should work... > The workaround is actually to provide the exact password size on the > command line, e.g.: > > cryptsetup open --type bitlk --keyfile-size 55 --key-file > <my_recovery_password_file> /dev/<bitlocker_device> bitlocker_mapping Hm, so what is the on-disk keyfile size here? In cryptsetup, the whole keyfile is read, unless you limit it (as in your workaround). So what is the exact content of your keyfile? Is there additional EOL, or it had some more characters there? Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
