31

I tried removing LUKS encryption on my home directory using the following command:

cryptsetup luksRemoveKey /dev/mapper/luks-3fd5-235-26-2625-2456f-4353fgdgd

But it gives me an error saying:

Device /dev/mapper/luks-3fd5-235-26-2625-2456f-4353fgdgd is not a valid LUKS device.

Puzzled, I tried the following:

cryptsetup status luks-3fd5-235-26-2625-2456f-4353fgdgd

And it says:

/dev/mapper/luks-3fd5-235-26-2625-2456f-4353fgdgd is active and is in use.
type: LUKS1
cipher: ...

It seems the encrypted device is active, but not valid. What could be wrong here?

1
  • 5
    WARNING the command op tried will wipe the volume if it its written correctly and there is only one passphrase. see man cryptsetup under luksRemoveKey the command revokes the password, at does not remove encryption. Commented Dec 12, 2020 at 15:50

5 Answers 5

25

ANSWER FROM 2013 - See other answers for happy times

  • Backup
  • Reformat
  • Restore

cryptsetup luksRemoveKey would only remove an encryption key if you had more than one. The encryption would still be there.

The Fedora Installation_Guide Section C.5.3 explains how luksRemoveKey works.

That it's "impossible" to remove the encryption while keeping the contents is just an educated guess. I base that on two things:

  • Because the LUKS container has a filesystem or LVM or whatever on top of it, just removing the encryption layer would require knowledge of the meaning of the data stored on top of it, which simply is not available. Also, a requirement would be that overwriting a part of the LUKS volume with its decrypted counterpart, would not break the rest of the LUKS content, and I'm not sure if that can be done.
  • Implementing it would solve a problem that is about as far away from the purpose of LUKS as you can get, and I find it very unlikely that someone would take the time to do that instead of something more "meaningful".
3
  • How did you know that? Any references? Commented Jan 11, 2013 at 15:34
  • Added reference to Fedora Installation Guide and why I believe backup-restore is the only option for going from full-disk-encryption to no-encryption.
    – MattBianco
    Commented Jan 11, 2013 at 16:07
  • 1
    this was probably correct when written - other answers more relevant now
    – SwiftD
    Commented Apr 6, 2022 at 17:04
22

Removing key-slots is like forgetting a password, it has nothing to do with moving the replacing the LUKS device by the filesytem inside of it.

You CAN non-destructively remove the LUKS encryption from a device, without having to backup, reformat and restore. cryptsetup has supported this since version 1.5.0, released in 2012.

After succesful decryption of a LUKS device, the filesystem inside becomes available to the OS, and you can mount it directly.

Warning: This is dangerous, backup all your data first.

For LUKS1:

  1. Boot from a USB key
  2. Use
    cryptsetup-reencrypt --decrypt <device_path>
    

For LUKS2:

  1. Boot from a USB key
  2. Convert all key-slots to use LUKS1 compatible parameters with
    cryptsetup luksChangeKey  --pbkdf pbkdf2 <device_path>
    
  3. Convert the LUKS2 device to a LUKS1 device using
    cryptsetup convert --type luks1 <device_path>
    
  4. Perform the decryption using
    cryptsetup-reencrypt --decrypt <device_path>
    

I've tested both of these and they work.


Current versions of cryptsetup claim to support direct decryption of LUKS2 devices. The command is

cryptsetup --reencrypt --decrypt --header HEADER_FILE <device_path>

The --header argument is required, because the commands assumes your device uses a detached header. If you do, it works, and can even do the decryption online. If you don't use a detached header (quite common), and you try to either provide a dump of the header, or passing the block device itself as the --header value, cryptsetup will quietly proceed and when it finishes, you'll end up with a LUKS2 device which has no key-slots and your data will be gone.

This is as of version 2.3.3 (2020), it may change in future versions.

My recommendation is to use the safer LUKS2->LUKS1->Decrypt path, which I can confirm does the job.

4
  • 3
    This was fantastic. Thank you! I want to add a little. After doing this on a CentOS system (RH probably similiar) you must take a few more steps to allow it to boot (assuming it was a boot partition). Boot from a Install Media, and Rescue the system. chroot in the system /mnt/sysroot. remove /etc/crypttab. Edit /etc/default/grub and remove the luks portion. Regenerate the grub config: grub2-mkconfig -o /etc/efi/EFI/centos/grub.cfg Reinstall grub. yum reinstall grub2-efi (This part was a little tricky, without internet access, but there is a package repo on the recovery disk)
    – jagauthier
    Commented Jan 29, 2021 at 18:42
  • Note for me, after I did steps 2 and 3 above (under "for LUKS2") I had to reboot to avoid issues like this: Attaching loopback device failed (loop device with autoclear flag is required) Commented Dec 7, 2022 at 13:45
  • You may add to your post to use lsblk --fs to figure out what is the <device_path> to decrypt
    – smartmouse
    Commented Jul 5, 2023 at 10:00
  • How do I determine which LUKS version is in play?
    – a coder
    Commented Jan 4 at 18:53
17

Firstly, when removing a passphrase from a LUKS partition, you need to specify the disk partition where it resides, like:

cryptsetup luksRemoveKey /dev/sda2

And when you want the status from a LUKS-encrypted device, you need to refer to the LUKS-name, as you did.

But luksRemoveKey only removes one of the passphrases (and never the last one). If you want to permanently decrypt, you have to use cryptsetup-reencrypt:

cryptsetup-reencrypt --decrypt /dev/sda2
1
  • 1
    FWIW, for LUKS 2 devices cryptsetup has a reencrypt subcommand. Commented May 4, 2020 at 20:21
1

The following worked for me for LUKS2:

sudo cryptsetup   reencrypt /dev/sdf1 --decrypt --header HEADER_FILE

However:

sudo cryptsetup --reencrypt           --decrypt --header HEADER_FILE /dev/sdf1

(with the <device_path> last, as shown in Chen She’s answer) did not.

2
  • Please explain exactly what you mean by “did not work”.  Did it give an error message?  (If so, what was it?)  Did it damage your disk?      Please do not respond in comments; edit your answer to make it clearer and more complete. Commented Jun 23 at 18:20
  • correct thanks for editing, it does not like the --reencrypt but instead reencrypt, plus the drive to be decrypted Commented Jul 10 at 13:26
0

Adding to Chen She's answer, the default cryptsetup package with Ubuntu18.04 is 2.0.2 has a bug which exits the decryption command with return code 1, if the first active keyslot for Luksformatted device is not zero (ref here) But it has been patched, as the next comment in the attached forum link mentions.

So, you might need to build from the source from gitlab in order for it to work with your encrypted system. Mind it, as of release 2.6.0 the command to decrypt a device has changed to cryptsetup reencrypt <device-name> --decrypt

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .