[148544] in cryptography@c2.net mail archive
Re: [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's
daemon@ATHENA.MIT.EDU (Arnold Reinhold)
Fri Dec 20 16:02:50 2013
X-Original-To: cryptography@metzdowd.com
From: Arnold Reinhold <agr@me.com>
In-reply-to: <1758173.qJugRWNj0J@tauon>
Date: Fri, 20 Dec 2013 15:46:32 -0500
To: Stephan Mueller <smueller@chronox.de>
Cc: John Kelsey <crypto.jmk@gmail.com>, nico@cryptonector.com,
Charles Jackson <clj@jacksons.net>,
Cryptography <cryptography@metzdowd.com>,
Sandy Harris <sandyinchina@gmail.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============9035650093531592149==
Content-type: multipart/alternative;
boundary="Apple-Mail=_4E575D21-142A-402C-8EAF-6658494BCF72"
--Apple-Mail=_4E575D21-142A-402C-8EAF-6658494BCF72
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Dec 19, 2013, at 12:04 PM, Stephan Mueller wrote:
> Am Donnerstag, 19. Dezember 2013, 07:56:36 schrieb Arnold Reinhold:
>=20
> Hi Arnold,
>=20
>=20
>> How do we safely initialize Yarrow or a another software RNG if the
>> CPU's hardware RNG is compromised and there is no other source of
>> entropy? This is a situation that is increasingly common in all
>> solid-state black box devices, and is especially tricky at first
>> startup, when keys used to manage such units are often generated.
>=20
> There are various implementations of RNGs that use CPU execution =
timing=20
> variations as noise source. That phenomenon is available right from =
the=20
> start of the CPU. In fact, the patch in my Jitter RNG [4] for the =
Linux=20
> /dev/random would fill the input_pool with entropy during =
initialization=20
> at system boot time, early in the boot cycle. This could be done for a=20=
> Yarrow as well. I guess the other RNGs could be used in a similar=20
> fashion.
>=20
> So, there are noise sources which do not depend on some black box.
>=20
> [1] http://www.issihosts.com/haveged/
> [2] http://dankaminsky.com/2012/08/15/dakarand/
> [3] http://jytter.blogspot.se/
> [4] http://www.chronox.de/
>=20
>=20
> Ciao
> Stephan
Sandy Harris mentioned one more: =
ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/
I am not able to evaluate these RNG schemes that rely on uncertainties =
in CPU timing. They may well provide a solution, but I am not prepared =
to bet that people who can modify CPU innards, can't find a way to =
defeat them. In section 2.1 of your =
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html you point out some =
possibilities, but say that if an attacker has that much access to the =
CPU, they have other means of compromising your system. That may not be =
true. The beauty of a compromised CPU RNG is that it does not require =
any covert communication from the compromised system back to the =
attacker. =20
As others have said, a billion chip CPU is impossible to audit. Adding =
what I proposed, a key stretcher in the initialization chain of an OS =
RNG like Yarrow or /dev/random, is very simple to do and need only add a =
few seconds to first boot up. The best solution however is still an =
auditable source of randomness independent of the CPU.
Arnold Reinhold=
--Apple-Mail=_4E575D21-142A-402C-8EAF-6658494BCF72
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 19, 2013, at 12:04 PM, Stephan Mueller =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Am Donnerstag, 19. Dezember 2013, 07:56:36 schrieb =
Arnold Reinhold:<br><br>Hi Arnold,<br><br><br><blockquote =
type=3D"cite">How do we safely initialize Yarrow or a another software =
RNG if the<br></blockquote><blockquote type=3D"cite">CPU's hardware RNG =
is compromised and there is no other source =
of<br></blockquote><blockquote type=3D"cite">entropy? This is a =
situation that is increasingly common in all<br></blockquote><blockquote =
type=3D"cite">solid-state black box devices, and is especially tricky at =
first<br></blockquote><blockquote type=3D"cite">startup, when keys used =
to manage such units are often generated.<br></blockquote><br>There are =
various implementations of RNGs that use CPU execution timing =
<br>variations as noise source. That phenomenon is available right from =
the <br>start of the CPU. In fact, the patch in my Jitter RNG [4] for =
the Linux <br>/dev/random would fill the input_pool with entropy during =
initialization <br>at system boot time, early in the boot cycle. This =
could be done for a <br>Yarrow as well. I guess the other RNGs could be =
used in a similar <br>fashion.<br><br>So, there are noise sources which =
do not depend on some black box.<br><br>[1] <a =
href=3D"http://www.issihosts.com/haveged/">http://www.issihosts.com/havege=
d/</a><br>[2] <a =
href=3D"http://dankaminsky.com/2012/08/15/dakarand/">http://dankaminsky.co=
m/2012/08/15/dakarand/</a><br>[3] <a =
href=3D"http://jytter.blogspot.se/">http://jytter.blogspot.se/</a><br>[4] =
<a =
href=3D"http://www.chronox.de/">http://www.chronox.de/</a><br><br><br>Ciao=
<br>Stephan<br></div></blockquote></div><br><div>Sandy Harris mentioned =
one more: <a =
href=3D"ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/">ftp://ftp.cs.sjtu.edu=
.cn:990/sandy/maxwell/</a></div><div><br></div><div>I am not able to =
evaluate these RNG schemes that rely on uncertainties in CPU timing. =
They may well provide a solution, but I am not prepared to bet that =
people who can modify CPU innards, can't find a way to defeat them. In =
section 2.1 of your <a =
href=3D"http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html">http://www.=
chronox.de/jent/doc/CPU-Jitter-NPTRNG.html</a> you point out some =
possibilities, but say that if an attacker has that much access to the =
CPU, they have other means of compromising your system. That may not be =
true. The beauty of a compromised CPU RNG is that it does not require =
any covert communication from the compromised system back to the =
attacker. </div><div><br></div><div>As others have said, a billion =
chip CPU is impossible to audit. Adding what I proposed, a key stretcher =
in the initialization chain of an OS RNG like Yarrow or /dev/random, is =
very simple to do and need only add a few seconds to first boot up. =
The best solution however is still an auditable source of =
randomness independent of the =
CPU.</div><div><br></div><div><br></div><div>Arnold =
Reinhold</div></body></html>=
--Apple-Mail=_4E575D21-142A-402C-8EAF-6658494BCF72--
--===============9035650093531592149==
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
--===============9035650093531592149==--
