4

I have an old computer that I'm ready to get rid of that has been encrypted using LUKS full disk encryption. Is it possible to delete the encryption key from the LUKS metadata so that nobody will ever be able to unlock the partition again? If so, how do I go about doing that?

4
  • You could boot from a USB (Live CD) and run dd if=/dev/urandom of=/dev/sda bs=1M or something similar. Feb 5, 2016 at 23:49
  • 1
    Possible duplicate of Securely erase hard drive using the Disk Utility Feb 5, 2016 at 23:49
  • If the passphrase is secure then so is the data... but that doesn't prevent guessing it, so changing & wiping is a good idea (sounds almost like a punchline ;-)
    – Xen2050
    Feb 5, 2016 at 23:49
  • @CharlesGreen overwriting the whole drive is way overkill for LUKS, I'll post an answer...
    – Xen2050
    Feb 5, 2016 at 23:59

1 Answer 1

3

Just overwriting the LUKS header will work, overwriting the whole drive is way overkill for LUKS & would take possibly hours longer.

The LUKS header could be 1MB or 2MB or bigger depending on the type & number of keys, ArchWiki advises to wipe/overwrite the first 10MB:

dd if=/dev/urandom of=/dev/sdx2 bs=512 count=20480

Note the correct partition sdx2 or whatever it is, you can check with a live dvd/usb and lsblk or blkid and confirm with the cryptsetup command below, this will tell you if partition sdx5 for example is a LUKS device:

cryptsetup -v isLuks /dev/sdx5

Also from ArchWiki:

Note: It is crucial to write to the LUKS encrypted partition ( /dev/sdx5 in this example) and not directly to the disks device node. If you did set up encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID then write to RAID respectively.

You could only (or additionally) delete all the luks keyslots, leaving no keys, if you know a working passphrase. See man cryptsetup or a web version here, with:

cryptsetup -v luksRemoveKey <device>

or

cryptsetup -v luksKillSlot <device> <key slot number>

Also note about SSDs (also from ArchWiki):

When wiping the header with random data everything left on the device is encrypted data. An exception to this may occur for an SSD, because of cache blocks SSDs employ. In theory it may happen that the header was cached in these some time before and that copy may consequently be still available after wiping the original header. For strong security concerns, a secure ATA erase of the SSD should be done (procedure please see the cryptsetup FAQ 5.19 ).

0

You must log in to answer this question.

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