[cryptography] philosophical question about strengths and attacks at impossible levels

coderman coderman at gmail.com
Wed Nov 24 15:11:29 EST 2010


On Wed, Nov 24, 2010 at 2:49 AM, Marsh Ray <marsh at extendedsubset.com> 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,



More information about the cryptography mailing list