[147889] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] /dev/random initialisation
daemon@ATHENA.MIT.EDU (David Johnston)
Wed Oct 30 00:24:37 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 29 Oct 2013 21:09:57 -0700
From: David Johnston <dj@deadhat.com>
To: cryptography@metzdowd.com
In-Reply-To: <8EFE56C8-6C61-40E2-8A90-728EAA3A33A6@gmail.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is a multi-part message in MIME format.
--===============3807682592319234748==
Content-Type: multipart/alternative;
boundary="------------090200030706010402050308"
This is a multi-part message in MIME format.
--------------090200030706010402050308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 10/29/2013 8:59 PM, John Kelsey wrote:
> On Oct 28, 2013, at 5:28 PM, dj@deadhat.com <mailto:dj@deadhat.com> wrote:
>
> ...
>> But the specifications (SP800-90x & FIPS 140-2) make it spectacularly
>> hard
>> to mix in multiple sources in a compliant way. SP800-90 gives a way
>> to mix
>> in "additional entropy" and "personalization strings", but FIPS 140-2
>> states that all sources must be authenticated. All configuring entities
>> must be authenticated. Try authenticating hardware on one end of chip
>> against hardware at the other end of the chip. It is the mother of all
>> chicken and egg problems.
>
> 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.
>
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.
--------------090200030706010402050308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<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>
--------------090200030706010402050308--
--===============3807682592319234748==
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
--===============3807682592319234748==--
