Hi, And sorry for the lag. While I understand why one might want to use LUKS2, this switch seems to be happening very late in the release cycle…
Guilhem Moulin <guil...@debian.org> (2019-02-09): > On Sat, 09 Feb 2019 at 00:34:47 +0000, Debian FTP Masters wrote: > > * New upstream release. Highlights include: > > - The on-disk LUKS format version now defaults to LUKS2 (use `luksFormat > > --type luks1` to use LUKS1 format). Closes: #919725. This is apparently incompatible with GRUB's cryptodisk feature, as I've only learned today during release preps? I've opened this to link it from our errata page: https://bugs.debian.org/927165 > > - LUKS' default key size is now 512 in XTS mode, half of which is > > used for block encryption. XTS mode uses two internal keys, hence > > the previous default key size (256) caused AES-128 to be used for > > block encryption, while users were expecting AES-256. I had spotted it from the changelog (I gather all changelog excerpts from all udeb-producing packages when preparing our release announce), and I've mentioned this en passant in the bug report above. > `luksFormat` might cause entropy starvation on low-entropy systems that > use the default key size (i.e., don't pass `-s`) *and* use `--use-random`. > (The default RNG source for volume keys was, and still is, /dev/urandom.) > Probably irrelevant for d-i? We have known entropy issues at the moment: https://bugs.debian.org/923675 and before that, we already encountered issues with the graphical installer due to the availability of getrandom(): https://debamax.com/blog/2018/05/25/debugging-black-screen-in-debian-installer/ but I haven't spotted anything like that when testing the guided encrypted LVM recipe (that's one of the usual tests I run before deciding a release can be prepared). Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
