> I'm not saying that a diode is unsuitable, just warning that someone should > examine the distribution of their output to make sure that it is reasonably > random and uniform (not the same thing,since not all random processes show > no law-LIKE behavior,in this case,procuding lower voltages more than higher > ones). | Alternative solutions: | Swap bits around in numbers you read (re-map the bits.) | Mod every number by some quantity (same as only taking the rightmost n |bits, effectively, if you mod by 2^n; If you MOD by 15, though, you get |different numbers, etc) For any of this to be worth anything, you need to end up with fewer bits than you got from your raw hardware. Basically, what will happen is that each bit from the hardware RNG device will have a certain amount of "entropy" to it <= 1 bit. For cryptographic purposes (esp. OTP, but really for any kind of key generation) random data should have as close to a "full bit" of entropy per bit as possible. Hash functions can't output more entropy than is fed into them, but they can condense a large stream of less-than-perfectly-random numbers into a smaller stream of closer-to-perfectly-random numbers. | (Also one side note - we REALLY should get back to PICs sometime! - |I've never trusted "key escrow" - as if I want to pick on you & I'm a |government agent, I just store all encrypted comms you ever send - then |if I EVER get a valid search warrant, for some specific piece of |information (faked from a "confidential informant" or not), I can "go |fishing" and steal, loot, and pillage your (rightfully!) confidential |information, at my leisure; Quite illegal in the real world to do |this; And by keeping a copy of the keys, could continue to do so, |illegally... "Key Escrow" means no right to privacy, unless & until |they change it so that only a key for a certain piece/pieces of |information is released, time limited or otherwise somehow limited... |When no-one is allowed to watch the watchers, design failsafes INTO the |system, SHEESH! I'd never trust Clipper to keep company secrets |safe, myself, unless it changed a lot since the time I looked at it, |it's been a while though...) The notion of "key escrow" is not necessarily a bad one; it may, at times be useful *IF* one trusts the people with whom the keys are kept. For example, an employee at a company which is concerned about security might keep all data on his machine encrypted with his own personal key, but may arrange for a "backup" key to be stored safely somewhere so that the comp- any could access his data if he were incapacitated. There are a variety of useful approaches for doing this sort of thing; as an example of a useful approach, consider a company with 9 people on the board of directors. If keys are 128 bits, the employee could give 8 of the directors 16 bits each, and give the 9th director the XOR of the other eight pieces. If it were necessary for the directors to reconstruct the key, any eight of the directors could get together and do so; without the cooperation of at least 8 of the 9 directors, however, the key would be confidential. Of course, the above sort of "key escrow" has very little to do with what Clinton et al have in mind...