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.
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
