[systemd-devel] homed, LUKS2 passphrase encoding, and recovery key

[Chris Murphy]

Thanks for the answer, it's very useful. When I asked the question, I
didn't fully appreciate the cryptographic and anti-forensic
capabilities in LUKS that almost certainly should not be
re-implemented elsewhere.

I'd like to better understand what it would take to support UTF-8
passphrases for LUKS (luksFormat, luksOpen). Consistently and
reliably, in a portable user home context. Of course the keyboard
could change. Locale could, thus default local language of the host
system could be different.

That's the short version. Everything below this line is a super
verbose explanation how I'm arriving at the above.

I assume users want their login passphrase to use local characters.
Germans should of course be allowed to create a login passphrase using
characters with umlaut; Japanese should of course be allowed to create
passphrases using kanji. And so on. I further assume that this same
login passphrase is what should be used for `cryptsetup
luksFormat/luksOpen' in order to *avoid* more indirection, and being
forced to invent new crypto, which entails a lot of work and risk:
security and interoperability.

Many users are conditioned to accept a restriction to the 95 printable
of the first 128 ASCII characters for a LUKS passphrase. That's
because the typical workflow demands volume unlocking in an
environment with a limited input stack (initramfs and plymouth). But I
assume a global user isn't prepared for, and shouldn't have to accept,
such a limitation for their login password. And in a systemd-homed
context, that means the login password, if it's what's handed off to
cryptsetup, are the same and also cannot be limited to ASCII.

So the question comes full circle.

What are all of the things that can affect the encoding between the
user's passphrase as it exists in their mind, and as handed off to
cryptsetup? How to store that metadata? That way it can be tested
against, and provide the user with helpful hints about why
authentication isn't succeeding. Right now it's a one size fits all.
There's no difference in the error between wrong passphrase (this user
is not authentic) and encoding failure due to keyboard change, or
keymapping change, or whatever else can affect encoding.

Small problem? :D

--
Chris Murphy