Thanks. An update is indeed in progress. I've included Don and Jeff. Don has been active in the update process; I have not.
Steve Sent from my iPhone > On Mar 8, 2015, at 5:55 PM, tlhackque <[email protected]> wrote: > > 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]> 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.
