On Sat, 2013-12-14 at 19:00 -0200, Henrique de Moraes Holschuh wrote: > On Sat, 14 Dec 2013, Steven Chamberlain wrote: > > On 14/12/13 01:08, Henrique de Moraes Holschuh wrote: > > > Yeah, I think Linux went through similar blindness braindamage sometime ago, > > > but blind trust on rdrand has been fixed for a long time now, and it never > > > trusted any of the other HRNGs (or used them for anything at all without a > > > trip through "rng-tools" userspace until v3.12). > > > > I seem to remember that Ted T'so's committed the fix for this only after > > the release of Linux 3.2, so I assuemd wheezy's kernels might be still > > affected? > > I'd need to check it througoutly, but almost all important /dev/random > changes in Linux were backported to all stable kernels, and thus eventually > migrated into the Debian kernel (which is based on 3.2.y-stable plus lots of > other backports). If I understand rightly, in Linux 3.2 RDRAND (or other architectural HWRNG) was used for get_random_int() and get_random_bytes() but not for /dev/random or /dev/urandom. Linux 3.2.27 (and other stable updates) inclued a large set of security improvements for the RNG, primarily addressing lack of entropy at boot (see <https://factorable.net>). As part of this, an architectural HWRNG will be used as a extra source of entropy for /dev/random and /dev/urandom, but credited as providing only a fraction of a bit of entropy. get_random_bytes() was changed to not use an architectural HWRNG. get_random_int() and get_random_bytes_arch() will use it and it is documented that they are not suitable for cryptographic purposes. Ben. -- Ben Hutchings Knowledge is power. France is bacon.
Attachment:
signature.asc
Description: This is a digitally signed message part