If someone had previously followed the instructions on Libreboot.org (https://web.archive.org/web/20200327071913/https://libreboot.org/docs/gnulinux/encrypted_parabola.html#preparing-the-storage-device-for-installation) for setting up FDE (at least on Parabola, haven't verified on others), OpenSSL3 will lead to unbootable systems!
As the instructions lead to using the whirlpool hash function and that has been pulled out of OpenSSL:
Currently it has been moved to a compile-time flag but should be fully deprecated later, in Arch Linux they seem to have not enabled it (disabled by default), this means that any downstream distro of Arch will have this breakage.
There already seems to be breakage: https://labs.parabola.nu/issues/3368#note-19
I have also verified on my system that the hash is using whirlpool (T400, set up in 2020 following the instructions on libreboot.org).
As an update, all the guides on libreboot.org (or ones linked to) - except the Debian one (couldn't verify) - do specify the whirlpool algorithm for the hash, this means the breakage is wide-ranging and all those who followed these guides (even after libreboot.org re-write) will be affected.
I looked at OpenSSL's dependencies on ArchLinux and noticed its largely the same.
It is a pity that ArchLinux hasn't gotten the sense to switch to LibreSSL or something better than OpenSSL at least... aka, there are people talking about a possible heartbleed 2.0 vulnerability... smh...
Btw, isn't that parabola FDE guide above, extremely, mega old?
2+ years old...
Not surprised this would happen, this is what rolling release bleeding edge distros have a tendency to do.
Doesn't matter if it is old, chances are people aren't re-encrypting their devices all the time.
As for Arch's regrettable decision to use OpenSSL, we'll IDK - I'm trying to see if Parabola would switch to gnutls.
To anyone looking for a solution short of re-encryption:
Arch/Parabola now carry an openssl1.1 package, which has the legacy ciphers.
TL;DR: whirlpool is now considered a legacy cipher by OpenSSL.
Hmm... that begs the question then, which are the most secure algorithms that should be used for LUKS(2+)
Or as a whole...
This is for GNUPG:
but I wonder what is good for LUKS...
Food for thought anyhow, as I am curious.
could try libressl instead
archlinux has libressl in pacman repos
probably best not to rely on grub for fde anyway, it's horribly incomplete especially for luks2
this really isn't our bug
I keep forgetting that you said this about the 2nd luks, dunno why...
Btw, until something better arrives, wondered if you are going to fork nitrokey's heads version or w/e and add it.