<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/29/2013 8:59 PM, John Kelsey
wrote:<br>
</div>
<blockquote
cite="mid:8EFE56C8-6C61-40E2-8A90-728EAA3A33A6@gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<div>On Oct 28, 2013, at 5:28 PM, <a moz-do-not-send="true"
href="mailto:dj@deadhat.com">dj@deadhat.com</a> wrote:</div>
<div><br>
</div>
<div>...</div>
<blockquote type="cite">
<div><span>But the specifications (SP800-90x & FIPS 140-2)
make it spectacularly hard</span><br>
<span>to mix in multiple sources in a compliant way. SP800-90
gives a way to mix</span><br>
<span>in "additional entropy" and "personalization strings",
but FIPS 140-2</span><br>
<span>states that all sources must be authenticated. All
configuring entities</span><br>
<span>must be authenticated. Try authenticating hardware on
one end of chip</span><br>
<span>against hardware at the other end of the chip. It is the
mother of all</span><br>
<span>chicken and egg problems.</span><br>
</div>
</blockquote>
<div><br>
</div>
<div>Wait, the FIPS labs refuse to let you put your own stuff into
those additional inputs? That's the whole *point* of having
them in the DRBGs. If you call generate with an additional
input that is not guessable to the attacker, starting with a
DRBG state the attacker knows, the DRBG is put into an
unguessable-to-the-attacker state before the output bits are
generated. </div>
<br>
</blockquote>
<br>
But FIPS requires that the inputting entity be authenticated. In a
chip scenario, that is silly. Especially when 'authenticated' means
a FIPS authentication scheme where each on-chip bus attached entity
has to be provisioned a cert by a third party or undergo some
ephemeral key exchange with bignum arithmetic.<br>
<br>
<br>
</body>
</html>