View Issue Details

IDProjectCategoryView StatusLast Update
0005373Kali LinuxFeature Requestspublic2020-12-01 10:48
Reporterrhertzog Assigned Torhertzog  
Status resolvedResolutionfixed 
Product Version2019.1 
Fixed in Version2019.3 
Summary0005373: Replace cryptsetup nuke passphrase with a dedicated system service

The feature described in relies on a custom C patch of cryptsetup that we are carrying and updating over time. Maintaining this patch can be very hard at times. Right now, I have spent more than a day to try to implement the feature for the luks2 format which is the new default format used by cryptsetup 2.1.0 and I'm not done yet.

To avoid this regular work, I wanted to work with upstream on this feature and get it merged. Thus I opened and I got a clear answer that this was not going to be merged in any form. But upstream also suggested that we should create some system service calling "cryptsetup luksErase" to provide the same feature. This ticket is about this idea.

Additional Information

I believe that this is a good idea and that we should pursue it. If the "nuke password" use case is mainly a quick & easy way to wipe everything on early boot, then we can imagine extending the initramfs with a hook that would scan the kernel command line for "cryptsetup-nuke=yes" and that would erase the luks header in that case... we could even add a new grub menu entry in the advanced menu to make it more accessible (with a "cryptsetup-nuke=ask" parameter that would require an explicit confirmation before erasing anything to avoid accidental selection of the menu entry). However we would loose the authentication brought by the nuke password since anyone with access to the machine could wipe the luks header (but I guess as soon as anyone is in a position to access the machine and reboot it, he can destroy it in many other ways).

Such a feature can be implemented in an entirely separate kali-specific package and it would be easier to maintain over time. Opinions ?




2019-03-29 14:40

reporter   ~0010458

It seems that creating an advanced grub menu entry is the only practical way to do this going forward. The nuke feature, while cool, has a pretty limited use-case so I don't think it's worth the effort of you fighting with it.



2019-04-19 11:37

reporter   ~0010527

I'd like not to lose this function.
It's really unique, I did not meet the one in any other distributive. I use it in my daily routine and I know it very well.



2019-06-14 19:35

administrator   ~0010695

So I created "cryptsetup-nuke-password" as a separate package hijacking the cryptsetup password prompt in the initramfs. That will let us switch to an unmodified cryptsetup.

See for details.

The new cryptsetup and the new cryptsetup-nuke-password package are both in kali-experimental. Feel free to test them.

I wonder what else needs to happen before I can move them to kali-dev... I guess we want to update and the sidebar in the book (cf end of

Do we want to modify cryptsetup so that luksAddNuke prints an informative error message directing users to the new package ?



2019-06-25 09:51

administrator   ~0010738

I updated cryptsetup 2.1.0-5kali1 in kali-experimental to print a warning:
$ cryptsetup luksAddNuke foobar
ERROR: 'cryptsetup luksAddNuke' is deprecated.
Instead use the feature provided by the cryptsetup-nuke-password package:
sudo apt install cryptsetup-nuke-password
sudo dpkg-reconfigure cryptsetup-nuke-password

And the package has a recommends on cryptsetup-nuke-password. cryptsetup-nuke-password is now in kali-rolling as well.



2019-06-25 12:03

administrator   ~0010741

Kali Revealed book updated with commit a5fe5bd88d9e04a070ba38d40f16260799703777 and asked digip to update its online copy.

Now on the website, there are at least two articles that need to be updated to document the new cryptsetup-nuke-password feature:



2019-07-08 14:38

administrator   ~0010769

The websites have been updated, the packages have been pushed to kali-rolling. Nothing left to do here.

Issue History

Date Modified Username Field Change
2019-03-29 10:19 rhertzog New Issue
2019-03-29 10:19 rhertzog Status new => assigned
2019-03-29 10:19 rhertzog Assigned To => rhertzog
2019-03-29 10:37 rhertzog Description Updated
2019-03-29 14:40 dookie Note Added: 0010458
2019-04-19 11:37 Dober Note Added: 0010527
2019-06-14 19:35 rhertzog Note Added: 0010695
2019-06-25 09:51 rhertzog Note Added: 0010738
2019-06-25 12:03 rhertzog Note Added: 0010741
2019-07-08 14:38 rhertzog Status assigned => resolved
2019-07-08 14:38 rhertzog Resolution open => fixed
2019-07-08 14:38 rhertzog Fixed in Version => 2019.3
2019-07-08 14:38 rhertzog Note Added: 0010769
2020-12-01 10:48 g0tmi1k Priority high => normal