Hacker News Reader

Comment by cedws | Hacker News Reader

Software erasure is no good on modern hardware, it pulls too many tricks internally and the data could easily stick around in a region of NAND not accessible. There’s an easier way - use full disk encryption with a TPM. Data effectively erased upon destruction of TPM key.

View on HN

This is often how secure erase is implemented on SSD (though they often don't use TPMs). Encrypting data transparently on the controller, then regenerating the key on erasure request, turning the data on disk into useless bits.

Of course this comes with the risk that someone exploits the firmware and extracts the key, rendering secure erase useless, but in most cases that's good enough.

When a new key is generated, how can you be certain that the old key is securely deleted?

How do you be certain that ShredOS or any other component does its job? You can always physically burn the drive, but make sure you actually watch it turn to slag.

You have to trust the SSD firmware. And if you don’t, just add your own layer of encryption and manage the key yourself.

Drives which support doing this in hardware have a block just for storing the key. Because it’s not often rewritten, it doesn’t need to go in the pool of blocks that can get remapped.

> There’s an easier way - use full disk encryption with a TPM. Data effectively erased upon destruction of TPM key.

Assuming you can trust the drives to actually encrypt:

* https://news.ycombinator.com/item?id=18382975

I usually encrypt with LUKS and then delete the headers (and then physically destroy the disk). Don’t remember where I read about it, but been doing that for a while.

What happens when the encryption is broken in the future? I feel like relying solely on the key isn’t good enough.

If that's in your threat model, fill the disk with random bytes.

This works on the economic argument that if you could easily recover data from a disk that's been rewritten, drive manufacturers would exploit that already to increase storage.

If your threat model includes attackers who bypass the firmware to read overwritten data, you are probably boned several other ways.

It is usually quicker to just zero the disk instead of random bytes, just because the randomness pool might be scarce in a system. This can save hours when clearing a large and fast disk, like a SSD. /dev/zero usually has much more throughput than /dev/random.

Of course this matters less on slow disks, where the bottleneck is the writing speeds anyway.

Many SSDs transform all-zero sector writes into a simple TRIM/DISCARD to reduce flash wear, so overwriting with pseudorandom data from /dev/urandom is likely more secure.

I don't understand why this question is asked in any context. What if an asteroid is on a collision course with Earth? What if Jesus comes back? What if the yeti is real?

> What happens when the encryption is broken in the future?

Your great, great grandchildren will be embarrassed of the websites you visited.

Or whoever that has quantum computer in the near future. Encryption is just a cat and mouse game it is before long someone will figure out to decrypt it.

There is currently no reason to believe quantum computers will make breaking symmetric encryption like AES-256 any more practical than it is today. At best, grovers algorithm can modestly reduce the search time for brute forcing, but it's still brute force.

Asymmetric algorithms like RSA are the ones you should be worrying about, and I can't imagine any reason someone would do disk encryption with an asymmetric algorithm.

Reply on news.ycombinator.com