Hi Steve, At the risk of an echoing echo...and violently agreeing: I do remember your comprehensive RFC, but even the update is now a decade old. An updated update may be in order, as there are several notable recent developments...
1) The inclusion of hardware random number generators in CPUs - both Intel and ARM. (I'm not sure where AMD is, but they usually catch up.) 2) The availability of cheap ($50 is now cheap) hardware sources, mostly USB source. Also in the meantime, the consumption of entropy has increased. Virtual address space randomization consumes entropy, as do SSL/SSH connections that are much more common now than only a few years ago. And then there are security token challenges ... every time I turn around, some paper or process wants entropy to counteract the latest security issue! Not just permanent keys, but one-time nonces, tokens and seeds. One irony is that (as your paper notes, but perhaps does not emphasize enough for today) idle systems make it hard for software amplification techniques to work. Disk heads that aren't seeking don't generate randomness, nor do headless systems in dark corners of an enterprise. Key generators on machines off the net, or on isolated segments can't use network traffic as a volume source of entropy. And lots of cheap memory caches I/O to reduce that wonderful disk chatter. Even 10 years ago, an idle machine was an expensive waste. But today, that's not the case. Yet those idle machines are precisely the systems that people tend to use for important key generation. Isolated, protected and 'safe' - which means idle. Now that they're cheap (as in, a << $100 Raspberry Pi has a CPU with a hardware entropy source, ethernet & flash memory), they're it's perfectly reasonable to dedicate whole machines as well as hardware to entropy generation. Except that you have to turn on the entropy source, and distribute the entropy securely. When you wrote the RFC, hardware was desirable, but expensive. And so you rightly emphasized the alternatives for making the most of what little was available. I suggest that with the changes in both the economics and consumption of entropy, there is little excuse for not including hardware sources. $50 is a price point that even a hobbyist like me can afford. And newer CPUs make Gb/s entropy sources 'free' (as in mandatory options) -- even the notebook PC upgrade that I'm considering includes one at no price premium. Especially given the CPUs' (belated) arrival at the entropy party, there really isn't an excuse, even for the proverbial embedded system, to rely on software generation/amplification techniques, or tricky use of hardware intended for other purposes. The problem with tricky is that it's, well, tricky. Easy to get wrong, tough for the non-expert to validate. And easy for a non-expert to rely on something broken. There is a need to counter the impression that 'relying on hardware that must be bugged by NSA is dangerous'. My understanding is that once you have have mixed/whitened that data, it's quite safe...but there have been some heated exchanges in the Linux world on the subject. There may also be a need for a note on 'how to validate your entropy source' - better yet, a pass/fail tool that can be applied by non-experts. (Yes, I do know that that the tests are statistical, but system administrators shouldn't have to become statisticians to know when to service a machine, or to worry.) So while the RFC is an encyclopedic compendium of the (then) state of the art and beyond my expertise, it may be time for a change in emphasis. Hardware entropy generation is no longer expensive or exotic, but cheaply and widely available. Use it! T On 08-Mar-15 15:17, Steve Crocker wrote: > 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] > <mailto:[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. > -- This communication may not represent my employer's views, if any, on the matters discussed.
