WTF is a KDF?

The number comes from this mastodon post, which is cited in the original article:

https://kolektiva.social/@cedar/110214532879538171

> This enemy site talks about using up to 10,000 computers with GPU acceleration to attack a LUKS password:

> https://blog.elcomsoft.com/2020/08/breaking-luks-encryption/

There, it says:

> Up to 10,000 computers and on-demand cloud instances can be used to attack a single password with Elcomsoft Distributed Password Recovery.

So this is the theoretical maximum of some service.

We should not be under the impression that the hard drive of the activist in question has been attacked with 10,000 GPUs.

It really annoys me how everyone takes that statement that a 20 character password has been cracked at face value. If it was randomly generated, it is physically impossible to crack even if it was hashed with MD5. It's also unlikely that somebody memorized 20 random characters. It is much more likely that the passphrase was weak because it's the title of a Wikipedia article or contained in some public word list.

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.

What I find weird is that not many talk about one of the parameter to PBKDF2, c, the number of iterations desired. Someone here mentioned it a few days ago: just make decryption fast enough to be acceptable for you but still a big multiplier compared to the default. What do people care, when unlocking their SSD, if it takes 3ms or 300ms to unlock the SSD at boot?

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)

I would bet on '1'. That's the one that requires the least imagination.

Even if you encrypt boot partition someone could modify grub to grab password for boot partition used there.

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.