Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
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
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
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. signature.asc Description: PGP signature
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
Guilhem Moulin wrote: > 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. [...] Never mind all this beating me over the head with HOWTO information, let's skip to the part where you answer my WHYTO question: encrypted swap! Thanks, now it makes sense. [...] > 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. Okay, so talking about "accessing" the device may be misleading. Revised version below... 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). For consistency I'll put "size" second in the listing of options above, too. 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. So revisions so far: 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,hash=sha256``. Or does that last line look as if it's saying to remove "size"? If so, we could say that the defaults are ``cipher=aes-xts-plain64`` and ``hash=sha256``. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
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. signature.asc Description: PGP signature
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
cryptsetup has plenty of HOWTO documentation, but it's sadly lacking in WHYTOs. I still have no real idea what the use case for "plain mode" is, or (therefore) what kind of users are going to need to know about all this. Guilhem Moulin wrote: > On Sat, 12 Jul 2025 at 18:22:56 +0100, Richard Lewis wrote: >> 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 Surplus word: s/created using with/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 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. Avoid saying it's possible to rely on the defaults: record the settings used in ``/etc/crypttab``. The recommended way to configure plain-mode devices is to record the options ``cipher``, ``hash`` and ``size`` in ``/etc/crypttab``; otherwise `cryptsetup` will use default values, and the defaults for cipher and hash algorithm have changed in trixie, which will render such devices inaccessible until they are properly configured. > 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.) >> 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``. >> 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 >> 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``. I've heard of transient keys, but I have no idea what a transient device would be. If it's the opposite of (say) "permanent", I'd suggest cancelling out the negatives to get something like: recommends that you configure permanent devices with LUKS, or if you do use plain mode, that you explicitly record all the encryption settings [...] > 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. So maybe this combines with my last comment as [...] that you explicitly record all the required encryption settings -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
On Sat, 12 Jul 2025 at 18:22:56 +0100, Richard Lewis wrote: > On Sat, 12 Jul 2025 at 15:21, Guilhem Moulin 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. signature.asc Description: PGP signature
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
On Sat, 12 Jul 2025 at 15:21, Guilhem Moulin 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``.
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
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 Description: PGP signature
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
On Fri, 11 Jul 2025 23:39:24 +0200 Guilhem Moulin 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/msg3.html): > >> Guilhem Moulin 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!
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
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/msg3.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/msg3.html): >> Guilhem Moulin 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 i
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
RL wrote (https://lists.debian.org/debian-doc/2024/05/msg3.html): > Guilhem Moulin 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: # + plain mode: Set default cipher to aes-xts-plain64 and password hashing # to sha256. This is a backward incompatible change for plain mode when # relying on the defaults. It doesn't affect LUKS volumes. Defaults for # plain mode should not be relied upon anyway; for many releases the # Debian wrappers found in the 'cryptsetup' binary package spew a loud # warning when 'ciphers' or 'hash=' are not explicitly specified in the # crypttab(5) options of plain devices. The cryptsetup(8) executable now # issue such a warning as well. (But I can't answer any of your questions, except that I noticed a mention elsewhere of plain mode being the default.) >> 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", 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). (I see crypttab(5) is absolutely infested with resps.) > 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. >> 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...") > (assuming LUKS is a noun) "by LUKS" not "for LUKS"? (No idea.) > 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? (No idea.) >> 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. >> 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. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults
Package: release-notes Severity: wishlist Hi, 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. --8<->8-- 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). The new values matches what is used for LUKS, but the change does NOT affect LUKS volumes. This is a backward incompatible change for plain mode when relying on the defaults, which (for plain mode only) is strongly advised against. 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. --8<->8-- (Original text from https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/latest/debian/cryptsetup-bin.NEWS ) Cheers, -- Guilhem. signature.asc Description: PGP signature
