We've been using this general design on multi-user CPU's for a few years. I'm happier with it there because even if the entropy source is just a hardware PRNG there's enough other noise (bus stalls from other running processes, interrupts etc) to ensure that it's going to be very very difficult for someone to determine the point at which you sample that PRNG with sufficient accuracy to compromise you anyway.
All you care about is that you have a stream of numbers which can't be guessed by another running process or from outside the box - whether it's a 'real' entropy source or a PRNG doesn't make a difference. (Unless there's a flaw of course :) - which is Andy's concern here). You can exclude obvious attacks from the kernel, or from the same process, or from someone with physical access to the machine - anyone with that level of access would find it simpler to simply read things like generated RSA keys from memory than to try and guess your bitstream. Which is useful because there's a clear point at which you can cut off the paranoia - beyond this point we don't have to care because we'd have no protection even if we had a proven good entropy source rather than something that just looks like it could be an entropy source. There are some gray areas there - devices which are supposedly tamper-proof, but generally with physical access many such devices have been compromised anyway. The single user case, a lot less confident, yes, PLL's tend to be noisy devices, and may well be behaving like a real entropy source here, however my EE background is 20 years old, and things may have changed - plus, you don't really know what the source of the noise is, that'd require access to the underlying hardware design, and probably quite a lot of time. I suspect that simply checking the distribution is going to be as effective in practice as having more knowledge in any case - I think I'd also be resetting the machine, grabbing a sample (repeat) and and running multiple samples through cross-correlation functions, just to ensure it isn't effectively just a sequence generator initialized at boot. However, with the caveats that you don't get repeated sequences at boot, that you can determine when the 'entropy' source fails and that an attacker can't get physical access to the device it's probably an adequate entropy source. i.e. in something like a smart card - or a PS3 :) - possibly not good enough - in a box sitting in a telecom rack in a locked room, probably yes. Certainly mixing this in is better than *just* using date/time at boot to seed a PRNG for example. Peter From: Andy Polyakov <ap...@openssl.org> To: openssl-dev@openssl.org Date: 16/01/2012 19:32 Subject: Re: OS-independent entropy source? Sent by: owner-openssl-...@openssl.org >> Comments on http://www.openssl.org/~appro/OPENSSL_instrument_bus/ are >> welcomed. > > I did not analyse the architecture of tested processors to check > how many frequencies they are using and how they are generating > them, but isn't this just manifestation of the PLL characteristics? Are you aware of any quantitative PLL characteristics that can be relevant in the context? Can *you* argue in favor of the hypothesis? It's essential that somebody else but me argues to confirm or dismiss it. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
