Re: [dm-crypt] Debian installer formatting LUKS2 devices by default?

[Milan Broz <gmazyland@gmail.com>]

On 27/07/18 10:16, Guilhem Moulin wrote:
> Debian Buster will freeze at the beginning of next year and we have
> people asking for the installer to format devices with `--type luks2`.
> 
> (FWIW, I think these requests to default to `--type luks2` are mostly
> motivated by a better PBKDF, so nothing impossible to obtain by
> conversion from an existing LUKS1 device.)

Hi,

(btw another important LUKS2 option is the sector size - 4k sectors are
much faster if used over 4k sector devices)

We already added configure switch for default format, so now it is up to
the distro maintainer.

I would like to change upstream default in some next version (see below),
but we still have some issues to solve.

One important issue is with Argon2 (or with memory-hard functions in general):

If the Argon2 required amount of memory is too high (existing device from different
systems etc), out-of-memory killer can kill cryptsetup.
This is because of (stupid) Linux memory over-committing strategy.
(And that's why we have hard upper limit to 1GB but it is still a lot.)

We will need to tune some switches to work it reliably and perhaps
fork process during key-derivation to have control over possible unconditional
process termination to clean memory with sensitive data.
(I hate it, but seems nothing else is reliable.)

You can workaround it by limiting memory yourself, cryptsetup limits it as
well according to physical memory, but OOM can still happen, it just depends
how other processes allocates memory.

Just be prepared for these reports. Actually, it was Fedora installer where
we saw this when tried to use LUKS2 :-)

Another thing is that I would like to see some independent analysis of Argon2
costs - do we really provide better security margin than PBKDF2 now?


Anyway, the rough plan is:

- later this week there will be stable 2.0.4 release.

The major LUKS2 fix is that libcryptsetup is now linked to libblkid
and will not automatically recover from secondary header if it detects
another (fs) signature.
(Because recovery could revert intentional change... We were too aggressive here.)
Libblkid is already used in dm/udev rules, so it should not increase
any image sizes. (And it can be disabled in configure if needed.)

As a bonus we now warn user before luksFormat if some signature is found.

Related patch for libblkid that can detect secondary LUKS2 header and properly
wipe it in wipefs is in util-linux upstream, not sure if it planned for stable,
but is should be in distro that use LUKS2 as default.
(Now only primary header is wiped and some commands,  unfortunately including isLuks,
will quietly recover from secondary header :-)


- there will be cryptsetup 2.1 release, I hope not later than end of this year (i.e. 2018 :),
where some bigger changes are planned, including OOM "fixes" mentioned above
(but no changes in LUKS2 on-disk format, maybe we just increase default header size,
but that's already supported).

Perhaps I will need to bump library version because of some dm-integrity
parameters struct change (my mistake). Only recompilation will be needed though.

I guess we can make LUKS2 default in 2.1 upstream.

For the authenticated encryption - it will remain experimental for some time still.

There are AEGIS and MORUS AEADs in 4.18 kernel that have 128bit nonces, so are
usable for our scenarios, but some other things are missing in cryptsetup code
(resize, recovery on dm-integrity metadata/journal corruption etc).

Milan
 
> Personally I'd rather *not* have such custom defaults in the installer.
> Do you have any plan to have `luksFormat` default to LUKS2 at some
> point?  If so, any idea, when that would happen? ;-)  Given the warning
> in the latest Release Notes [0] I assume LUKS2 is not mature enough for
> our installer yet.  Not sure what other distros are doing, but for
> Debian we're waiting for that scary warning to disappear (or
> alternatively, an explicit blessing from upstream) before promoting
> LUKS2 (and latter authenticated encryption — once a better AEAD
> algorithm is available) in our installer and documentation :-)
> 
> Cheers,
>