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

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 interrogator 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]>
>