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
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
