[147982] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] What's a Plausible Attack On Random Number

daemon@ATHENA.MIT.EDU (Yaron Sheffer)
Mon Nov 4 01:13:34 2013

X-Original-To: cryptography@metzdowd.com
Date: Mon, 04 Nov 2013 07:49:27 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: John Denker <jsd@av8n.com>, 
	"cryptography@metzdowd.com List" <cryptography@metzdowd.com>
In-Reply-To: <52758C6D.5010404@av8n.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

On 2013-11-03 01:36, John Denker wrote:
> As one possible answer to the question in the Subject: line
> of this thread:  The #1 all-time most-plausible method for
> attacking a PRNG starts by finding out how badly initialized
> the thing is.
>
> Some actual observed facts:
>                                     prior
>       startup script                #bits
>     ---------------------           -----
>     (mountall)                      18816
>     (mounted-run)                   21888
>     (sshd server)                   35616
>     (network-interface : lo)        55968
>     (network-interface : eth0)      68832
>     (urandom)                       79168
>
> In the left column, we have the description of a startup script,
> as observed on an ordinary Linux system.  In the rightmost column
> we have the number of bits extracted from the kernel PRNG before
> said script gets invoked.
>
Thank you, this is great information (if only for some distros, as Ted 
noted).

I personally think the following three are better alternatives than a 
DHCP-based solution, however they are not sufficiently widespread and so 
leave enough of a hole that DHCP could plug:

1. Pre-provisioning of a random, unique, secret seed by the manufacturer,
2. Hardware sources, such as RdRand.
3. Obtaining a seed from the host, in virtual environment.

#1 is rarely done, #3 is only applicable to some environments (and not 
even to all public clouds), and #2 does not apply to all hardware.

I agree that DHCP alone will not solve the problem and that startup 
processes will need to be rearranged in some cases, or at least the 
important consumers (sshd) will need to hold off before they start 
requesting entropy.

Thanks,
	Yaron
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post