XPost: linux.debian.doc

Sorry, didn't receive the follow-up on the bug (and forgot I had filed
the request in the first place). And https://lists.debian.org/debian-doc/2024/05/msg00003.html never made it
to the bug it seems.

On Sun, 5 May 2024 at 17:29:03 +0100, Justin B Rye wrote:

L wrote (https://lists.debian.org/debian-doc/2024/05/msg00003.html):

Guilhem Moulin <[email protected]> writes:

cryptsetup 2:2.7.0~rc0-1 has a backward incompatible change for plain
mode when relying on defaults cipher and password hashing algorithm.

The change affects users upgrading from bookworm to trixie. Plain mode
is generally advised against but it still makes sense to include the
NEWS entry into the release notes.

The text needs a bit of intro/context to be readable by an end-user. Can
you give some pointers to explain the basic issue here - what is "plain
mode"? is it the default now? what is the change, and what is the user
meant to do about in response to this change? what is the
"incompatability"?

I imagine it's connected with the Changelog entry saying:
[…]
(But I can't answer any of your questions, except that I noticed a
mention elsewhere of plain mode being the default.)

plain mode is the default when the crypttab(5) option field doesn't
specify any other type (luks, tcrypt, etc.). However I suspect most
users don't edit crypttab(5) manually, but instead do it automatically
at installation time (via d-i) which always sets the type explicitly.
d-i's default “LVM-over-crypt” setup sets up LUKS devices, but users can choose (explicit) plain in the menu too if they choose to do so.

Technically, “plain mode” means the device is mapped directly using a
key derived from a passphrase. Unlocking a device in plain mode is
always successful (there is no error checking), and unlocking with
different parameters (cipher, digest algorithm, key size, etc.) yields different mapped devices. Unlike LUKS, there is no header to check
whether the passphrase is correct, nor to store algorithms: consumers
need to always pass algorithms consistently at mapping time for
non-transient devices. (Generally, cryptsetup has consistently advised
not to use plain mode for non-transient devices.) Those who rely on
default algorithms for non-transient devices will experience a
regression when upgrading from bookworm to trixie. To fix the
regression, they will need to explicitly pass the previous defaults
using `--cipher aes-cbc-essiv:sha256 --hash ripemd160` (CLI), or `cipher=aes-cbc-essiv:sha256,hash=ripemd160` (crypttab). I expect the
latter to be far fewer though, since we're already spewing a warning
that default are not be relied upon for plain mode; but only when
processing crypttab(5), the cryptsetup(8) binary didn't spew such a
warning before 2:2.7.0.

Default cipher and password hashing for plain mode have respectively
been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256
resp. ripemd160).

It would help to start with "The" before "default".

what does "resp." mean in this context?

