urandom is too slow
Apparently there has been little or no development on urandom even though the device is in widespread use for disk shredding and such use. The device emits data at rather slow rate of 19 MB/s even on modern hardware where other software-based PRNGs could do far better. An even better option seems to be utilizing AES for encrypting zeroes, using a random key, allowing for rates up to 500 MB/s with hardware that has AES-NI instructions.
Why is urandom so slow and why isn't AES hardware acceleration utilized?
Quoted 9 lines · Lasse Kärkkäinen
Apparently there has been little or no development on urandom even though the device is in widespread use for disk shredding and such use. The device emits data at rather slow rate of 19 MB/s even on modern hardware where other software-based PRNGs could do far better. An even better option seems to be utilizing AES for encrypting zeroes, using a random key, allowing for rates up to 500 MB/s with hardware that has AES-NI instructions.
Why is urandom so slow and why isn't AES hardware acceleration utilized?
If you can use a software-based PRNG, you should use one in userspace. The intended use of urandom is for cryptographic purposes (i.e., generating random session keys, long-term public keys, etc.). If you just want to wipe a disk, you shouldn't be using /dev/urandom for that purpose.
Regards,
- Ted
Quoted 9 lines · Theodore Ts'o
Quoted 8 lines · Lasse Kärkkäinen
Apparently there has been little or no development on urandom even though the device is in widespread use for disk shredding and such use. The device emits data at rather slow rate of 19 MB/s even on modern hardware where other software-based PRNGs could do far better. An even better option seems to be utilizing AES for encrypting zeroes, using a random key, allowing for rates up to 500 MB/s with hardware that has AES-NI instructions.
Quoted 7 lines
Quoted 1 line
Why is urandom so slow and why isn't AES hardware acceleration utilized?
If you can use a software-based PRNG, you should use one in userspace. The intended use of urandom is for cryptographic purposes (i.e., generating random session keys, long-term public keys, etc.). If you just want to wipe a disk, you shouldn't be using
/dev/urandomfor that purpose.
For the record, shred uses a user space PRNG for speed for the last 3 years or so, rather than using /dev/urandom:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=af5723c7
$ shred-old -v -n3 t shred-old: t: pass 1/3 (random)... shred-old: t: pass 1/3 (random)...8.3MiB/1000MiB 0% shred-old: t: pass 1/3 (random)...17MiB/1000MiB 1% shred-old: t: pass 1/3 (random)...32MiB/1000MiB 3% ...
$ time shred-new -v t shred-new: t: pass 1/3 (random)... shred-new: t: pass 1/3 (random)...116MiB/1000MiB 11% shred-new: t: pass 1/3 (random)...216MiB/1000MiB 21% shred-new: t: pass 1/3 (random)...340MiB/1000MiB 34% ...
cheers,
Pádraig.
Quoted 2 lines
If you just want to wipe a disk, you shouldn't be using
/dev/urandomfor that purpose.
If you want to wipe a disk issue a security erase command via hdparm. There is no guarantee that simply writing crap all over it will re-use the same sectors of physical media, and for a flash drive it causes massive wear and takes forever while a security erase is normally near immediate.
Alan
Quoted 1 line · Alan Cox
If you want to wipe a disk issue a security erase command via hdparm. There is no guarantee that simply writing crap all over it will re-use the same sectors of physical media, and for a flash drive it causes massive wear and takes forever while a security erase is normally near immediate. Alan
Thank you for your answers, they should be very helpful for someone who is actually blanking or shredding their disks. However, I am just genuinely interested on why is no better CSPRNG algorithm used in the kernel (is it simply because no-one sent a patch or am I missing something?).
Quoted 5 lines · Lasse Kärkkäinen
Thank you for your answers, they should be very helpful for someone who is actually blanking or shredding their disks. However, I am just genuinely interested on why is no better CSPRNG algorithm used in the kernel (is it simply because no-one sent a patch or am I missing something?).
The answer is that the goal of /dev/urandom is not to be a cryptographic random number generator (CRNG); a CRNG relies on the security of the cryptographic primitive for its strength. For example, a CRNG which is based on DES or AES encrypting an incrementing counter using a secret key, is fundamentally reliant on the strength of DES or AES. If DES were to be broken, for example, an attacker would be able to determine secret key and thus predict all future outputs of a DES-based CRNG.
The design of the /dev/random and /dev/urandom is to take advantage of the kernel's access to unpredictability from the hardware, and to avoid being "brittle" even in the face of a discovery of a weakness of its cryptographic primitives.
Regards,
- Ted