[147745] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
daemon@ATHENA.MIT.EDU (John Denker)
Sat Oct 19 12:02:11 2013
X-Original-To: cryptography@metzdowd.com
Date: Sat, 19 Oct 2013 08:59:40 -0700
From: John Denker <jsd@av8n.com>
To: Cryptography <cryptography@metzdowd.com>,
"rng@lists.bitrot.info" <rng@lists.bitrot.info>
In-Reply-To: <20131019143334.GC11764@thunk.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 10/19/2013 07:33 AM, Theodore Ts'o wrote:
> we made a lot of changes to the
> /dev/random code base [....]
> One of them was to do precisely this --- /dev/urandom now mixes in
> salting information (ethernet MAC addresses, etc, via the new
> interface add_device_randomness).
That the sort of thing that /might/ help. It cannot hurt,
except insofar as people overestimate how effective it is.
What is the chance that the attacker can figure out the
MAC address of the box?
What is the chance that the attacker can figure out tight
uppper and lower bounds on the value of the real-time clock?
What is the chance that the attacker can figure out tight
uppper and lower bounds on the device serial number?
===================
Constructive suggestion: As I have been saying for years:
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 randomly-chosen and secret, very
unlike the MAC address, RTC, and device serial number.
Go ahead and mix in stuff likt he RTC and the MAC address
if you want, but you'll have a hard time convincing anybody
that such things are sufficient.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
