Re: Bug in cryptsetup 2.3.0 (BitLocker key-file support)
Quentin Lefebvre <qlefebvre_pro-/[email protected]>
| Newsgroups | gmane.linux.kernel.device-mapper.dm-crypt |
|---|---|
| Message-ID | <[email protected]> |
Hi Milan, Actually there will be no debug output as I found the problem (lying between the chair and the computer), thanks to your help. See below for the explanation. Le 19/02/2020 à 20:30, Milan Broz a écrit :> 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. Ok, it may be useful another day. >> 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. That's fair ;-) >> 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). The on-disk keyfile was the printed recovery passphrase provided by Windows... > So what is the exact content of your keyfile? Is there additional EOL, > or it had some more characters there? ls -l <my_recovery_password_file> showed a 56 bytes file and hexdump -C <my_recovery_password_file> showed a trailing '\x0a' character added by my favorite editor. Removing it with dd(!) solved my problem... Sorry for the useless message (I should have triple-checked) and thanks again for the new feature. Regards, Quentin _______________________________________________ dm-crypt mailing list [email protected] https://www.saout.de/mailman/listinfo/dm-crypt