Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults

Guilhem Moulin <[email protected]> Sat, 12 Jul 2025 16:21:19 +0200
Newsgroups	gmane.linux.debian.devel.documentation
Message-ID	<aHJvX4Y2sjG7CuTL__10115.5564699852$1752330205$gmane$org@debian.org>
On Sat, 12 Jul 2025 at 14:52:13 +0100, Richard Lewis wrote:
> I think what i understand from this (which may be very wrong) is:
>
> The default settings for LUKS filesystems (see crypttab(5)) have
> changed to improve security, which may cause issues if you did not

No, the new defaults affect plain dm-crypt devices only (aka plain
mode), Algorithms for LUKS remain unchanged for Bookworm → Trixie.

While algorithms for LUKS did change too in an earlier release, that
didn't cause any regression since LUKS have a metadata header area
containing algorithms needed to unlock the device.  LUKS devices are
therefore forward compatible with newer cryptsetup(8) binaries in a way.
plain devices are *not*, and this is what this release note paragraph is
trying to warn users about.

> explicitly include the settings in [/etc/cryptab]. To access encrypted

/etc/crypttab

> filesystems, [/etc/crypttab] should specify the ``cypher`` and

cipher

That works if *should* is not a must but only a strong recommendation
here.  Also this sentence should say that this recommendation only
applies to plain devices.  For LUKS, specifying --cipher and/or --hash
at mapping time is a no-op.

> ``hash`` that were used to create the filesystem: these are usually
> set to the correct values automatically (for example the debian
> installer usually writes them to the file), but if they are not
> present, LUKS falls back to default values. Because the default values

the *cryptsetup(8) binary* falls back to default values.  Again, this
only applies to plain devices.

> have changed in trixie, filesystems created in bookworm will not be
> accessible, which may prevent you from booting the system. To access
> such filesystems, assuming they were created with the previous
> defaults, you should add
> ``cipher=aes-cbc-essiv:sha256,hash=ripemd160`` to [/etc/crypttab].  If
> you use [LUKS on the command line] you can use ``--cipher

Replace [LUKS on the command line] with “the cryptsetup(8) binary to
manually unlock existing plain devices from an older release `cryptsetup
--open --type plain`”.

> aes-cbc-essiv:sha256 --hash ripemd160``.  Debian recommends you always

So does upstream.  And we both advise against using plain mode for
non-transient devices in the first place.  (Where transient means for
instance an ephemeral device holding a swap partition not used as a
resume device.  That would be a valid use case for plain mode with a
random key, so closing the encrypted device or rebooting would destroy
the swap partition.  That use case is however not affected by the
algorithm change, since each `cryptsetup open --type plain --key-file
/dev/urandom` call yields a whole new mapped device.)

> explicitly set the exact values used to create a filesystem in
> [/etc/crypttab].
>
> The new defaults are ``cipher=aes-xts-plain64,hash=sha256``: you can
> change LUKS filesystems to use the new defaults by [???].

Suggesting to migrate existing devices to new defaults doesn't really
make sense (at least on non-transient devices) because that would yield
a seemingly random device (where no file system could be found).  I
would just strike that sentence.

-- 
Guilhem.
signature.asc (application/pgp-signature, 833 B)