Is there a possibility to make Linux install automatically delete the data if wrong decryption key is set x amount of times?
Would be nice too, if it started automatically to overwrite the data too even full disk overwrite takes a lots of time.
I tried to google docs, but I don’t know the right words.
You have no control over how an adversary accesses the drive, so no.
However, if it’s enough to erase the data if wrong key is entered AND the original operating system is running it should be possible. But I agree, that limitation doesn’t really make sense in a security point of view.
Besides that, I believe that luks encryption with sufficiently complex password (and updates) is practically the same than empty drive for the attacker. More interesting setup would be to give out different data depending on which key is given, there was some windows-based software which could do that back in the day, I’m not sure if it’s still around and don’t remember the name for it right now.
It would at least add a layer of obfuscation if someone extorts a key from the owner.
This is the correct answer. Your best bet is to simply make your encryption as strong as possible, because once an attacker gains access, they will be able to clone the encrypted data and access it in any way they choose. Any sort of interventions you put in place will only work on your machine.
That’s what I was thinking. If someone realllly wanted to break into your computer, they would take your storage device and brute force there. The decryption screen that shows on boot will probably prevent a brute force attack.
If the decryption key is unavailable, the data is as good as wiped already, right? It’s unreadable.
I’m guessing you’re attempting to mitigate against a brute force attack. I think the ‘stock’ answer to that would be to ensure you’re using a complicated enough pass phrase (I think the current best practice on this is >12 characters with the usual upper, lower, character, number combo can take thousands of years to crack, see here: https://www.security.org/how-secure-is-my-password/) or use a hardware token.
Doesn’t LUKS lock out any attempts for 60 seconds after 3 attempts anyway? That’s a huge blocker in the way for brute forcing. That’s 180 attempts in an hour, 4320 a day, etc. It’ll take a long time.
If you’re truly looking to wipe, I think you’d need to execute something at the OS level once unlocked/booted to detect incorrect attempts (if attempt >3; then dd if=/dev/zero of=/dev/YourDevice bs=2M or similar).
Have a look at response 5.21 on why LUKS does not include the nuke option: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
Doesn’t LUKS lock out any attempts for 60 seconds after 3 attempts anyway? That’s a huge blocker in the way for brute forcing. That’s 180 attempts in an hour, 4320 a day, etc. It’ll take a long time.
The prompt running on (many) distributions boot has a time limit, but if you pull the drive and plug it into another host (or boot from USB) the limitation doesn’t exist.
If you’re truly looking to wipe, I think you’d need to execute something at the OS level once unlocked/booted to detect incorrect attempts (if attempt >3; then dd if=/dev/zero of=/dev/YourDevice bs=2M or similar).
You could bake that into init scripts since the kernel is already running. On the same spot where the time delay triggers you could just wipe the drive instead of prompting to wait until receiving new password. But that still leaves the option to pull the drive physically into another host and do whatever you like with it since the wiping code on the drive wouldn’t/couldn’t execute.
good way to accidentally lose the data.
in case of any forensics your drive will be copied first and master will be not touched, any decryption attempts will be executed on copies - so kill switch is effectively useless.
deleted by creator
