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?

Improve this question
5
  • 23
    No. Stop doing this. You are just destroying the SSD.
    – Michael Hampton
    Jun 11, 2015 at 17:12
  • Is this the wrong use of the word entropy?
    – user3728501
    Jun 11, 2015 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, 2015 at 0: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, 2015 at 7:41
  • @Reid Fair enough - I saw the question and was interested due to my physics background.
    – user3728501
    Jun 12, 2015 at 10:25

4 Answers 4

Reset to default
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.)

Improve this answer
1
  • 1
    Bravo @Michael for not letting the question get in the way of the proper answer.
    – chicks
    Jun 16, 2015 at 23:48
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.

Improve this answer
3
  • 2
    Faster than /dev/random, sure, but slower than /dev/zero, and it doesn't gain you any security.
    – Mark
    Jun 12, 2015 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, 2015 at 7: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, 2015 at 8: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.

Improve this answer
1
  • I should use my serverfault account more often.
    – Aloha
    Jun 14, 2015 at 13:04
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.

Improve this answer
7
  • 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 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, 2015 at 7:01
  • thanks for the comment. I edited my answer to reflect your point.
    – Henrik Pingel
    Jul 28, 2015 at 7:10
  • Can't argue with that - +1 from me (even though this question has already been fully answered).
    – MadHatter
    Jul 28, 2015 at 7: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, 2015 at 7:19
  • 1
    I agree, but not for SSDs, which is what this question is specifically about.
    – MadHatter
    Jul 28, 2015 at 7:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .