| |||||||||||||
Appropriate sources of entropyAppropriate sources of entropyPosted May 29, 2008 10:01 UTC (Thu) by forthy (guest, #1525)In reply to: Appropriate sources of entropy by giraffedata Parent article: Appropriate sources of entropy
Actually, no, none of the physical processes are predictable to sub-ns precision. First, the sender's CPU uses cache - if some data is not in the cache, it will take more time to read in. Same happens on the receiver CPU - a single cache miss, and the counter will read differently (last few bits only, for sure). Then, there's also clock synchronization. CPU clocks aren't synchronized, and the crystals aren't too precise - a 200MHz HT clock for an AMD processor can actually run at 201.xxMHz (the one I'm using right now is running at 201.155MHz, the other, very similar configured machines I've in the office have the last digits at 53, 54, 55, and 89). As outside attacker, you can't know the exact value (well, even as inside attacker you can't know the exact number - only to a limited precision), but you need to to inject deterministic data into the random number pool. Also, today's networks are usually switched. So there's a store-and-forward switch in between. These switches can theoretically be quite deterministic, but their clock is slower than the CPU clock (25MHz for fast, 125MHz for Gb ethernet). This clock is not synchronized with the other PCs. So if you have a 2.5GHz CPU sending a packed through a single Gb switch, and receive it with another 2.5GHz CPU, you can add 4 bits of randomness into your pool. Chances are high that even more bits are random. I suggest a challenge: Try to produce a deterministic pattern with full knowledge over both sides - e.g. by modifying the kernel's ping code so that it sends the rtdsc timestamp as answer). Whatever quality you achieve in this challenge will be the "dubious" part of the randomness, and the remaining noise can be added.
(Log in to post comments)
|
|||||||||||||