[149244] in cryptography@c2.net mail archive
Re: [Cryptography] cheap sources of entropy
daemon@ATHENA.MIT.EDU (Arnold Reinhold)
Tue Jan 28 14:57:48 2014
X-Original-To: cryptography@metzdowd.com
From: Arnold Reinhold <agr@me.com>
Date: Tue, 28 Jan 2014 13:31:08 -0500
To: Bill Stewart <bill.stewart@pobox.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
Jon Callas <jon@callas.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7777540663508663305==
Content-type: multipart/alternative;
boundary="Apple-Mail=_2B618E6D-AC43-4CA7-83AE-1B3437268483"
--Apple-Mail=_2B618E6D-AC43-4CA7-83AE-1B3437268483
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Mon, 27 Jan 2014 22:23 Bill Stewart <bill.stewart@pobox.com>
To: cryptography@metzdowd.com
Subject: Re: [Cryptography] cheap sources of entropy
Message-ID: <20140128062407.01B3C106B1@a-pb-sasl-quonix.pobox.com>
Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed
> At 07:10 AM 1/21/2014, Theodore Ts'o wrote:
>> [1] http://zsoltfabok.com/blog/2013/01/parkinsons-law/
>> I'm not sure whether the RNG is better characterized as the "bite
>> shed" or the "coffee for refreshments" as described in Parkinson's =
3rd
>> chapter, "High Finance, or the Point of Vanishing Interest", but I
>> know one thing for sure. It's not the 10 million pound nuclear
>> reactor.
>=20
> It's clearly into bike shed territory, thus the endless discussion.
> We've all got ideas about the problem and how to fix it, or how it's=20=
> unfixable,
> or at least how somebody else's solution to it is clearly wrong wrong =
wrong,
> unlike the coffee case where we'd have all agreed on a good-enough =
solution
> ("But I don't like coffee!" "Fine, we'll also order donuts=20
> and tea." "Ok, whatever.")
>=20
Nice analogy, but you both have it backwards. SHA2 vs SHA3, AES vs =
Salsa20 and RSA vs ECC are the bike shed/refreshment committee. RNG is =
the $10 billion nuclear reactor waiting to blow up. At the present time =
there is no practical attack on the standard crypto algorithms, but RNG =
is a single point of failure that has shattered crypto security in =
practice many times =
(https://en.wikipedia.org/wiki/RNG_attack#Prominent_examples) and we =
have every reason to believe it is being actively exploited by large =
security organizations.=20
> I'd be tempted to take the Intel "NSA Inside" RNG, hash each 32 bits=20=
> down to 1,
> hash it in with any other available entropy, and call it a day.
> Probably simple parity calculation is as good as fancier hashes for =
that,
> but hash in the system clock if you'd like.
> Maybe use 128 bits instead of 32 if you don't have any other saved =
entropy.
If the Intel chip that you are using has its RNG cooked in ways that =
have been proposed, what you are suggesting will do you no good. The =
cook will still be able to recover the internal state of the faux-RNG =
and all your crypto will be worthless.
>=20
> -- other comments on paint colours for the bike shed --
> There are lots of recommendations for what to do if you can add on =
hardware,
> such as accelerometers (much more useful for cellphones than=20
> rack-mounted servers,
> which are kind of tough to wave around), USB cameras (if you can trust =
the USB
> on your VMware server), sound cards with or without microphones =
(ditto),
> but sometimes you just can't. There's CPU timing randomness
> (not sure how random the low-order bits are in a virtual machine),
> clocks aren't all that random, though they can help you against replay =
attacks,
> and for a virtual machine you really need to do something to prevent
> everybody from using the same "entropy" seed in their identical =
images.
You are right that every RNG solution has limitations (for the record I =
suggested including a cellphone vibration motor to excite an =
accelerometer used on a server) and there is no one right answer. The =
best we can do is to use two or more independent sources, characterize =
each source well, implement them properly, and design our systems for =
maximum auditability consistent with security.
There are (at least) four reasons we keep having endless discussions =
about RNG: there are many possible solutions, there is no one solution =
that fits every situation, there are no good standards available (NIST =
SP800-90 ducks the hard questions), and people forget what was said =
before.=20
Maybe it is time to build a Wiki that summarizes cryptography mailing =
list discussions on this and other topics.
Arnold Reinhold=
--Apple-Mail=_2B618E6D-AC43-4CA7-83AE-1B3437268483
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">On =
Mon, 27 Jan 2014 22:23 Bill Stewart <<a =
href=3D"mailto:bill.stewart@pobox.com">bill.stewart@pobox.com</a>><br>T=
o: <a =
href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br=
>Subject: Re: [Cryptography] cheap sources of entropy<br>Message-ID: =
<20140128062407.01B3C106B1@<a =
href=3D"http://a-pb-sasl-quonix.pobox.com/">a-pb-sasl-quonix.pobox.com</a>=
><br>Content-Type: text/plain; charset=3D"us-ascii"; =
format=3Dflowed<br><br><blockquote type=3D"cite">At 07:10 AM 1/21/2014, =
Theodore Ts'o wrote:<br><blockquote type=3D"cite">[1] <a =
href=3D"http://zsoltfabok.com/blog/2013/01/parkinsons-law/">http://zsoltfa=
bok.com/blog/2013/01/parkinsons-law/</a><br>I'm not sure whether the RNG =
is better characterized as the "bite<br>shed" or the "coffee for =
refreshments" as described in Parkinson's 3rd<br>chapter, "High Finance, =
or the Point of Vanishing Interest", but I<br>know one thing for sure. =
It's not the 10 million pound =
nuclear<br>reactor.<br></blockquote><br>It's clearly into bike shed =
territory, thus the endless discussion.<br>We've all got ideas about the =
problem and how to fix it, or how it's <br>unfixable,<br>or at =
least how somebody else's solution to it is clearly wrong wrong =
wrong,<br>unlike the coffee case where we'd have all agreed on a =
good-enough =
solution<br> ("But I =
don't like coffee!" "Fine, we'll also order donuts <br>and tea." =
"Ok, whatever.")<br><br></blockquote><br>Nice analogy, but you both have =
it backwards. SHA2 vs SHA3, AES vs Salsa20 and RSA vs ECC are the bike =
shed/refreshment committee. RNG is the $10 billion nuclear reactor =
waiting to blow up. At the present time there is no practical attack on =
the standard crypto algorithms, but RNG is a single point of failure =
that has shattered crypto security in practice many times (<a =
href=3D"https://en.wikipedia.org/wiki/RNG_attack#Prominent_examples">https=
://en.wikipedia.org/wiki/RNG_attack#Prominent_examples</a>) and we have =
every reason to believe it is being actively exploited by large security =
organizations. <div><br><div><blockquote type=3D"cite">I'd be =
tempted to take the Intel "NSA Inside" RNG, hash each 32 =
bits <br>down to 1,<br>hash it in with any other available entropy, =
and call it a day.<br>Probably simple parity calculation is as good as =
fancier hashes for that,<br>but hash in the system clock if you'd =
like.<br>Maybe use 128 bits instead of 32 if you don't have any other =
saved entropy.<br></blockquote><div><br></div>If the Intel chip that you =
are using has its RNG cooked in ways that have been proposed, what you =
are suggesting will do you no good. The cook will still be able to =
recover the internal state of the faux-RNG and all your crypto will be =
worthless.</div><div><br><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">-- other =
comments on paint colours for the bike shed --<br>There are lots of =
recommendations for what to do if you can add on hardware,<br>such as =
accelerometers (much more useful for cellphones =
than <br>rack-mounted servers,<br>which are kind of tough to wave =
around), USB cameras (if you can trust the USB<br>on your VMware =
server), sound cards with or without microphones (ditto),<br>but =
sometimes you just can't. There's CPU timing randomness<br>(not =
sure how random the low-order bits are in a virtual machine),<br>clocks =
aren't all that random, though they can help you against replay =
attacks,<br>and for a virtual machine you really need to do something to =
prevent<br>everybody from using the same "entropy" seed in their =
identical images.</blockquote><br></div><div>You are right that every =
RNG solution has limitations (for the record I suggested including a =
cellphone vibration motor to excite an accelerometer used on a server) =
and there is no one right answer. The best we can do is to use two =
or more independent sources, characterize each source well, =
implement them properly, and design our systems for maximum auditability =
consistent with security.</div><div><br></div><div>There are (at least) =
four reasons we keep having endless discussions about RNG: there are =
many possible solutions, there is no one solution that fits every =
situation, there are no good standards available (NIST SP800-90 =
ducks the hard questions), and people forget what was said =
before. </div><div><br></div><div>Maybe it is time to build a Wiki =
that summarizes cryptography mailing list discussions on this =
and other topics.</div><div><br></div><div><br></div><div>Arnold =
Reinhold</div></div></body></html>=
--Apple-Mail=_2B618E6D-AC43-4CA7-83AE-1B3437268483--
--===============7777540663508663305==
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
--===============7777540663508663305==--
