linux-kernel - Re: urandom is too slow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50903F18.10004@draigBrady.com>
Date:	Tue, 30 Oct 2012 20:56:56 +0000
From:	Pádraig Brady <P@...igBrady.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Lasse Kärkkäinen <ljkarkk2@...hut.fi>,
	linux-kernel@...r.kernel.org
Subject: Re: urandom is too slow

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/