Also, by going with the original article (https://nantes.indymedia.org/posts/87395/une-lettre-divan-en...), which I translated using DeepL, this is what we know:

> As far as the investigation is concerned, in recent months new elements have been added to the file. The most significant is that the police managed to gain access to my computers, even though they were encrypted. The one at work, on which Windows is installed, is encrypted with BitLocker. _A previous report in the file says that they had already tried to access it while I was in police custody but had not succeeded._ But in September the Brigade d'appui en téléphonie, cyber-investigation et analyse criminelle (BATCIAC) sent a copy of the hard disk to the SDAT. In the PV, they only explain that they booted the computer with a bootable USB key and then used the software AccesData FTK imager 3.3.05 to copy the hard disk. But they don't talk about the decryption itself.

> My personal computer, which runs Ubuntu 18, is encrypted with Luks (the password is more than twenty characters: letters, numbers, punctuation marks...). I couldn't find any indication in the file about how they decrypted it, but there too they made a copy of the hard disk. There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted). They didn't find anything that could be related to the fires I'm charged with. But I think the very fact that they were able to access hard drives encrypted with supposedly unbreakable software should be made as widely known as possible.

This clearly hints at an evil maid attack, which we always knew were a real risk when it comes to full disk encryption.

- recovering the key from a deleted file, ram, or other caches.

- obtained key or bytes thereof by prior surveillance. (so many ways)

- a forensics company could be sitting on a LUKS zero-day the way certain companies sit on Signal and iPhone vulns and use them on behalf of state actors.

- exploited a deprecated version themselves with an implementation error.

- prisoner had a short key because he used it so often

- brute force using generated wordlists from surveillance and data transcripts.

- trained a GPT model on all the books, music and online forum posts the prisoner had ever bought and used and produced a weighted wordlist. (I just made that one up.)

- Happen to have "millions of dollars in gpu time" because they already had racks of seized mining rigs from other investigations so the main cost was electricity.

Being an anarchist or secret police in France just seems like participation in their national traditions of riot sports, intrigue, and feats of mysterious intellectual prowess. There are so many unanswered questions in the story, I will wait for the Wes Anderson adaptation before thinking about it again.

https://news.ycombinator.com/item?id=35611425 "PSA: Upgrade your LUKS key derivation function" (>180 comments)

And this letter's authenticity was verified how?

Even if authentic, it could be the result of coercion, to create a bluff and spook some other activists.

Or it could be that the cops fooled the activist into believing that they cracked his hard drive, so that he then wrote the letter.

Do not believe everything "posted to the Internet".

The letter says (DeepL translation) that "There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted)."

Files and e-mails come from somewhere. If I know that you downloaded certain files or e-mails from a mail server to your encrypted hard drive, I could claim that I decrypted them from your drive and spook you.

It should really read "An arsonist imprisoned in France".

Here are projects which try to mitigate some of evil maid attack risks:

https://github.com/noahbliss/mortar

https://safeboot.dev/

When I setup FDE with LUKS on my Ubuntu laptop I had to go the manual route since I noticed that the default iteration counts don't make any sense, and it was so incredibly difficult to change them, pages upon pages of instructions.

Anyone has any insight why the state of FDE is so bad on Linux? Nobody uses it?

Bitlocker can save backup keys in the cloud where they can probably be subpoenad by the police. If the victim used a password manager without encryption (e.g. browser) and used or saved the same password somewhere else, they might have gotten it this way.

I mean: attacker shall have a bazillion RAM and a trizillion GPUs... Fine. I augment the number of iterations by 1024, there, it's brute-force attacking cost just rose by 1024.

(I'm not sure that person was attacked by bruteforce but I'm surprised it's always left out... And now I've got friends sending me that picture with "time needed to brute-force a password if it has x, y or z characters" and I don't know what to answer except that "it's more complicated than that picture which circulates everywhere)

There is a faction out there that claims that Argon2 is not as good as cache hard functions for the case where the user is only going to be willing to wait second or less. That's a reasonable assumption so it would probably be a good idea to evaluate more than just Argon2 for any particular application. Yes I know that Argon2 won a contest, but such contests are followed by a much longer evaluation period.

>Brute force attacks became not just faster, but much smarter as well. The user’s existing passwords are an excellent starting point. These passwords can be pulled from the user’s Google Account, macOS, iOS or iCloud keychain, Microsoft Account, or simply extracted from the user’s computer. The user’s existing passwords give a hint at what character groups are likely used:

So if the victim used portions of that "longer than 20 characters" password in their other passwords, the amount of work required to crack the LUKS password would be much reduced.

Why can't programs like Hashcat treat virtual memory (which is just disk space) as "on board memory", and then get 1000 attempts out of each TB?

I would think the calculations themselves are relatively minor, if you are using that amount of RAM.

Then with that password they can evil maid again and change your boot partition. (unless you have same password on root/boot or password is embedded in boot partition in which case win for attacker)

You could detect evil maid if you add a script that does a hash over grub used to load with a salt from boot sector, show on screen for user to decide against memorised hash...

Prevent perhaps secure boot with custom keys?, but then that's one more layer. And you could probably use secure boot to avoid boot partition encryption entirely.

On windows the default way it's set up when you have a TPM though is that it locks the decryption keys against a hash of all of the code that has run during the boot process.

FDE works fine with encrypted boot, it's just not the default for Ubuntu. I just ticked the "encrypt my install" box as far as I know, I only found out that my /boot wasn't encrypted after the fact.

For evil maid attacks, encrypting /boot or not shouldn't really matter unless there's a known exploit for your bootloader. IMO it doesn't matter much because before you can decrypt the main drive, you'll have to deal with either a rewriteable boot sector, a rewriteable EFI:/boot/grub, or a rewriteable /boot. Each step should verify the hashes of the next loader and of any of the loaded modules, so an attacker would need to inject themselves into your boot process before the verification chain can start. You need to keep secure boot on, though.

Setting this up right involves enrolling keys into your UEFI (every time the bootloader updates), securing your UEFI with a good password, and assuring nobody can reflash your motherboard firmware somehow. All of that isn't necessary if you trust that Microsoft's keys don't leak and if you use the pre-signed shims, but that approach tends to break kernel modules (i.e. when you use Nvidia's driver).

