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

[Jonas Meurer]

On 28/08/2006 Robert Bihlmeyer wrote:
> >>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.

as i understood, not if they still use latin1 locales.

> >>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.)

i don't support this request. it will break to much.

it's not that we should care for every corner case. if you want special
(localized) characters in your password, it's your job to check for
locale settings.

and from my understanding, your proposal still can break with different
keyboard layouts used for luksFormat and luksOpen. especially if the
charset has been changed, converted, whatsoever.

> 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.

it's not the job of cryptsetup to deal with encodings at all. i don't
know any commandline software that requires password prompt and that
deals with encodings.

it's the users job to configure his/her console properly.

...
 jonas