This one I know (and there's a clue earlier in the sentence): it's a
common non-native-English-speakerism. "Resp." is short for "and/or respectively",

Yup, and I was not aware that wasn't proper English, thanks.

but it's used where anglophones would be more likely to
use plain "and" or "or", and it's a warning sign of a tortuously
organised sentence. I'd suggest:

The default cipher has been changed to aes-xts-plain64 (from aes-cbc-essiv:sha256), and the default hash to sha256 (from ripemd160).

Make sense.

Is there a crucial word missing after "hashing" - should it be "hash
function"?

That (or "password hashing algorithm") would be more natural English,
but it might be better to stick to "hash" since that's the name of the crypttab field.

I think I meant to write hash algorithm here, but hash probably works
too.

The new values matches what is used for LUKS, but the change does NOT
affect LUKS volumes.

"value" not "values" here

(In fact I think he means "the new values match what is used...")

Correct.

(assuming LUKS is a noun) "by LUKS" not "for LUKS"?

LUKS is an acronym and stands for Linux Unified Key Setup.

the bit after the comma is pretty confusing to a non-expert like me,
what are you trying to say here? would i expect a change in cryptsetup
what *does* the change affect?

I don't understand the second sentence, but hopefully my first paragraph clarifies what I tried to say.

1/ Upstream's choice of new default algorithms for plain devices
matches what has already been used as default for LUKS. In
retrospect that might only be a curiosity though, so not worth
mentioning in the release notes.

2/ The new default don't affect LUKS devices, since those have a
header area where cipher, hash algorithm, etc. are stored as
metadata so don't need to be passed explicitly at mapping time.

This is a backward incompatible change for plain mode when relying on
the defaults, which (for plain mode only) is strongly advised
against.

i'm afraid I cant make any sense out of this paragraph! what is
"strongly advised against"?

"Relying on the defaults" - that is, leaving the fields empty in
crypttab.

Yup, or using the cryptsetup(8) binary without --hash or --cipher
options.

For many releases the Debian wrappers found in the ‘cryptsetup’ binary >>> package have spewed a loud warning for plain devices from crypttab(5)
where ‘cipher=’ or ‘hash=’ are not explicitly specified. The
cryptsetup(8) executable now issue such a warning as well.

Is this an unrelated change or is there some link to the above?

Part of the same deprecation process.

Correct.

Thanks for the reading and suggested improvements!
--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmhxhIoACgkQ05pJnDwh pVKc8w//Ry2KyS73VMJkK2I9wepaCBgskXQ5CBj6mGk6bHcrzQZEvRtnaRculyEj b7MOl8RRrKy3FfB2JYwzG9YMID7+FgeW6dIRWu/iUXFna6V9ynQA/Xz9rp3Fa5Kl kKtAtSdBij3jFp4dVfEwoVetLsFCylhh1GSjCimMK+xbqFD5nFDgPYwuESFIFHBd 150h57bwn91BvAtHC4RzC4DIDLeOqCHVcHg7Ocpe/fbLrLYZnuv2aOujuPMaIVS0 /wuB8qN2YCOKBCF26PlLdAQF9567aFD7GGQ6gy5KSqEsbzHVHKC94KO+RoLQP4kB e5i8jgljO7uAbhr7wRb72J/nenX4NuVTD6/SGcN8cotEvvZGUPq7fDCCu80JEG4I bzwfnLK2QqUo9JygwUwfLE9doFT61HM/tVD/RiYhrM8OtiK0XH6DcYFm4THmM0ds KXcyBtxfMlOFXKTO+vug5LXQ3O0aI5jgPA4RVxUQ8UEYTIqNzTXMBd/m9lCaJg9O gks/Vuqv0+F9mTNznnmwwoE/goqHdSIg9Wr4Xlsb6RGA/Ki6bbuf21Z4RIWUD2gM vvpApuSQx6g+LiswjAxeyDbhN5QS4VrPtesouulFo46tuCRT3vyuTACI8rCGP6LG cX/W0xPu8KgXFNDlv+O0CNFoukzXK8DVuvGSYIQ75vp40M5Abw0=
=/RNP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.doc

On Fri, 11 Jul 2025 23:39:24 +0200 Guilhem Moulin <[email protected]> wrote:

On Sun, 5 May 2024 at 17:29:03 +0100, Justin B Rye wrote:

L wrote (https://lists.debian.org/debian-doc/2024/05/msg00003.html):

Guilhem Moulin <[email protected]> writes:

cryptsetup 2:2.7.0~rc0-1 has a backward incompatible change for plain
mode when relying on defaults cipher and password hashing algorithm.

plain mode is the default when the crypttab(5) option field doesn't
specify any other type (luks, tcrypt, etc.). However I suspect most
users don't edit crypttab(5) manually, but instead do it automatically
at installation time (via d-i) which always sets the type explicitly.
d-i's default “LVM-over-crypt” setup sets up LUKS devices, but users can choose (explicit) plain in the menu too if they choose to do so.

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
explicitly include the settings in [/etc/cryptab]. To access encrypted filesystems, [/etc/crypttab] should specify the ``cypher`` and
``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
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
aes-cbc-essiv:sha256 --hash ripemd160``. Debian recommends you always 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 [???].


please check!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.doc

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.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmhyb10ACgkQ05pJnDwh pVIKkA//avXtFgccC6UT0jyTqfQJIOwQ3KFsXq6FFHg7Vu4YTubraYwkRpYjKZYK TAoMCdv6NnXPbP02jiQMSI7PwaLfMeJcSsjth94RJTPGyUMxtI+FTeLQjQ8rdxlo j/pLdX9/+vg973RrqGiuxj0JlWj6PXJjUa8YG/Wfta/35qbrfQaes9ksHaXR9K0Y KlibzhB5arcE/svZ6o/EOcMK1SQgJxXefGFOoF5mloOi4jE2pZ9eYAd3CoGxlhg6 w/JpLLo6clPCc6FYALjDtpkDBWGV+Fj8bDqljHi24FDGB/WEfVE0BHeymijVvR+o YlSub+79onDLliu9XZJiSr/VuP5pi6W+cMKiluKLiFquXMZ9ZfdC4ndc9UyPnAKI Iq+foGX0ql5w7k3My+ukPKTCse1nzmp0tqQruqbC6VoccayDWU/rnwAO7M5/Bqgl SjCCJ3huVEREhOXxJEg/uPoES5zCMT+J0o24ScwPWAjF9IOGeE+iOiLaDMFTPCtw Y2WKxsYtJu3wUCWm57ARvYRpak4djQGAvycY51ihoOn6iAnufFDTqu0sv4jAVR0d 0Bopq5CMTGmO3Dwn2gVkeyiG6T7cVor1EkgzX0xkTvc1x4jOAr+rHqRLpkx2msxQ f0/BwLcwUI12zwQ/6MRVOqpBJ6s8C2FdE0k3xjiULD7Pe9Ft9RM=
=MD5K
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.doc

On Sat, 12 Jul 2025 at 15:21, Guilhem Moulin <[email protected]> wrote:

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.

aha -- i had not understood that there was a difference, so i have
learned something (not east what a terrible design decision was made
with plain-mode!). I think the version below might be more accurate --
but can we tell people to record the keysize while we are at it -
crypttab(5) mentions this is also needed, but doesnt give any hints as
to the default values themselves! even though keysize did not change
in trixie, telling people to add it now may avoid future issues
(assuming anyone reads the release-notes)


change to default encryption settings for plain-mode dm-crypt devices ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The default settings for ``dm-crypt`` devices created using with
``plain``-mode encryption (see :url-man-stable:`crypttab(5)) have
changed to improve security. This will cause problems if you did not
record the settings used in ``/etc/crypttab``. The only recommended
way to configure plain-mode devices is to record the ``cipher``,
``hash`` and ``keysize`` options in ``/etc/crypttab``, but it is
possible to rely on `cryptsetup` using default values. Because the
default values for cipher and hash algorithm have changed in trixie,
such poorly-configured devices will not be accessible until you
properly configure them. This does not apply to LUKS devices because
LUKS records the settings in the device itself.

To properly configure your plain-mode devices, assuming they were
created with the bookworm defaults, you should add ``cipher=aes-cbc-essiv:sha256,hash=ripemd160`` to ``/etc/crypttab``.
To access such devices with ``cryptsetup`` on the command line you can
use ``--cipher aes-cbc-essiv:sha256 --hash ripemd160``. Debian
recommends you do not use plain mode for non-transient devices, and
that if you do use them, you should explicitly record all the
encryption settings used in ``/etc/crypttab``. The new defaults are ``cipher=aes-xts-plain64,hash=sha256``.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.doc

On Sat, 12 Jul 2025 at 18:22:56 +0100, Richard Lewis wrote:

On Sat, 12 Jul 2025 at 15:21, Guilhem Moulin <[email protected]> wrote:

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.

aha -- i had not understood that there was a difference, so i have
learned something (not east what a terrible design decision was made
with plain-mode!).

It doesn't belong to the release notes, but FWIW in upstream's defense,
LUKS is merely a metadata layer above plain mode in a way, which in
turns is a merely exposing to userspace dm-crypt capabilities from the
kernel. The defaults algorithms used to be the same for all modes, and upstream upgraded them for LUKS some releases ago, but until now had
held it back for plain to avoid backward incompatibility. So I think “terrible design decision” is a bit harsh.

I think the version below might be more accurate --
but can we tell people to record the keysize while we are at it -
crypttab(5) mentions this is also needed, but doesnt give any hints as
to the default values themselves! even though keysize did not change
in trixie, telling people to add it now may avoid future issues
(assuming anyone reads the release-notes)

Fair point, the default is size=256 both for ≤bookworm and trixie. The corresponding cryptsetup(8) option is `--key-size 256`. Both
crypttab(5) parsing and cryptsetup(8) binary spew a warning (with the
default size) if the key size is unspecified, but it doesn't hurt to
spell it down in the release notes indeed.

change to default encryption settings for plain-mode dm-crypt devices ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The default settings for ``dm-crypt`` devices created using with ``plain``-mode encryption (see :url-man-stable:`crypttab(5)) have
changed to improve security. This will cause problems if you did not
record the settings used in ``/etc/crypttab``. The only recommended
way to configure plain-mode devices is to record the ``cipher``,
``hash`` and ``keysize`` options in ``/etc/crypttab``, but it is

keysize → size (for historical reasons)

possible to rely on `cryptsetup` using default values. Because the
default values for cipher and hash algorithm have changed in trixie,
such poorly-configured devices will not be accessible until you
properly configure them.

I'd suggest to say that this will yield random-looking devices rather
than making them “not accessible”. That way the read can decide whether that's a regression (for a device holding a file system or something) or whether it can wait.

This does not apply to LUKS devices because LUKS records the settings
in the device itself.

To properly configure your plain-mode devices, assuming they were
created with the bookworm defaults, you should add ``cipher=aes-cbc-essiv:sha256,hash=ripemd160`` to ``/etc/crypttab``.

…,size=256

To access such devices with ``cryptsetup`` on the command line you can
use ``--cipher aes-cbc-essiv:sha256 --hash ripemd160``. Debian

… --key-size 256

recommends you do not use plain mode for non-transient devices, and
that if you do use them, you should explicitly record all the
encryption settings used in ``/etc/crypttab``. The new defaults are ``cipher=aes-xts-plain64,hash=sha256``.

FWIW technically specifying the hash is not needed when a key file is
used, but it doesn't hurt to have it in that case (it's ignored) so it's probably not worth spelling out the full logic in the release notes.

Thanks!
--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmhzrQcACgkQ05pJnDwh pVIWbQ//bSDR5m1TDrAMz+/OQ0M1aMgVRyPcTAhZf6ajqNwDGQSLqJvR0yXYe/KX 6KF1+TzG2ZqE/rPNUVOGa0V1GGrbK+81v5AuWM1mybOvNM1ET/QjpjWqJx97m6ft TVBq3L3T8tlzE8sUyQRdBvgxBBaXaHIyjxBR0bdg1N7r62v8bsdV9nxERPnVPf/w jBdFJSNINfNBCLtvMpP5f8j0EV5RxyM4qqwAnJ0BGa3dVD8YUm/3pAfxNwJCavUE xAiDV0cjjmm01iXU1waK0LwRigvG7yfUJkdsPGtsCtNnFDGvR8hz2SHP10B8jK+A 52727HgUSUQ0zSjhLQwffv59wfjwKajmr8h2HAyKKWeW/Vulv7v+f2lAOUbkxaiS QWXhgWEZoUlWR/ffdFveYNt+D9VpaLY0/lwOqZCHsIk9NoZctTxt42pMnGqrE3bZ Iz6PwgoM6cQDCCXqUIm/SoiSeYApM2hl5dtRZF5TYEAzxpupOY/nRg1cjJYBC7+g dwfFuDOOPzJwzEKA7oZPsA9wZA/IXma/ozCt8d8sAai9RraSYrfc0FQdLY4/cy6W k5zPciQnpV9lFH/Fr8fDana82HZ27uwdOyP91SwF9NnBv5oK+v2coBSwbHQ11+Nx jdleCpvcH8RHoirSUlshvrEnrdVrITNcVA0TJIfPZqrTjvntmCc=
=bexR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.doc

On Mon, 14 Jul 2025 at 10:14:51 +0100, Justin B Rye wrote:

I still have no real idea what the use case for "plain mode" is, or

Plain mode *is* used, I don't think the release notes is about
questioning users' use case. As I wrote earlier, both upstream and
Debian recommend LUKS for non-transient devices, but some use it anyway
and the release notes should warn them about it.

(therefore) what kind of users are going to need to know about all
this.

plain mode users not spelling out cipher= and/or hash= in crypttab(5)
(or --cipher and/or --hash when using the cryptsetup(8) CLI) for
non-transient devices.

I'd suggest to say that this will yield random-looking devices rather
than making them “not accessible”. That way the read can decide whether >> that's a regression (for a device holding a file system or something) or
whether it can wait.

(I don't follow this, possibly because I have no idea what the user is
likely to be trying to do.)

The using is creating a device which is mapped encrypted on hardware.
If that device is meant to be used as permanent storage, then the very
same encryption parameters need to be passed every single time the
device is mapped.

For LUKS mode, these parameters are stored in the metadata area at
creation (formatting) time and can be retrieved from there at mapping
time, so this is not an issue.

For plain mode, the user may be relying on defaults, or pass parameters explicitly (either in crypttab(5) or via CLI parameters). Default
parameters are subject to change, so user not spelling out encryption parameters explicitly are exposing themselves to regression. Mapping a
device with different encryption parameters will yield a device
containing data indistinguishable from random (it does *not* fail). If
the user is expecting to contain a file system or some kind of
persistent data, that's obviously problematic. If the device is meant
to be used for ephemeral storage, for instance for an encrypted swap
partition, that's not a big deal.

This does not apply to LUKS devices because LUKS records the settings
in the device itself.

To properly configure your plain-mode devices, assuming they were
created with the bookworm defaults, you should add
``cipher=aes-cbc-essiv:sha256,hash=ripemd160`` to ``/etc/crypttab``.

…,size=256

That is, make it
``cipher=aes-cbc-essiv:sha256,hash=ripemd160,siz=256`` to ``/etc/crypttab``.

I'd suggest

``cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160``

as the key size goes along with the cipher algorithm, while the hash
function does not (it's merely used for key derivation).

To access such devices with ``cryptsetup`` on the command line you can
use ``--cipher aes-cbc-essiv:sha256 --hash ripemd160``. Debian

… --key-size 256

use ``--cipher aes-cbc-essiv:sha256 --hash ripemd160 --key-size 256``. Debian

Similarly,

``--cipher aes-cbc-essiv:sha256 --key-size 256 --hash ripemd160``

recommends that you configure permanent devices with LUKS, or if you do use
plain mode, that you explicitly record all the encryption settings [...]

[…]

So maybe this combines with my last comment as
[...] that you explicitly record all the required encryption settings

Sounds good.

--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmh01UgACgkQ05pJnDwh pVK55A//XrOit5qJL9r5qfWc8cwukSf9r9kBJAnrvyByz1RNVA5m+1riW2sojs3C hI6DLWsd1LBFBjTCkCt0cZhqlIiidmbr41toDEdVGmuzbSofZiP1AK5eMDASBDXh hk1oG5DNlJMQH1Sn1bqE9DICD2be8833jUy3MH0suZS3SgRdnUgXe1hqvosiXjHz gDMfjH+DYGIOjFFWLgLm4JX4JweSULYpl4HsW6k1Rt/MdPWWwEIvJJjARg8Q6oOA qeEpmyU8e4N1cSCfRXljmMaHLOADxKSoEKbkkNMcyG4YAibZoRmVIt60s3ABLbnQ bkpNgg9oiEt41EqIhEVizKDajI163JfykdA/wcU+APaKBDgI3V6K8G1mwA7NJBB8 yeHD1yuUbYIykPsajLCMWFokFQjAycNeIuNZaOOvAckc6dr5tNolXxmGQjFdH40+ 4Va+0AR2rBqXvdw3Mh/8Ni7WuD4fwumn+S/1R83C6lWdOV8isFsAG9r53vzt3iA0 duGsp+Uwa5asqE/F6sQSrEzf0cC376E2IOJiNH5W/D4rYxojYmk2HaBIivFcXrXj 2Qur7n02bD9kmjIEOBpXu0bWGFO+N72zBtxkHVqSefcMfTBv0W/8OU9Jx9Jf41+h nI9ID/X62QPO9p4/fujqqVu/TaxLwndLVJ4L14Nd+FfFrO7zUTI=
=B0/g
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.doc

I Changed “otherwise `cryptsetup` will use default values” to “otherwise default values will be used” because it's the wrappers not the
cryptsetup(8) binary which use crypttab(5) directly. LGTM otherwise,
thanks!


change to default encryption settings for plain-mode dm-crypt devices ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The default settings for ``dm-crypt`` devices created using
``plain``-mode encryption (see :url-man-stable:`crypttab(5)) have
changed to improve security. This will cause problems if you did not
record the settings used in ``/etc/crypttab``. The recommended way
to configure plain-mode devices is to record the options ``cipher``,
``size`, and ``hash`` in ``/etc/crypttab``; otherwise `cryptsetup`
will use default values, and the defaults for cipher and hash
algorithm have changed in trixie, which will cause such devices to
appear as random data until they are properly configured.

This does not apply to LUKS devices because LUKS records the settings
in the device itself.

To properly configure your plain-mode devices, assuming they were
created with the bookworm defaults, you should add ``cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160`` to
``/etc/crypttab``.

To access such devices with ``cryptsetup`` on the command line you can
use ``--cipher aes-cbc-essiv:sha256 --key-size 256 --hash ripemd160``.
Debian recommends that you configure permanent devices with LUKS, or
if you do use plain mode, that you explicitly record all the required encryption settings in ``/etc/crypttab``. The new defaults are ``cipher=aes-xts-plain64`` and ``hash=sha256``.

--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmh1ACwACgkQ05pJnDwh pVIKDA/+LPNYLPCOOnpsMMwo2kD3hV6MMJAduZTuARXgaJZcMMmq5MNgaGCfFKLu PGMh19LX1d+OWYindI6/lGFyLf+Ot3MmAFC6X97CddnPlHsXXN3kLdmg9BQkiZE6 nwvMJc2osOfbEke8jSxyIrx/Fr2HukEj3mHDbbstAfaUmLMi43EfG0u5wskDd0/1 PUPLL5EV8w7ExgbJ4h6wkNnTWbKTXvZ5Ui+bPijbUrZdDKh6ikvY58xSUXFWxZ29 tfOPWJXyWbY1+OVpdQ1ikkcjDU0HYQ8e7qqStCNnFASDn62nXX4UTcCxO5upAavQ FeicXgknhByEBLACqkxSBg1QUNgn/We78/hBnRrOBU13NMYW38d1I64kA5IvKr8z iOpOvkrMLC2x9kWIqCUz8MW54O/p/LM7bAYRtn3NNhw+RWzw8goMuUo9oI3v3OmE OHL8e2n3ge8KVlJZBTW1Y4dxmc68FPvtPNWKfpoSFktWCpQIA2KAQCGnxM1KJ032 5X+TMi0czrVhZhpuWt45a26Bo3fBgN+y6G9qIhEkrqvqrlxkpBrAiJQNDgcZ/5gS ykfi8Qfr4Fpm10wqwCAGCx3/O32OU4mzqe9o/mMnGOeEwFrOLKYnK0mh78B6vLJB u9ZLMR88N0mf0TD0pZFv+NF1/gcy2E1rEKPp3umok/pRuTkTwZw=
=hKsb
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.doc

Control: forwarded -1 https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/283

On Mon, Jul 14, 2025 at 03:03:42PM +0200, Guilhem Moulin wrote:

I Changed “otherwise `cryptsetup` will use default values” to “otherwise
default values will be used” because it's the wrappers not the cryptsetup(8) binary which use crypttab(5) directly. LGTM otherwise,
thanks!

I put the text into this MR: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/283
and did some minor formatting fixes.

I think the text style could match the rest of the issues texts
better. Review/improvements/comments on the MR welcome.

Best,
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)