[146617] in cryptography@c2.net mail archive
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
daemon@ATHENA.MIT.EDU (David Mercer)
Thu Sep 5 21:53:02 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <A38A92AB-5D38-4C81-B784-929ACE7F9934@lrw.com>
Date: Fri, 6 Sep 2013 09:49:03 +0800
From: David Mercer <radix42@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
"Perry E. Metzger" <perry@piermont.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============4965444072607440957==
Content-Type: multipart/alternative; boundary=089e0168163448595e04e5ad3e70
--089e0168163448595e04e5ad3e70
Content-Type: text/plain; charset=UTF-8
On Thursday, September 5, 2013, Jerry Leichter wrote:
> [This drifts from the thread topic; feel free to attach a different
> subject line to it]
>
> On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote:
> > 3) I would not be surprised if random number generator problems in a
> > variety of equipment and software were not a very obvious target,
> > whether those problems were intentionally added or not.
> Random number generators make for a very interesting target. Getting
> decent amounts of entropy on conventional machines is very difficult.
> Servers have almost no random variation in their environments; desktops
> somewhat more; modern laptops, yet more. Virtualization - now extremely
> common on the server side - makes things even harder. But even laptops
> don't have much. So we're left trying to distill "enough" randomness for
> security - a process that's error-prone and difficult to check.
>
Virtual private servers are a very big problem. Virtual machine deployment
systems at very large hosting providers have been found to use the same
/dev/urandom initialization for many thousands of machines. It comes from
not re-seeding from /dev/random on provisioning, and running with the same
seed as was in the VM template when it was 'cut'.
I know because I fixed it at places I worked as a contractor. I know at
least one competitor had the issue. No knowledge if it was ever fixed
there. Don't trust seeds you didn't generate. Think about Amazon AWS
instances all spinning up on demand with the exact same init code and prng
seed (this example is not the ones i dealt with, butnis perhaps a larger
problem). You always have a window after startup where you can predicte the
state of the kernel level prng. Not a big one, but it is real and in the
wild.
-David Mercer
--
David Mercer - http://dmercer.tumblr.com
IM: AIM: MathHippy Yahoo/MSN: n0tmusic
Facebook/Twitter/Google+/Linkedin: radix42
FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7
--089e0168163448595e04e5ad3e70
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, September 5, 2013, Jerry Leichter wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">[This drifts from the thread topic; feel free to atta=
ch a different subject line to it]<br>
<br>
On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote:<br>
> 3) I would not be surprised if random number generator problems in a<b=
r>
> variety of equipment and software were not a very obvious target,<br>
> whether those problems were intentionally added or not.<br>
Random number generators make for a very interesting target. =C2=A0Getting =
decent amounts of entropy on conventional machines is very difficult. =C2=
=A0Servers have almost no random variation in their environments; desktops =
somewhat more; modern laptops, yet more. =C2=A0Virtualization - now extreme=
ly common on the server side - makes things even harder. =C2=A0But even lap=
tops don't have much. =C2=A0So we're left trying to distill "e=
nough" randomness for security - a process that's error-prone and =
difficult to check.<br>
</blockquote><div><br></div><div>Virtual private servers are a very big pro=
blem. Virtual machine deployment systems at very large hosting providers ha=
ve been found to use the same /dev/urandom initialization for many thousand=
s of machines. It comes from not re-seeding from /dev/random on provisionin=
g, and running with the same seed as was in the VM template when it was =
9;cut'.</div>
<div><br></div><div>I know because I fixed it=C2=A0at places I worked=C2=A0=
as a contractor. I know at least one competitor had the issue. No knowledge=
if it was ever fixed there. Don't trust seeds you didn't generate.=
Think about Amazon AWS instances all spinning up on demand with the exact =
same init code and prng seed (this example is not the ones i dealt with, bu=
tnis perhaps a larger problem). You always have a window after startup wher=
e you can predicte the state of the kernel level prng. Not a big one, but i=
t is real and in the wild.</div>
<div><br></div><div>-David Mercer<span></span></div><div><br></div><br><br>=
-- <br>David Mercer - <a href=3D"http://dmercer.tumblr.com" target=3D"_blan=
k">http://dmercer.tumblr.com</a><br>IM: =C2=A0AIM: MathHippy Yahoo/MSN: n0t=
music<br>
Facebook/Twitter/Google+/Linkedin: radix42<br>FAX: +1-801-877-4351 - BlackB=
erry PIN: 332004F7<br>
--089e0168163448595e04e5ad3e70--
--===============4965444072607440957==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============4965444072607440957==--
