[147891] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] /dev/random initialisation
daemon@ATHENA.MIT.EDU (ianG)
Wed Oct 30 13:41:43 2013
X-Original-To: cryptography@metzdowd.com
Date: Wed, 30 Oct 2013 15:29:12 +0300
From: ianG <iang@iang.org>
To: cryptography@metzdowd.com
In-Reply-To: <52708695.8060402@deadhat.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 30/10/13 07:09 AM, David Johnston wrote:
> 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.
Bingo. 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.
Do we see a multi-phase approach here?
1. Limit the sources to FIPS-authenticated inputs.
2. Limit the number of sources that can be used.
3. Do a deal with all major suppliers of FIPS-authenticated inputs.
4. Profit.
This is looking like the same multi-pronged strategy that sunk DRBG_EC.
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