Microsoft can get around this problem because their root keys are preloaded into almost every secure boot capable device you can find. They can pre-sign a bootloader and distribute it to hundreds of millions of computers, whereas every Linux distro has to jump through hoops and use the Microsoft-signed loader as an inbetween stage or have the user set up their own keys and signature system.

Then there's the challenge of TPMs. Windows uses the TPM to verify nothing has changed or demand a recovery key, and can use TPM+PIN to unlock a Bitlocker partition. On Linux, there is a wide variety of tools, but as far as I can tell, you can only choose between "unlock the disk from the TPM" or "unlock the disk with your passphrase". I suppose it's possible to set up a multi stage boot process in which initramfs is loaded from a TPM-based key and the main system is decrypted using a password, but I'm not aware of any easy to use installers for that purpose. I find proper GUI support for TPM configuration sorely lacking compared to other operating systems.

The iteration count LUKS defaults to depends on your CPU's performance. By default, LUKS takes 1000ms (or 2000ms in modern versions) of hashing to determine the amount of iterations. I can definitely see why, because at some point I put my iterations up to 10 seconds and the preboot environment, lacking the necessary acceleration instructions, took forever to unlock the disk. Anyone trying out encryption on their new install would probably wipe and retry without encryption with those parameters, which is obviously worse.

Getting secure boot set up right is the biggest challenge in my experience. The tools are all there, but there's no real GUI for configuring any of this and with how many Linux enthusiasts will decree that secure boot is Microsoft conspiracy and TPMs are instruments of the devil, I'm not sure that'll change any time soon.

Furthermore, the article talks about LUKS, which is decidedly not related to Bitlocker.

I doubt they would've spent the ridiculous amount of money you need to crack LUKS though. Most likely, the password was a phrase that could be brute forced through a dictionary attack, or it was reused somewhere else.

That's not to say we shouldn't move to Argon2i as GPU performance increases over time. Argon is proven to be stronger and there's very little reason not to upgrade if you can get your bootloader to unlock the modern LUKS standard (i.e. not GRUB).

Besides, the user also had a Windows laptop encrypted with Bitlocker, and the police failed to crack that one (see top comment).

For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U (Q3'18) CPU, that seems to result in an iteration count on the order of 1.8M. Assuming the RTX 4090 hashcat benchmarks [4] scale linearly on the iteration count, that's about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256.

In terms of brute-force vs password entropy, that would give you roughly 45 bits of entropy for 1k gpu-months, or ~250k gpu-years to net 56 bits of entropy. Those would be on the order of [a-z0-9]{8} (41 bits), [a-zA-Z0-9]{8} (47 bits) or [a-z]{12} (56 bits).

Worryingly close enough to make replacing the KDF a relevant concern, but still enough to make this story about brute-forcing a random 20-character password somewhat implausible, unless the password was far weaker than implied.

[1] https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...

>LUKS varies the number of hash iterations used to protect the master encryption key. When creating an encrypted disk with a given combination of encryption settings, LUKS benchmarks the user’s system. The data is used to select the number of hash iterations protecting the master encryption key.