-----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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
