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?
On Tue, Oct 30, 2012 at 04:55:22PM +0200, Lasse K?rkk?inen wrote:
> 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
On 10/30/2012 06:54 PM, Theodore Ts'o wrote:
> On Tue, Oct 30, 2012 at 04:55:22PM +0200, Lasse K?rkk?inen wrote:
>> 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.
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.
> If you just want to wipe a disk, you shouldn't be using /dev/urandom for 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
On 30.10.2012 23:38, Alan Cox wrote:
> 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?).
On Fri, Nov 02, 2012 at 03:10:05AM +0200, Lasse K?rkk?inen wrote:
> 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