[147999] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Kent Borg)
Mon Nov 4 14:33:32 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 04 Nov 2013 14:21:15 -0500
From: Kent Borg <kentborg@borg.org>
To: John Kelsey <crypto.jmk@gmail.com>,
Alan Braggins <alan.braggins@gmail.com>
In-Reply-To: <B73B9CCA-9532-4DA0-AAFE-16641204C7C6@gmail.com>
Cc: Cryptography <cryptography@metzdowd.com>,
Phillip Hallam-Baker <hallam@gmail.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 11/04/2013 12:39 PM, John Kelsey wrote:
> Yep. It seems like getting random secure starting seeds into devices
> would be a huge win here. Then they can combine that with whatever
> information they have locally, and initialize their RNG, and then
> generate their keypair.
I think some lessons here are:
1. Worry about operating with low initial entropy, including blocking
usually non-blocking RNG output until some configurable amount entropy
has maybe been collected.
2. Look for local sources of entropy, and look again every few years
as technology changes:
- disk turbulence might have been good once maybe not so much anymore;
- interrupt timing might have been an iffy source earlier, but now
with much faster system clocks holds more promise;
- hw sources like rdrand are becoming more common, but maybe not
trusted, mix with other sources;
- uninitialized RAM contents might have been worth some entropy once
but it seems not so with recent technology.
3. Even non-entropy data that is unique or might vary (MAC addresses,
serial numbers, version numbers, time) makes an attacker's life harder
and are worth mixing in.
A manufactured-in starting seed seems more like #3 than #2 (is it kept
secret?, was it honest and high quality to begin with?), but still worth
using if a manufacturer can afford to include it.
-kb
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography