Let me echo your advice that hardware random numbers are preferable to software, and if you have to use software it’s important take some precautions. Multiple sources of randomness are indeed strongly recommended.
Don Eastlake, Jeff Schiller and I wrote an RFC twenty years ago giving some advice on this. The current version is RFC 4086. The abstract is below. Steve > Security systems are built on strong cryptographic algorithms that > foil pattern analysis attempts. However, the security of these > systems is dependent on generating secret quantities for passwords, > cryptographic keys, and similar quantities. The use of pseudo-random > processes to generate secret quantities can result in pseudo- > security. A sophisticated attacker may find it easier to reproduce > the environment that produced the secret quantities and to search the > resulting small set of possibilities than to locate the quantities in > the whole of the potential number space. > > Choosing random quantities to foil a resourceful and motivated > adversary is surprisingly difficult. This document points out many > pitfalls in using poor entropy sources or traditional pseudo-random > number generation techniques for generating such quantities. It > recommends the use of truly random hardware techniques and shows that > the existing hardware on many systems can be used for this purpose. > It provides suggestions to ameliorate the problem when a hardware > solution is not available, and it gives examples of how large such > quantities need to be for some applications. On Mar 8, 2015, at 2:05 PM, tlhackque <[email protected]> wrote: >> >> Subject: Re: [Dnssec-deployment] Haveged >> From: Richard Lamb <[email protected]> >> Date: 07-Mar-15 17:49 >> To: Robert Martin-Legene <[email protected]> >> CC: "[email protected]" >> <[email protected]> >> Seems like a good approach. But I havent tried it. I thought for "crypto >> quality" random numbers you had to feed results through AES so that a secret >> counter feeding AES would be reasonable. ...or something trying to be both >> like http://www.pcg-random.org/ >> >> Thanks for the link. There are a number of key gen installations with low >> entropy. >> >> -Rick >> >> > Actually, I'm quite suspicious of software and activity-based approaches for > this. If you care about > crypto-quality results, there is cheap hardware available. EntropyKey (which > I have been happy with) > seems to be out of business. But a device like TrueRNG on paper is quite > similar. For $50, you get plenty of > really random bits. Even on an idle machine. > > http://ubld.it/products/truerng-hardware-random-number-generator/ > > I have no stake in either company, but have been burned by 'clever' software > that isn't. > > Of course, there are much more expensive random number generator devices; > often > packaged with SSL accelerators, they go for USD thousand(s)-ish. > > Newer CPUs also include hardware random number generators that can provide > Gb/s of entropy. > > Normally, one multiplexes any of these sources into the entropy pool, which > does whitening and > some mixing. This helps to ensure that that a failure or bug in one doesn't > produce predictable results, > and protects against some physical compromises of the source. > > For multiple machines, I use entropybroker to distribute one key to multiple > (virtual and physical) > machines. So it's one $50 expense, not $50/machine. > > There's a lot written on the web about this topic; of varying quality. For > less money, there are > a number of 'build it yourself' / open hardware projects. I don't think > those apply here. > > My bottom line is that for $50, (or $0 with a newer CPU), you can solve the > problem in most > cases. You can also do a lot of multiples of $50 before hitting the price of > an SSL accelerator > class solution... > > And it's really neat to generate a 4K key in the time it takes to look up the > next command :-( > > -- > This communication may not represent my employer's views, > if any, on the matters discussed.
