Is there a way to set a custom passwd to initiate a luks header shred? I saw something similar by offensive sec.
Many problems that people have in Qubes are actually not Qubes specific.
This is one of those.
You can find guides online to help you do this - but if you are in state
which requires you to enter a password, then entering a password which
renders the drives unreadable will undoubtedly leave you open to criminal
charges.
Back then, kali linux is providing patch that would permit the user to type a special [duress password] when decrypting the drive on-boot. When entered, this duress password would wipe (nuke) the encrypted drive where Kali was installed.
But it never merged to cryptsetup, and some years ago it was requested and rejected again by crypsetup team.
The dev said This issue was discussed many times. The luksErase command was the final decision, there will be no other internal mechanism to autowipe header, sorry.
Just go with detach header.
1 Like
Recently, ParrotOS released an update we if provide the nuke password the drive gets wiped.
Can this also be implemented in qubesos? I tried but cryptsetup doesn’t have nuke option command like kali or parrot os
not sure it’s up to dev, but you can say nope. if you like, you could just install the cryptsetup-nuke-password and find how to make it work in fedora.
…or in some cases, bodily harm, neither of which are very pleasant…
There have been quite a few discussions about this on this forum. The closest thing that could actually be somewhat useful in certain situations is a duress password that causes your machine to boot into a decoy OS. There is potential for sys-gui to serve this function.
The only situation where booting into a decoy OS is useful is where you’d need to “show your laptop” to someone who would then inspect it without any proper tools, such as a partner who think you’ve been unfaithful, a school teacher, or a really dumb border agent.
Honestly, a duress password that shreds your headers may sound cool, but think about it in practice.
A duress password to shred your header making your drive unable to be decrypted (easily, unless you have access to the NASA supercomputer for ~15 years) requires you to use your patched version of cryptsetup for the duress password to work.
The drive isn’t the thing that recognises the duress password, it’s the cryptsetup binary. So it’s completely useless if they mount your drive on another machine.
If someone wants your data, and knows what they’re doing, let me explain what they do. First, they take your laptop and image all drives, so they have a full backup. On their own machine, they then mount the image in RAM (they’ll have a machine with enough RAM) and start analysing it and bruteforcing it, using their own version of cryptsetup (or maybe even their own custom tool).
Then, they bring the laptop to you, put it in front of you and tell you to unlock it.
What are you going to do then?
Even if you type in your duress password and shred your headers in front of them, they’ll have a backup anyway.
And now you’ve made them angry. 
If they’re law enforcement, expect them to ask for a harsher sentence (and a court would probably wouldn’t hesitate in giving it).
If they’re the other kind of people who pressure you to unlock your laptop, well, you just destroyed the one thing keeping you alive… 
@51lieal is right. I would probably go with this option if you’re looking for something extra for your Qubes OS install. It’s more practical. Your headers aren’t with your encrypted drive to begin with, so you’ve got partial plausible deniability.
You can then make an encrypted backup of the headers and stash it somewhere, if you need to.
But, if you still wish to try to build it yourself and install it, here are the kali patches:
And here are the cryptsetup 2 patches:
Just do it on a Qubes OS install that you’re prepared to bork. I don’t want you to lose anything important without a valid reason 
1 Like