Messages in this thread | | | From | Stephan Mueller <> | Subject | Re: [RFC PATCH 0/5] CPU Jitter RNG | Date | Tue, 04 Feb 2014 21:31:59 +0100 |
| |
Am Dienstag, 4. Februar 2014, 11:06:04 schrieb H. Peter Anvin:
Hi Peter,
>On 02/04/2014 09:08 AM, Theodore Ts'o wrote: >> I really wish we could get someone inside Intel who has deep >> knowledge >> about CPU internals to render an opinion about this. My reaction to >> "I can't explain where the entropy is coming from" seems very similar >> to what my home grown attempts to create an encryption algoritm when >> I >> was much younger and much more foolish --- "it must be secure because >> I can't break it". > >I think I have deep enough knowledge about CPU architectures in general >(as opposed to specific Intel designs, which I wouldn't be able to >comment on anyway) to comment. The more modern and high performance a >design you have the more sources of unpredictability there are. >However, there are very few, if any, (unintentional) sources of actual >quantum noise in a synchronous CPU, which means that this is at its >core a PRNG albeit with a large and rather obfuscated state space. > >The quantum noise sources there are in a system are generally two >independent clocks running against each other. However, independent >clocks are rare; instead, most clocks are in fact slaved against each >other using PLLs and similar structures. When mixing spread spectrum >clocks and non-spread-spectrum clocks that relationship can be very >complex, but at least for some designs it is still at its core >predictable.
But isn't there an additional clock? The clock used to drive the cache and memory bus? When measuring memory accesses timings, larger variations in the execution time are evident. This also applies when hitting the caches (for L1, the variations are less than for L2 than for L3). The variations in access timings would come from the CPU wait states and their duration, would it not?
Ciao Stephan
| |