V.23 | it/its | demi | machine | no minors! 🔞
British-Australian 🇬🇧🇦🇺 living in London!
Systems Engineer, worldbuilder & writer
all NSFW posts will have a content warning
| Pronouns | it/its |
| Gender | Machine |
| Matrix | @vertex:glassway.net |
https://www.youtube.com/watch?v=Tf_UjBMIzNo
launches in 5 minutes :3
Ok, I've done some research and I *think* I understand why
1. When the drive is locked the controller refuses to read or write to the locked regions, so it prevents attempts at forensic recovery of the LUKS ciphertext or the LUKS headers
2. It allows you to do a hardware crypto erase without the PSID
3. FIPS compliance or something, I guess?
1 is *incredibly* paranoid and 2 is pretty much moot since LUKS erases its own headers anyway when doing a wipe, but I guess it might technically be more effective to do a lower level erase of the controller's keys as well. But yeah, mostly inconsequential
just found out cryptsetup has a mode to use both LUKS and OPAL at the same time. the release notes say:
“TCG interface (SEDs - self-encrypting drives). Using hardware disk encryption is controversial as you must trust proprietary hardware. On the other side, using both software and hardware encryption layers increases the security margin by adding an additional layer of protection.”
…which makes sense, but if you don’t trust OPAL anyway, why have it as a point of failure? It’s true that it doesn’t cost anything to turn it on because OPAL drives already encrypt everything transparently but it seems rather redundant if you already inherently trust LUKS. maybe someone else can weigh in here?
