16

I have to hand off a Laptop including its hard disc. Since it was not encrypted I wanted to wipe it at least quickly. I know this is not optimal on SSD, but I thought better than just plain readable.

Now I am running wipe of a live USB stick and it is painfully slow. I wonder why that is. Of course there is hardly anything happening on the computer besides wiping that device, so I imagine entropy could be low (entropy_avail says it is at 1220). Would it be equally good to just call 

dd if=/dev/random of=/dev/sda1 bs=1k

four times? Or is there a way I can call something that will increase the randomness? Or is the bottle neck somewhere completely different?

user857990
  • 287
  • 3
  • 13
  • 23
    No. Stop doing this. You are just destroying the SSD. – Michael Hampton Jun 11 '15 at 17:12
  • Is this the wrong use of the word entropy? – user3728501 Jun 11 '15 at 20:25
  • 3
    @user3728501: There are really two facets to the answer: "entropy" here is consistent with kernel usage, so yes, it is the right word in that sense; but the kernel's usage of "entropy" is *really* talking about *estimated* entropy, not true Shannon entropy. Suffice it to say that the details are sufficiently subtle that no one will fault you for saying "entropy" in this context (unless they are being pedantic). – Reid Jun 12 '15 at 00:59
  • 3
    I don't understand why someone would use random/urandom on a modern disk anyway, SSD or not - zeroing would be quicker and just as effective. – Chopper3 Jun 12 '15 at 07:41
  • @Reid Fair enough - I saw the question and was interested due to my physics background. – user3728501 Jun 12 '15 at 10:25

4 Answers4

50

Don't attempt to "wipe" an SSD with tools designed for spinning magnetic hard drives. You won't actually destroy all the data, and you'll just reduce the lifetime of the SSD.

Instead, use an erase tool specifically designed for SSDs, which can use the drive's internal flash erase (discard) to discard all of the blocks, including the ones you can't access. The SSD vendor usually provides such a tool which is guaranteed to be compatible with that vendor's drives.

You can also try doing it yourself with a Secure Erase utility. Programs that do Secure Erase work with both spinning hard drives and SSDs. In addition, a few system BIOSes (mainly in business laptops) have Secure Erase functionality built in. Note that a Secure Erase will take hours on a hard drive, but only seconds on an SSD; on a hard drive every sector must be ovewritten, but on an SSD it will discard all the blocks at once and/or change the drive's internal encryption key.

(And note that secure erase did not work properly on some of the earliest generation SSDs; in these cases you should just throw the drive in a crusher.)

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
6

Using /dev/urandom should make everything faster. I wouldn't wipe an SSD like that. SSD's usually have advanced wear leveling in place. Basically, instead of writing over the existing data, the drive writes over unused portions. It'll take a bit of time to properly scramble all the data. By that time, you would have already wore down an SSD, though it's only by a tiny bit.

Aloha
  • 266
  • 4
  • 15
  • 2
    Faster than `/dev/random`, sure, but slower than `/dev/zero`, and it doesn't gain you any security. – Mark Jun 12 '15 at 22:20
  • 2
    @Mark Why? Although it is only pseudorandom, it also overwrites the data on the device with high-entropy crap. – peterh Jun 14 '15 at 07:46
  • 4
    @peterh, you don't need high-entropy crap. It hasn't been possible to recover data from a zero-wiped drive for at least the past 20 years. – Mark Jun 14 '15 at 08:31
3

/dev/random generates random data by entropy collected by your system (time delays between keyboard shortcuts, network timing by measuring the packet arrivals with nanosecond precision, etc). If there is not enough entropy, this device blocks output while it collects more entropy.

/dev/urandom uses aso the collected entropy, but it uses a pseudorandom generator, too. So its doesn't have that much entropy, unlike /dev/random, but it is very fast. Its output has high enough entropy, though, so you can use it everywhere if you don't have some very high security restrictions (typically, key generation).

If you overwrite an SSD o the block level with high-entropy crap, you will actually overwrite its flash ram on the very low (and in most cases, unreachable) level. This is because the SSD controlling IC doesn't have any possibility to investigate, your data it really crap or not, so its data deduplication mechanism is easily avoided.

But flash rams have a maximal block write and you send it with a such action nearer to its lifetime expiration. But an SSD can be overwritten around 10000-100000 times before it starts to die, and data wiping doesn't need to happen so often, so it is yet okay.

Aloha
  • 266
  • 4
  • 15
peterh
  • 4,914
  • 13
  • 29
  • 44
1

In response to the comments to my answer I must admit that wiping is in general not a good idea for SSDs.

In addtion to the answers above I would like to recommend frandom

It is even faster than urandom. urandom is a lot faster than random but yet quite slow. Frandom is my choice for wiping disks and only for wiping disks. It doesn't produce the same entropy as random and urandom, but for wiping disk it should be enough. As MadHatter pointed out the algorithm used has weaknesses. But for wiping disk however you only want to assure that it is not possible to reconstruct possible remaining bits.

If you got problems runnning it the ArchWiki has a good documentation. The ArchWiki also covers a lot more details about how to erease disks.

Henrik Pingel
  • 8,676
  • 2
  • 24
  • 38
  • As a caveat, I note that the author of frandom says that "*is based on the RC4 encryption algorithm, which is considered secure, and is used by several applications, including SSL*". That's not quite true; [Wikipedia notes](https://en.wikipedia.org/wiki/RC4) in July 2015 that "*RC4 has weaknesses that argue against its use in new systems ... RFC 7465 prohibits the use of RC4 in TLS*". I grant that frandom is a replacement for `/dev/urandom`, which isn't highly-random anyway, but anyone using frandom should probably make themselves aware of the issues. – MadHatter Jul 28 '15 at 07:01
  • thanks for the comment. I edited my answer to reflect your point. – Henrik Pingel Jul 28 '15 at 07:10
  • Can't argue with that - +1 from me (even though this question has already been fully answered). – MadHatter Jul 28 '15 at 07:12
  • thanks. wiping with `urandom` can take hours. I'm pretty sure that many people will value frandom for that reason. – Henrik Pingel Jul 28 '15 at 07:19
  • 1
    I agree, **but not for SSDs**, which is what this question is specifically about. – MadHatter Jul 28 '15 at 07:20
  • This question is about erasing SSDs, not hard drives. Your proposal is useless for this and damaging to the SSD. – Michael Hampton Jul 28 '15 at 14:06
  • ok, you are right. I once did that in preparation for disk encryption. The argument I read to do that was: If everything is random on the disk an attacker could not identify the crypted parts of the disk. Is that valid? – Henrik Pingel Jul 28 '15 at 14:15