[147835] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Thu Oct 24 15:31:35 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20131017123257.GA23361@netbook.cypherspace.org>
Date: Thu, 24 Oct 2013 11:16:52 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Adam Back <adam@cypherspace.org>
Cc: Jerry Leichter <leichter@lrw.com>, Cryptography <cryptography@metzdowd.com>,
Sandy Harris <sandyinchina@gmail.com>, Theodore Ts'o <tytso@mit.edu>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============1684746692911999890==
Content-Type: multipart/alternative; boundary=001a11c3db74a7a21b04e97e1f9c
--001a11c3db74a7a21b04e97e1f9c
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 17, 2013 at 8:32 AM, Adam Back <adam@cypherspace.org> wrote:
> On Wed, Oct 16, 2013 at 10:12:14PM -0400, Theodore Ts'o wrote:
>
>> In the Linux Pseudo Random Number Generator Revisited paper
>> (http://eprint.iacr.org/2012/**251.pdf<http://eprint.iacr.org/2012/251.pdf>),
>> the authors sampled and
>> analyzed the various real-life entropy sources, and found the entropy
>> estimation to be pretty good, and if it erred, it erred on the side of
>> convervatism, which is as designed.
>>
>
> I think the more worrying case is a freshly imaged rack mount server,
> immediately generating keys or outputting random numbers to the network or
> in response to network queries.
>
+1
And I have not seen any proposal that is really going to solve this
particular problem in the thread since.
If I was asked three months ago my position would be 'generate the keys on
the device that is going to use them and they never leave unless it is a
really constrained device like a credit card.'
I have completely changed my mind on this. I now think public keys should
be generated in device adapted for that purpose and migrated out using some
form of secure protocol that ensures only the intended device can use them.
Further, the scheme used should provide the devices with a unique random
seed that can be used as a backstop against compromise or failure of other
RNGs. Using a stream cipher is not a very good RNG but nothing bad can
happen by XORing a good but brittle RNG against the output of a completely
independent cipherstream.
--
Website: http://hallambaker.com/
--001a11c3db74a7a21b04e97e1f9c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Oct 17, 2013 at 8:32 AM, Adam Back <span dir=3D"lt=
r"><<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyphe=
rspace.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, Oct 16, 2013 at 10=
:12:14PM -0400, Theodore Ts'o wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In the Linux Pseudo Random Number Generator Revisited paper<br>
(<a href=3D"http://eprint.iacr.org/2012/251.pdf" target=3D"_blank">http://e=
print.iacr.org/2012/<u></u>251.pdf</a>), the authors sampled and<br>
analyzed the various real-life entropy sources, and found the entropy<br>
estimation to be pretty good, and if it erred, it erred on the side of<br>
convervatism, which is as designed. =A0<br>
</blockquote>
<br></div>
I think the more worrying case is a freshly imaged rack mount server,<br>
immediately generating keys or outputting random numbers to the network or<=
br>
in response to network queries.<br></blockquote><div><br></div><div>+1</div=
><div><br></div><div>And I have not seen any proposal that is really going =
to solve this particular problem in the thread since.</div><div><br></div>
<div>If I was asked three months ago my position would be 'generate the=
keys on the device that is going to use them and they never leave unless i=
t is a really constrained device like a credit card.'</div><div><br>
</div><div>I have completely changed my mind on this. I now think public ke=
ys should be generated in device adapted for that purpose and migrated out =
using some form of secure protocol that ensures only the intended device ca=
n use them.=A0</div>
<div><br></div></div><div><br></div><div>Further, the scheme used should pr=
ovide the devices with a unique random seed that can be used as a backstop =
against compromise or failure of other RNGs. Using a stream cipher is not a=
very good RNG but nothing bad can happen by XORing a good but brittle RNG =
against the output of a completely independent cipherstream.</div>
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>
--001a11c3db74a7a21b04e97e1f9c--
--===============1684746692911999890==
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
--===============1684746692911999890==--
