[Cryptography] [RNG] on RNGs, VM state, rollback, etc.

John Denker jsd at av8n.com
Sat Oct 19 12:48:42 EDT 2013


On 10/19/2013 09:27 AM, Russ Nelson wrote:
>> Go ahead and mix in stuff like the RTC and the MAC address 
>> if you want, but you'll have a hard time convincing anybody
>> that such things are sufficient.
> 
> I just convinced you that the number of bits contributed to the
> entropy at start-up time is small, didn't I? If I didn't, why didn't
> I?

Uhhh, that's the answer to a different question.  We
agree that the amount of available entropy is "small".
My point is that it is too small.  Furthermore, the
work imposed on the attacker is an /exponential/
function of this number, so the work is verrrry much
too small.

If the embedded device had a hundred different MAC
addresses, all unrelated, all unknown to the attacker,
each of which contributed a few bits to the available 
entropy, then there would be no problem ... but that's
not the situation we find ourselves in.  Not even close.

We do not get to make an argument about the perfect
being the enemy of the good in this case.  That's not
the choice we face.  Instead, there is a choice of
real security versus futile security-theater.

 a) Any device that wants to have any security whatsoever
  needs to be able to store a seed, even when powered off.
 b) The seed needs to be provisioned on a per-device
  basis, much like the MAC address is provisioned.
 c) The seed needs to be big enough, randomly-chosen, and 
  secret, very unlike the MAC address, RTC, and device 
  serial number.


On 10/19/2013 09:36 AM, Adam Back wrote:

>> this is in principle a
>> band-aid or worse; it gives the illusion of entropy in the face of actually
>> no entropy to an attacker who can readily obtain the serial numbers in
>> question (eg because the MAC is broadcast on the LAN) or simply brute forced
>> because the guid is while large, highly structured and sparse.

Exactly so.




More information about the cryptography mailing list