On Wed, Nov 24, 2010 at 2:49 AM, Marsh Ray <[email protected]> wrote: > ... > How would you know if it was working properly? Or backdoored?
use an entropy gathering daemon to verify sanity checks on output, obscure generator state through digest or cipher, and finally mix this entropy at conservative density entropy into the host pool for consumption. (that's the abridged version. this is actually more complicated than many assume, and i've written my own egd's in the past to meet need.) > How does this feature interact with virtualization? for virtual guests you have a different type of egd that communicates with host egd / host entropy pool to feed guest pool in similar manner. you typically can't use these entropy sources in both host and guest concurrently. > Low power and sleep > states? What about variations in manufacturing process? in a good hardware entropy design these don't matter. > How hard is it to define such a thing in standard chip design tools? I > imagine many tools will complain loudly about nondeterministic states. it can be as simple as a pair of fast, free-wheeling oscillators sampled by a slower one. > What if it suddenly stopped working? on Padlock you get two independent entropy sources. i run an egd with both for throughput, however, if either entropy source fails the egd falls back on the other. if both fail, it stops contributing to the host entropy pool. (/dev/random) > It seems like doing a decent test on each unit shipped would add at least > some cost to the part. you test not only during qc checks, but also continuously while in use. they may fail at any time! > Will the chip estimate the amount of entropy it has pooled? How? you do the estimate or someone else can, typically after observing many gigabits of output and performing the usual statistical analysis. i also like to estimate at 75% of actual probable entropy density as a safety margin. > Wouldn't you prefer an industrial-strength software entropy pool over a > minimum-possible-area instruction that can never be fully tested? these are complimentary technologies. note that you still need to seed / keep state between runtimes / reboots for a strongly seeded industrial strength software entropy pool (like /dev/random -> /dev/urandom), a hardware source and egd means you're always mixing and contributing strong hardware entropy with your software based pool/mix. > I think a conscientious designer will want entropy from multiple sources, so > he probably won't trust the chip to do it all for him, but perhaps it could > be used as another input. absolutely! > What sources of entropy are available to the chip > designer that are not also available to a software EGD? physical processes :) > How many customers would choose your chip instead of the other brand because > of this? Is it worth the risk inherent in any new feature? you shouldn't have to choose. if every core had well designed hw entropy sources it would be a given. the lack of this is the source of my lamentation... > How do you market it? How do you keep it from being marketed as something > that it isn't? no idea. i have yet to find effective responses to combat the exagnorance from marketing incurred when technical meets prostitution. if you solve this let me know *grin* > If it turned out to be weak, would you have to recall the chips? How about > products containing it? > This sucker got baked into a lot of smart meters, or so I hear: > http://travisgoodspeed.blogspot.com/2009/12/prng-vulnerability-of-z-stack-zigbee.html yup. that's one example of how not to do entropy! (sadly, there are many more examples out there... :( > Of course, the answer may still be that it's better to have an instruction > for it than not. But the advantages are subtle and hard to quantify, whereas > the costs, complexity, and risks of adding it are measurable. agreed. i still think this is better to have than not, particularly for headless server configuration and plentiful key generation requirements. however, all of your concerns are valid and it is indeed a tricky endeavor to do correctly. best regards, _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
