[147748] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
daemon@ATHENA.MIT.EDU (John Denker)
Sat Oct 19 14:21:49 2013
X-Original-To: cryptography@metzdowd.com
Date: Sat, 19 Oct 2013 09:48:42 -0700
From: John Denker <jsd@av8n.com>
To: Cryptography <cryptography@metzdowd.com>,
"rng@lists.bitrot.info" <rng@lists.bitrot.info>
In-Reply-To: <21090.45811.164575.565840@desk.crynwr.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography