# How to determine the fastest OpenSSL cryptographic algorithm

This question does have to do with cryptography, but not necessarily with encrypting meaningful data. This is my first post here, so if I'm going about this question incorrectly please let me know.

Some quick back story: I have a regular volume of hard drives that I need to wipe. I'm not wiping DoD stuff, and I really don't want to debate which method is the correct one to use. I have a method I use that I'll show here and that's what I'll continue to use for the time being. I'm also running the wipe from a Raspberry Pi because I don't have an extra PC available.

Because I have a regular volume, I tried to find a method of writing psudo-random data to a disk with the highest throughput.

This gives me 8-9MBps throughput:

dd if=/dev/urandom of=/dev/sda


And this gives me 9-10MBps:

dd if=/dev/zero of=/dev/sda


I need this process to move much faster, and I don't have access to any hardware-backed crypto.

I found this a while ago from someone else in the StackExchange network and it gives me 28-35MBps throughput:

openssl enc-aes-128-ctr -pass pass:<128-bytes-of-random-data> -nosalt < /dev/zero > /dev/<disk-to-wipe>


My question is, how can I quickly determine which crypo library will give the the most throughput for my application and still generate sufficiently random data for my use case? Are there additional crypto libraries that aren't installed by default? Is there something faster than openssl for this?

I know I could use an old laptop or some other device for this, but I don't have that now, and even if I did I would still want to optimize the solution for that device.

I hope this makes sense and is relevant to this community, but if this needs to be posted somewhere else please let me know.

• openssl speed will start benchmarking algorithms. The fastest algorithm if you don't have AES-NI will probably be Salsa/ChaCha. That being said, I'm not sure this is on-topic for our site, but I'll let our community vote on it since I'm not absolutely sure. – Ella Rose Jan 28 '19 at 0:24
• If you want real speeds you will let the drive do it itself. This also has the advantage that it may wipe sectors that are out of reach of any software (spare sectors in case of bad sectors and the like). Try and look for the ATA SECURE ERASE . HDD's will still take a long time of course; SSD's will be wiped seconds. Because of the wear leveling algorithms, SECURE ERASE is the only recommended way to wipe an SSD. Disadvantage: the drive manufacturer must have implemented it correctly; a check afterwards may be a good idea. – Maarten Bodewes Jan 28 '19 at 1:04
• if "dd if=/dev/zero" is going slow, then you have a problem, because all that does is write 0s as fast as possible to the device, there is no computation. Perhaps use something other than dd – Richie Frame Jan 28 '19 at 2:02
• Possibly write a bigger block size (-bs) than the default for dd? Some searches show that it might indeed help. Using anything else than a Raspberry could also help. Of course, with SECURE ERASE, the Raspberry will suffice; it will just have to send some commands over to the drives after all. – Maarten Bodewes Jan 28 '19 at 2:54

It's always best to wipe disks using the ATA SECURE ERASE command directly to the drive. This command lets you wipe data that simply isn't visible to even the Operating System. It is a direct command to the drive to erase itself. Preferably you should send this command over a real SATA or PCI-e (M.2) connection as some (USB) controllers may get in the way. On Linux you can execute it using the hdparm command that is e.g. available on the Parted boot disks or sticks. The good thing is that it doesn't require any CPU or bus speed; the drive just wipes itself at maximum speeds.

The SECURE ERASE command is the only command you should use on an SSD. If you just write to an SSD then - first of all - you won't reach any sectors that have been written before due to wear leveling. Second, by writing data to all sectors, you'd mark all those sectors as in use, and you'd have to SECURE ERASE the disk anyway to be able to (reliably) use it again. Never try to wipe an SSD by just writing to it. Advantage: SECURE ERASE just erases the flash blocks, which is a separate, fast command to each of the blocks; it may literally finish in less than minute, even for larger drives.

Unfortunately, these commands may however be buggy, so some tests afterwards may be in order if you cannot find any information on the drive if SECURE ERASE has been implemented correctly (if unsure, buy Intel SSDs, as they have very rigorous testing of their drives - at least they seem most thorough when it comes to the security / drive encryption).

I don't think you will find anything much faster than AES-CTR on a highly optimized OpenSSL library. You could try a stream cipher as no Raspberry has fast AES support - as far as I know. For just erasing a disk I would assume that RC4 would give you much better results. It won't be as secure, but as it is exceedingly hard to remove data from a wiped disk in the first place, I'd say RC4 is still plenty secure none-the-less. So on actual hard drives - the type with actual disks - RC4 could be a preferred option.

The newer the disk, the more dense the data, the harder it is to restore it. So if you have a rather new disk then writing zeros may already be a good option. There may be some magnetic residue left on the outside of the tracks, but you'd have to reposition the head and be extremely lucky to be able to read it out with any chance of getting significant data. Most disk restoration services will not be able to restore a zeroed disk, at least as far as I've been able to find out so far.

Completely off topic here, but for dd, you'd probably better try a larger block size of e.g. 4 MiB using the -bs command. Otherwise you may get sub-optimal results.

I've got no idea on how to secure erase a USB stick or SD-card. They are pretty small, so if they contain any important data, I'd say destroying the chips physically is the best option. A direct appliance of a sharp object to the center of the chip destroys them with a very high reliability. They are very brittle and don't like torsion - or hammers, for that matter. Buy physically small ones so you don't pollute as much when you bin them for incineration - preferably only the silicon (the flame retardant in the plastic of USB sticks is highly toxic when burned; they are chemical waste).

Hammers also work pretty reliably on the disks of HDD's (with glass disks), for your uber highly secure stuff. Sanding them down is 100% effective. Wear protective glasses and protect yourself from dust and flying objects. I haven't tried this myself yet unfortunately.

• I wouldn't trust a hammer to truly destroy data. Either melt it down or degauss it, but simply shattering it does not necessarily destroy the data. Also I think 4 MiB is too large. Usually around 256 KiB is the ideal block size. – forest Feb 3 '19 at 12:19
• I would not trust degaussing it myself; I like to see things destroyed. But yeah, nothing is perfect. Incineration in a high temperature oven works pretty well. I've also seen some pretty effective shredders. The hammer doesn't really destroy data, it just makes it next to impossible to read the data. – Maarten Bodewes Feb 3 '19 at 12:23
• Sufficiently powerful degaussing can actually warp the metal. :P – forest Feb 3 '19 at 12:24
• OK, I'd trust warped metal to be sufficiently degaussed :) – Maarten Bodewes Feb 3 '19 at 12:25