[147996] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Nov 4 13:56:20 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 4 Nov 2013 13:26:53 -0500
From: Theodore Ts'o <tytso@mit.edu>
To: John Kelsey <crypto.jmk@gmail.com>
In-Reply-To: <B73B9CCA-9532-4DA0-AAFE-16641204C7C6@gmail.com>
X-SA-Exim-Mail-From: tytso@thunk.org
Cc: Alan Braggins <alan.braggins@gmail.com>,
Phillip Hallam-Baker <hallam@gmail.com>,
Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Mon, Nov 04, 2013 at 12:39:16PM -0500, 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.
If we have the random secure seed built into each device, it's
certainly better than nothing. But if we started building systems
that depended only on the secure seed, then how long would it take
before the NSA started leaning on manufacturers to make that "secure
random seed" be AES_ENCRYPT(NSA_KEY, DEVICE_SERIAL_NUMBER)?
I'd much rather try leaning on the ARM cpu vendors include a CPU cycle
counter, since it's much easier to audit that the CPU cycle counter is
doing what you think it is doing, and then you can use that to create
a better entropy-gathering RNG in the OS. (Having them add a hardware
RNG is also good, but that might require more silicon and validation
than simply adding a cycle counter register.)
- Ted
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
