Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Better to encrypt your drives. Like ZFS encryption. No need to destroy the hardware in this case and you're also save from someone stealing the server.


I’d say it depends on your use case.

In many compliance-heavy fields, there are specific requirements around data destruction, sometimes involving physically destroying the storage medium up to some given standard.

I’d assume this device targets that market.


Most data destruction compliance standards I am familiar with allow for cryptographic erasure when the device is encrypted prior to sensitive data being written to it (excluding some specific data-sensitivity levels).

If they are strict enough to not allow for cryptographic erasure (or the data is above a specific sensitivity), this device would likely not be in compliance either -- physical destruction generally requires shredding/grinding to a specific particulate size, or incineration, and this device does not appear to do either.


I'm not saying there are many (any?) modern standards that would allow physical destruction without cryptographic erasure. As far as I know, physical destruction requirements are usually accompanied by cryptographic erasure requirements.

I'm also not saying that all compliance standards related to data security require physical destruction; just that these absolutely exist, mostly in defense and similar areas.


Most standards (e.g. ISO 27001, NIST 800-88) do allow for physical destruction without cryptographic erasure if the device is being shredded or incinerated (to the applicable shredding/incineration standard of particulate size/temperature). Especially because cryptographic erasure is effectively pointless (at high data-sensitivity levels) if the device wasn't encrypted immediately and prior to data being written. Notably, NIST 800-88 2.6 explains when not to use cryptographic erasure, and when to consider it, but there is no requirement for it.

But, I mainly made my comment in reply to this part of your comment:

>I’d assume this device targets that market.

Because I don't think there is any market where this SSD punching device would be compliant and cryptographic erasure wouldn't be compliant. At least, in my career, I have not seen any environment or standard where this would be considered compliant but cryptographic erasure wouldn't be.


Right, but nobody's arguing that there are cases where you'd physically destroy a device, while cryptographic erasure of the data is not required as well.

I didn't explicitly say this in my original comment since it seemed implicit given the context.


>nobody's arguing that there are cases where you'd physically destroy a device, while cryptographic erasure of the data is not required as well.

I am very explicitly saying cryptographic erasure is not required if you are following physical destruction standards (in ISO 27001 and NIST 800-88, at least).


This isn't necessarily sufficient unless you encrypt the drives before any data is written to them. If any potentially sensitive data has been written to the drive prior to encryption, the only 100% method is physical destruction.

Of course, this clarification only matters if your threat model involves dealing with top-secret data and/or nation-state enemies.


I don't know, personally, I would be very unhappy if someone stole my server and then starts blackmailing me to reveal private information somewhere (unless I pay a certain sum). I don't have anything to hide, but I still don't want my private information public. I don't need to mind about this with encrypted data.


>I don't need to mind about this with encrypted data.

I'm not sure if I wasn't clear or if you didn't read my comment correctly.

Encrypting is not enough to prevent data recovery if data was written to disk prior to encrypting it.

In other words, if you want to be 100% sure about your data being safe, you must encrypt first (when the drive is brand new), or you must physically destroy the drive.


Yes, I understood - but this has nothing to do with encryption. Data that is encrypted is save. Any data that is not encrypted (or was not encrypted) would offer an attack surface. Since I use ZFS for all my data, all my data is encrypted from Minute 1 of a new hard drive.


Format, then sdelete x 10 passes writing random data, then secure erase for good measure, will take care of it for 99% of use cases out there.


Sure, if you don't need to meet any compliance standards and your threat model is pretty relaxed, this is likely okay.

But if your threat model is that relaxed, you can just encrypt the whole drive, toss the key, and then format the device. This would likely be quicker than doing 10x write passes.

As a note, write passes are really only good for HDDs due to wear-leveling algorithms in every SSD.


There is a encryption standard for ssds and the better ones do this anyway.

The boot password might be needed to be configured but it's unlocks your SSD. It's enough for the SSD to forget the AES key


Doesn't help the millions of unencrypted hard drives that are currently in service and will need to be disposed of eventually.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: