urandom vs haveged

[David Sommerseth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/03/12 21:56, Chris Murphy wrote:
> 
> Performance:
> 
> dd if=/dev/zero		~56MB/s		CPU < 10% dd if=/dev/urandom	~12MB/s
> CPU 99% haveged			~54MB/s		CPU < 25%
> 
> 
> The dd relative values are consistent with kernels in Fedora 16. 
> However these tests were done with 3.3.0-1. The questions are:
> 
> Is the urandom performance expected?

That sounds reasonable.  Unless I mix /dev/random and /dev/urandom,
the latter blocks until it has filled up the entropy pool again.

> What is the quality of pseudo-random data produced by urandom vs 
> haveged?

PolarSSL used havege in v1.0 and below.  It used RDTSC as a source for
seeding the randomisation.  However, it turned out that in some
virtualised environment, the RDTSC values was quite easy to predict.
I'm not sure if I mix it with another issue, but I believe I remember
some reporting it to constantly be seeded with 0.

Havege is in otherwords something to play carefully with.  If used
together with other randomisation sources or on bare metal, it's okay.

Kind of interesting, as LWN had an article pointing at this blog post
today <http://rusty.ozlabs.org/?p=265> ... and yesterday the havege
implementation in OpenVPN when using PolarSSL was discussed in the
developers meeting.  As a side note, OpenVPN decided to deprecate
PolarSSL versions below v1.1, thus enforcing DRBG as a replacement for
havege, due to the mentioned reasons.  (Using OpenSSL, nothing changes
btw.)

> If the qualities are similar, or haveged's is better, is there 
> anything that can be done to improve urandom's performance? It
> really takes quite a bit longer to prepare a disk/volume for
> encryption.

The reason /dev/urandom is experienced as slow is because it tries to
ensure a certain level of randomness.  That's also a device provided
by the kernel.

While havege and other rngd's are probably faster as they can use more
sources for entropy generation and prepare bigger entropy pools than
what's default in the kernel space.

But as mentioned, be careful with havege.  It might not be as random
as you'd expect.


kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk915wcACgkQIIWEatLf4HerZQCglA4QOSgRoIR8FwSMBBfR52Su
PNgAoKzFupvU2MwuFHty+3cDiUJJPGnv
=JN6G
-----END PGP SIGNATURE-----