Thierry Moreau <[email protected]> wrote: > Only NIST (with the help of NSA and participants in a circa 2004 symposium) > advanced the true random source standardization effort, with the main > outcome being NIST SP-800-90. Neither the financial industry (ANSI) nor the > European digital signature got any noticeable momentum on true random source > standardization.
I'd have said the standard reference was RFC 4086 http://www.ietf.org/rfc/rfc4086.txt > No matter how fantastic is the true random source, in all cases (with the > exception of the genuine one-time-pad) a deterministic algorithm crunches > the true random data before a security service is provided. The big picture > analysis can not ignore this required mating between true random source and > deterministic algorithms. Yes, but there is a vital distinction to be made. It is one thing to use a deterministic algorithm -- a hash, or von Neuman's technique for eliminating bias -- to produce dense randomness from an only partly random source. That is needed even if you generating a one-time pad. It is quite a different thing to attempt to use a deterministic algorithm to get out more randomness that you put in. There are systems that do something like this and are thought secure. Yarrow is probably the best-known example. > A deterministic PRNG seeded by a true random > source is usually present in the overall arrangement as a link in the > processing chain. Usually? I'd prefer "sometimes" or "often". > Entropy is an estimation of information quantity from a data source derived > from a probability distribution > *as*if*the*data*source*could*be*exercised*multiple*times*. It assumes some > stability in the data source properties. Entropy is derived from an > appraisal of the process by which true random data is obtained. I doubt any > automated process can reliably insert entropy estimate in meta-data. Any > arbitrary rule is just a reflection of someone's appraisal. For many systems, your description is accurate. However, have a look at Turbid. That does not use an estimate from data but instead derives a lower bond on the entropy from physical properties of the devices. http://www.av8n.com/turbid/paper/turbid.htm > The data rate of a true random source will remain an order of magnitude (or > more) slower than the processing speed of a system CPU (or dedicated crypto > processor). Yes, but the use of high-grade randomness is also orders of magnitude less than data processing. PGP-encrypting a message or re-keying an IPsec connection requires a few hundred random bits. The data that protects might be anything from about a Kbit to a Gbit. > Bursts of cryptographic operations consuming random data will > force either a PRNG expander of randomness or true random data buffering, > both of which implies system state data that requires secrecy protection. Yes, that is a real problem. Using something like the Linux or BSD /dev/random may eliminate the need for buffering, but then its state needs protecting. > In any event, a cryptographic system invariably needs a secure storage > arrangement ("chmod 600 filename" as a very least) for secret or private key > material. I would like to see a publication about the pros and cons of > relying on such secure storage in a secure system design instead of a higher > speed true random source. I suspect overall protections are enhanced if > design/implementation efforts are devoted to secure storage (where a PRNG > state may be kept) and correspondingly lesser emphasis is put on high speed > true random source. If an enemy gets root on your system, then your secure storage is no longer secure. By all means, if you have something like /dev/random or another buffering scheme, store some state and throw it in after a reboot. It certainly cannot hurt and, if the file is secure, it helps a lot. But I think you also need some entropy-collecting activity to stir the pool so that, even if the state is compromised, the pool eventually becomes unknown to the enemy. This might be the interrupt-driven stuff in the Linux driver or the sort of entropy-collecting daemon Gutmann has suggested (link in RFC cited above). For a typical desktop system, that is likely enough. Requirements for random numbers are not heavy, and there is plenty of mouse, keyboard and disk activity. However, on something like a web server that supports many SSL connections or an IPsec gateway running many tunnels, you likey need a hardware RNG. These applications demand considerable quantities of high-grade random numbers but available inputs are limited — a server may not even have a keyboard, mouse or disk. Information from things like timing of network interrupts may be partly known to an attacker who monitors the network, so it can be used only with great caution. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
