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

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

[techmetx11]

After seeing GrapheneOS's implementation of the same design idea, I feel
like this idea wasn't given much thought in the FAQ.

> While this sounds attractive at first glance, it does not make sense
> once a real security analysis is done.  One problem is that you have to
> have some kind of HSM (Hardware Security Module) in order to implement
> it securely.  In the movies, a HSM starts to smoke and melt once the
> Nuke-Option has been activated.  In actual reality, it just wipes some
> battery-backed RAM cells.  A proper HSM costs something like
> 20'000...100'000 EUR/USD and there a Nuke-Option may make some sense.
> BTW, a chipcard or a TPM is not a HSM, although some vendors are
> promoting that myth.

This paragraph ignores the fact that the TPMs that come with computers
have improved on-par to the standard of HSMs, and are now integrated
straight in the CPU in most cases, rather than being a seperate chip or
card that can be simply bus-probed or manipulated physically.

> Now think of the typical LUKS application scenario, i.e.  disk
> encryption.  Usually the ones forcing you to hand over your password
> will have access to the disk as well, and, if they have any real
> suspicion, they will mirror your disk before entering anything supplied
> by you.  This neatly negates any Nuke-Option.  If they have no suspicion
> (just harassing people that cross some border for example), the
> Nuke-Option would work, but see above about likely negative consequences
> and remember that a Nuke-Option may not work reliably on SSD and hybrid
> drives anyways.

Disk mirroring is a valid concern, but can be fixed by having layered
configurations, such as: having a outer configuration that decrypts the
inner configuration.
The outer configuration can have keyslots for the hardware security
chips, to decrypt the inner configuration (which includes the keyslot
parameters for the duress password and the normal password, and other
LUKS parameters). Not only does this make it so that wiping the
HSM/TPM/etc. permanently destroys any chance of decrypting the inner
configuration and thus the rest of the hard drive, this may also make it
hard to determine if the hard drive is "booby-trapped" just from reading
the LUKS header.

Why was not such a design considered for this kind of setup? (if it wasn't
due to complexity). Computers have advanced so far after
(persumably) this FAQ entry was written

> Still, if you have a good use-case (i.e.  non-abstract real-world
> situation) where a Nuke-Option would actually be beneficial, please let
> me know.

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)

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

[techmetx11]

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. >.<-.+++++><chris@xed.ch>

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

[techmetx11]

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 <techmetx11@disroot.org> 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. >.<-.+++++><chris@xed.ch>
> >
> 
> -- 
> Sent from my Android device.

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

[Kurt Fitzner]

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 
<techmetx11@disroot.org> 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. >.<-.+++++><chris@xed.ch>
> 

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

[Milan Broz]

On 11/6/25 3:38 PM, techmetx11 wrote:
> The outer configuration can have keyslots for the hardware security
> chips, to decrypt the inner configuration (which includes the keyslot
> parameters for the duress password and the normal password, and other
> LUKS parameters). Not only does this make it so that wiping the
> HSM/TPM/etc. permanently destroys any chance of decrypting the inner
> configuration and thus the rest of the hard drive, this may also make it
> hard to determine if the hard drive is "booby-trapped" just from reading
> the LUKS header.
> 
> Why was not such a design considered for this kind of setup? (if it wasn't
> due to complexity). Computers have advanced so far after
> (persumably) this FAQ entry was written

Cryptsetup never communicates directly with TPM or HSM; it only provides
space for storing metadata through LUKS2.

Integration with TPM is handled in systemd-cryptsetup; it is not part
of the cryptsetup project, but rather a subsystem within systemd.

Moreover, such data-destruction options are not user-friendly; there will
be many users who do not understand the concept and will wipe data by mistake.

If you want it, you can easily implement it through some external tool.

The nuke option will never be supported directly by libcryptsetup.
If you disagree, do not use LUKS. It is your choice.

Milan

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

[Arno Wagner]

On Thu, Nov 06, 2025 at 15:38:06 CET, techmetx11 wrote:
> After seeing GrapheneOS's implementation of the same design idea, I feel
> like this idea wasn't given much thought in the FAQ.
 
You feel incorrectly. This has been extensively discussed. 
 
> This paragraph ignores the fact that the TPMs that come with computers
> have improved on-par to the standard of HSMs, and are now integrated
> straight in the CPU in most cases, rather than being a seperate chip or
> card that can be simply bus-probed or manipulated physically.

They really have not. Not even remotely. 
 
> > Still, if you have a good use-case (i.e.  non-abstract real-world
> > situation) where a Nuke-Option would actually be beneficial, please let
> > me know.
> 
> 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)

This senario has been discussed here many times. It is not a 
valid reason to have a nuke option. Also note the cryptsetup
has no TPM integration as part of the project.  

Regards,
Arno Wagner

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier