cryptsetup VS sedutil

Overall, “dm-crypt” is a device-mapper target (https://elixir.bootlin.com/linux/v6.5-rc3/source/drivers/md/dm-crypt.c#L3689) supported from kernel version 2.6.4 (https://elixir.bootlin.com/linux/v2.6.4/source/drivers/md/dm-crypt.c). It is responsible for transparent (aka real-time/on-the-fly encryption) block device encryption while using the kernel crypto API (https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt) .

For more information check section 5.21 Why is there no "Nuke-Option"? of LUKS FAQ.

Please read the section 5.21 Why is there no "Nuke-Option"? of the LUKS FAQ for more information (eg. when a "wipe" option could actually harm you).

Check out the section 5.2 and 5.18 of the LUKS FAQ for more information.

See section 5.2 of LUKS FAQ and Key disclosure law all over the world.

References: - Frequently Asked Questions Cryptsetup/LUKS - Question 2.15: "neither dm-crypt nor LUKS1 stores partition size and LUKS2 uses a generic "whole device" size as default." - Stackexchange: What does cryptsetup resize do if LUKS doesn't store partition size?

LUKS is probably what you want

I'm afraid I can only set my level1 password, that's used to decrypt the actual level2 password stored somewhere on the drive. But I don't influence the level2 password, that's probably assigned by the manufacturer? Docs are ambigous on that.

I am trying to repurpose old laptop for backup of a server. Currently this is being done by PINE64 with 5x2.5' Seagate disks attached via usb. This backup runs once per week and stores latest ZFS snapshots using syncoid. The main server used Seagate EXOS x18 16TB SATA SED with active SED encryption (https://github.com/Drive-Trust-Alliance/sedutil ) and no ZFS encryption and the backup servers use ZFS encryption.

If you received encrypted drives, you'll also have to snag sedutil. The Github wiki page has good usage instructions (note the PSID revert page in particular). The package is also available in the AUR, so if you find yourself needing to live boot something just for this task Arch-based is pretty straightforward.

After more research I think everything I want is available in sedutil's Pre-Boot Authentication including unlocking multiple drives with the same password. I'm going to try it when all my parts arrive and hopefully report back findings and benchmarks in a month if anyone is interested.

Sedutil seems not to work on Ryzen 6000-Laptops as the Slim Pro X, as the keyboard is not detected due to the old kernel in the rescue image. Known Issue: https://github.com/Drive-Trust-Alliance/sedutil/issues/422

The article is saying that people don't unlock their devices before recycling them.

This could be true, but as I mentioned in another comment, as soon as it's removed from the original users iCloud account that lock will be removed.

> how can you trust that the "erase everything" works?

You can't remove it, but as long as nobody else can use the device to recover data then it's fine.

FWIW it's actually pretty easy with SATA SSD's to set a device key, which then encrypts everything on the drive at full speed: https://github.com/Drive-Trust-Alliance/sedutil

The drives are actually already doing this, it's just that the key is set to 0's.

I can imagine that, given the drive is accessed via T2, that Apples NANDS are being accessed the same way, in which case scrambling the key is enough to make it unrecoverable permanently.

LUKS doesn't support the OPAL standard that these drives use, and the only utility I found that does is this one, and it seems like it only works with legacy BIOS. Even if you could use it, I'm not sure it's a good idea. If you CPU supports AES instructions there shouldn't be a performance difference and as far as encryption is concerned an opaque firmware blob on a flash controller is about the last thing I'd trust with keeping my data secure.