Bug#379737: [Pkg-cryptsetup-devel] Bug#379737: cryptsetup: cannot handle UTF-8 in passphrase

[Robert Bihlmeyer]

Hi,

David Härdeman <david at 2gen.com> writes:

>>There is a caveat: if someone has a latin1 locale, sets a passphrase with
>>non-ascii characters, and later changes to a utf8 locale, he is subsequently
>>locked out of his data.
>
> Well, that goes for both cryptsetup during the initramfs stage and
> during normal use of the system, so it's something that will have to
> be addressed sooner or later by the user anyway.

Correct. But during normal use the user can set her console to
non-UTF8. Cryptosetup could also use large translation tables
(glibc's?) that may not be available in initramfs.

People that encrypted CDRs with latin1-passphrases will see this
problem (during normal use) for some time.

>>My other solution (normalising the passphrase to UTF-8 always) would have no
>>such problems, but it's a rather big hammer -- we can't put big translation
>>tables on initramfs I guess.
>
> Well, it wouldn't work simply because we can't know which encoding to
> convert from (i.e. was the old input in iso8859-1, or in iso8859-15,
> or something else).

The idea is to translate to UTF-8 on luksAddKey time. To be more
concrete:

1. Old passwords that are not UTF-8 are "lost" and need to be manually
   fixed. Should be documented.
2. Newly created keys always get their passphrases translated from
   whatever encoding is active (as per LANG and LC_*) to UTF-8.
3. initramfs always sets the terminal into UTF-8 mode, so new
   passwords will work without a hitch.

The feature from bullet 2 will probably need /usr/lib/gconv, but it
is not needed for the version put onto initramfs. (That was my main
fear, to bloat the initramfs by 5 megs or more.)

For legacy compatibility (e.g. old CDRs) cryptsetup could take a
--encoding=X parameter that translated from the current encoding
(usually UTF-8) to X so that passphrases encoded in X are still
usable.

This leaves d-i to think about.

-- 
Robbe