[sp332]

That is the only NIST-approved method for erasing a drive securely. http://security.stackexchange.com/a/5784/3714 Trying to overwrite data yourself will miss data in areas of the drive reserved for various reasons by the firmware, and you don't have control over caches etc. ATA Secure Erase is your best bet for clearing all of those.

[schoen]

I think there's a problem that at least one drive claimed at an ATA level to implement Secure Erase, and then didn't actually perform an erase of the drive medium. I'll try to find the reference to that.

[schoen]

Wei et al. (FAST '11), discussing solid-state drives:

"Drive B’s behavior is the most disturbing: it reported that sanitization was successful, but all the data remained intact. In fact, the filesystem was still mountable. Two more drives suffered a bug that prevented the ERASE UNIT command from working unless the drive firmware was recently reset, otherwise the command would only erase the first LBA. However, they accurately reported that the command failed.

The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted to properly sanitize the drive."

https://www.usenix.org/legacy/events/fast11/tech/full_papers...

[dobbsbob]

There's a good stack exchange post about ATA secure erase pitfalls too, how if you just do --secure-erase and not enhanced option then some SSDs will just compress the data and not actually wipe anything.

Found it: http://security.stackexchange.com/a/64480

[tedks]

Who cares if it's NIST-approved? The NSA owns NIST entirely; if something is NIST approved it's probably a good reason to not use it.

[eksith]

The safe bet may be a line from authority itself: "Trust, but verify" as they say.

Right now, the only antidote to systemic weakening (potential or actual, intentional or through incompetence) of security is an auditing of code along with these standards and practices.

It's been mentioned before here and many places elsewhere, but the fork of OpenSSL by the OpenBSD folks and their complete scuttling of cruft, including FIPS 140-2 which required the backdoored Dual_EC_DRBG algo, is a good sign that at least some people are taking a proactive approach to security. In lieu of blindly following existing procedures, seeing what breaks in your work when subjected to extreme duress leads to better software and better practices.

[sp332]

This guidance has been around since 2006 and I don't remember anyone having a better idea since then.

[tedks]

I think knowing that the NSA has some influence on NIST means you have to treat all actions by NIST as possibly the result of NSA pressure, and thus treat everything NIST does as suspect.