Re: Bug in cryptsetup 2.3.0 (BitLocker key-file support)

Hi Milan, Arno,

Thanks for your answers.
Below, my humble point of view...

Le 20/02/2020 à 07:37, Milan Broz a écrit :
> 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.

I think it would be a bit surprising (and a bit dangerous maybe) not to 
have a consistent behavior of cryptsetup between a bitlk recovery 
passphrase and a bitlk "normal" passphrase.

Although it is possible to add code to detect a bitlk recovery 
passphrase, it may be confusing for the user if cryptsetup is not 
consistent for all kinds of passphrases (bitlocker, luks, ...)

But suggestions are always good and here is mine:
When cryptsetup attemps to use a passphrase provided in a file:
1) try it,
2) only if the provided passphrase file fails, test whether there is a 
trailing EOL (maybe Unix/Windows-like) and try again cutting it (here I 
agree with Arno the user should be warned).

IMHO, this solution may be easier to implement and it has the benefits 
to be consistent for all kind of encrypted containers, and also to make 
the user aware of the EOL problem in his file (and learn more about his 
favorite text editor ;-).

Have a nice day,
Quentin

_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt