Re: Bug in cryptsetup 2.3.0 (BitLocker key-file support)
Milan Broz <[email protected]>
| Newsgroups | gmane.linux.kernel.device-mapper.dm-crypt |
|---|---|
| Message-ID | <[email protected]> |
On 20/02/2020 03:23, Arno Wagner wrote: > On Wed, Feb 19, 2020 at 21:57:23 CET, Milan Broz wrote: >> On 19/02/2020 21:13, Quentin Lefebvre wrote: >>> 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... >> >> ok, thanks for the info. >> >> But I think we should perhaps process even this file (recovery >> passphrase has a special format - if it is detected, we try to use it, >> otherwise we parse it as a normal passphrase). >> I think we can do this even if it is has an additional EOL there. > > I would suggest giving a verbose warning in this case. > Something like, "recovery passphrase detected, extra EOL chars stripped." If it fails to open through a recovery passphrase slot, then code tries it as a normal one (key derivation is quite fast here, so it is just a small delay) - so this is really not necessary. m. _______________________________________________ dm-crypt mailing list [email protected] https://www.saout.de/mailman/listinfo/dm-crypt