I just read this article about weaknesses in Linux disk encryption https://mjg59.dreamwidth.org/66429.html and wonder how it applies to Fedora? Can the instructions in the article be applied to a Fedora installation?
On Wed, 2023-04-19 at 07:53 +0200, Andreas Fournier wrote:
I just read this article about weaknesses in Linux disk encryption https://mjg59.dreamwidth.org/66429.html and wonder how it applies to Fedora?
To be honest, I've always considered encryption of drives to *probably* be able to protect your data from the casual thief, but not from government agencies (who do have the computing horsepower to brute force things, or have managed to spy on you). And for all we know, one of their programmers secretly contributed code to the encryption feature.
On the other hand, if your drive was super-heavily-encrypted, it'd be a pain for all the files that you need to read and write as you used it.
But even new hardware can have malware preinstalled. My laptop did. Asus clearly used a cracked version of WinZip in preparing the drive image, it had the tool used for cracking it (with malware in it), installed on the system. And it was only a few days ago I watched a video criticising just about every Android TV box for some dodgy updating tool that's pre-installed on them.
And I recall in recent years a stoush in the news about an government agency wanting to crack an iPhone, Apple refusing to help, threats escalated, but they cracked it via some third party in the end, anyway. But if you try to create a super-secure something, *they* try very hard to outlaw it.
So I have little trust in anything. Fortunately I'm not plotting coups, nor work in soul-destroying three-letter-agencies.
On Wed, 19 Apr 2023 07:53:33 +0200 Andreas Fournier andreas.fournier@runbox.com wrote:
I just read this article about weaknesses in Linux disk encryption https://mjg59.dreamwidth.org/66429.html and wonder how it applies to Fedora? Can the instructions in the article be applied to a Fedora installation?
Fedora has version 2.06 of grub2 which has support for argon2id patched in, though it is slated to be native in the 2.11 release of grub2. https://www.phoronix.com/news/GRUB-2.11-Next-Year However it is much later than a year, and 2.11 is not out. There were extensive discussions of including a patch to allow it in 2.06 https://lists.gnu.org/archive/html/grub-devel/2020-02/msg00040.html And it seems that support was added.
Fedora has the argon2 package. https://packages.fedoraproject.org/pkgs/argon2/argon2/index.html
I see this reference to a patch to add argon2 support to grub2 for Arch: https://mdleom.com/blog/2022/11/27/grub-luks2-argon2/
I haven't done it, but after doing this research, I think the answer to your question is yes, you can follow those instructions in Fedora. What isn't clear to me is if it is possible to do it directly without following those instructions. That is, is there native argon2id support now backported to grub2 2.06? Maybe someone with direct experience can give better tuned advice.
Methinks that better than having a program try to get 128 bits out of 20 bits is to start with 128 bits. This is especially true if one's opponent is a government[*]. At 6 bits per character, 128 bits can be expressed as 22 characters. Put the output of uuidgen -r through a filter to get 22 charcters. One might also use it directly.
It seems to me that a tricky part of brute force is deciding whether a key works. My guess is that it is done by looking for text or for filesystem features. I'd expect a partition without a filesystem and filled with binary passwords to be difficult to crack. A filesystem that took a second to start because it took that long to find its header might also present difficulties, especially if all the files were compressed.
[*] Or not. In some countries, e.g. Britain, one is required to hand over such keys on demand. Regarding such things, there is no right not to testify against oneself. One might have a choice of crimes.