3 ms·
I don’t want my drive to handle encryption. That’s what operating system is for. It’s not only much more flexible, but also much more secure. Have you seen qua
by justapassenger 4y ago
I don’t want my drive to handle encryption. That’s what operating system is for. It’s not only much more flexible, but also much more secure.
Have you seen quality of the code that runs in most of the embedded devices firmware? It’s a huge surprise that any of the devices actually work. I don’t trust them a second to implement any secure encryption.
- mschuster91 4y ago> I don’t want my drive to handle encryption. That’s what operating system is for. It’s not only much more flexible, but also much more secure. The problem: - an operating system by necessity must have the crypto keys in RAM (which means it's vulnerable to a kernel-level exploit, a hardware-level exploit like Thunderbolt, or to a "freezing spray" attack) - all I/O data will have to be shuffled between the SATA controller, RAM and CPU multiple times for decryption/encryption, incurring a (significant) latency penalty Leaving the crypto operations to the SSD controller or an intermediate FPGA/ASIC removes a lot of these problems: - the OS can wipe the memory containing the key information after passing them to the disk - no part of the system can retrieve the key information past that point, and the disk controller can be built in a way that automatically wipes its internal RAM / plaintext key storage upon power loss - there is no performance/latency penalty at all or at least significantly lower, the system gains back the ability to do DMA transfer (e.g. load GPU texture data straight from the disk into the GPU's RAM space)