Re: Question about FAQ 5.21: "Why is there no "Nuke-Option"?"

Again, no one will try and bruteforce using the software on the device,
but if you employ TPM and such, and tie the decryption to the secret
stored within the TPM, they have no other choice but to bruteforce it on
the device.

You can look at Android phones, they may not be perfect. but some like
GrapheneOS has been pretty robust against law enforcement and forensics
companies trying to crack the phone open

Modern computers, especially the CPUs themselves have already had many,
many security mechanisms built-in to counteract most of what you said
(other than putting a camera watching your keyboard), such as Intel
TME (Total Memory Encryption) that transparently decrypts/encrypts
memory as it reads and writes to the RAM, sandboxes and Secure Boot to
protect against malicious code being ran

If this is considered out of scope in LUKS, then fine. I can't argue
much about that

On Thu, Nov 06, 2025 at 04:47:38PM +0000, Kurt Fitzner wrote:
> Nuke options are mommy medicine.  They rely on:
> 1a) the ignorance of the adversary to their presence and
> 1b) the adversary not taking the most basic precautions
> Or
> 2) External hardware or mechanisms to enforce.
> 
> In either case they are beyond the scope of DM-CRYPT / LUKS.  Any implementation in LUKS would do more harm than good, either giving the user a false sense of security, or in inadvertent activations.
> 
> If your threat model anticipates torture and in spending your life to protect the secrets on your hard drive, then LUKS is not for you.
> 
> And no one, literally no one, will try and brute force a password using the software ON the device.
> 
> You can already accomplish almost all the same  goals using simple methods.  Get yourself a frangible USB stick.  Or a small USB microsd reader and physically score the card to render it easily snapped.  There are even hackaday projects to make USB sticks with buttons that dump a fatal shock into the electronics.  Put your storage device key file on that device and retain it on your person.
> 
> I will also add that your threat model is naive and implausible.  No one who wants your data that bad will get your password with a bat.  They will put a camera watching your keyboard.  Or they will install a physical RAM grabber in your computer.  Or subvert the update process for some piece of software on your computer.  Or any one of a thousand different variations.  And in the remotest chance your threat scenario ever materialized, I promise you a trained interogator will know when you're trying to feed them a fake password before your conscious brain even gets the handoff and the idea percolates to your forebrain.
> 
> Lastly, I will add that if such threat models as you anticipate exist, then such measures as nuke options are then more of a danger to others than they are useful to you.  Do you really want to make it impossible for any person who doesn't actually employ a nuke password to be trusted to give the password?
> 
> LUKS does not address any of this nor should it.
> 
> On November 6, 2025 3:46:51 p.m. UTC, techmetx11 <[email protected]> wrote:
> >Yes, that is what would happen if computers didn't come with a
> >integrated cryptoprocessor to store secrets or something like TPM2, but
> >computers do come with that now.
> >You could require a secret stored in it as apart of the process of
> >unlocking the drive, either deriving a key from both parameters (the
> >key-derived password and the secret in TPM) or having the TPM secret
> >decrypt the configuration that stores the password hash and parameters
> >
> >Since you can't easily mirror data from a TPM chip, especially if it's
> >integrated deep into the CPU, wiping it would render the contents on the
> >drive useless even if they mirrored it beforehand
> >
> >On Thu, Nov 06, 2025 at 10:34:26AM -0500, Chris X Edwards wrote:
> >> I don't really have any true expertise to comment publicly but how
> >> about this:
> >> 
> >> You have an encrypted drive with important stuff on it. There are two
> >> passwords, one is "?LR3*F%@hdQa7Db3d=L7&A27LQ%aAd3aA@?H?adL" and this
> >> unlocks the drive. The other password is "mypassword" and it nukes it.
> >> Simple brute force attempts will be hindered. Though if they're smart,
> >> they are mirroring.
> >> 
> >> Maybe I'm overlooking something. There's always something!
> >> Good luck,
> >> Chris
> >> 
> >> On 2025-11-06 15:38 +0100, techmetx11 wrote:
> >> > Imagine if you were being tortured by people to unlock a hard drive that
> >> > you didn't want them to see the contents of, and so you give them the
> >> > password to hopefully make it so that it wipes the TPM/HSM/etc. of the
> >> > computer and destroy any chance of unlocking the contents, thus making
> >> > their job futile and saving information from ending up on your
> >> > adversaries' hands (even if it meant it cost you your life)
> >> 
> >> -- 
> >> ++++++++++[>++++++++++++<-]>-...<++++++[>>+++++++<<-]>>++++.<+.<++++[>
> >> Chris X Edwards-----<-]>+.- Have a nice day. >.<-.+++++><[email protected]>
> >
> 
> -- 
> Sent from my Android device.