[148110] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] SP800-90A B & C

daemon@ATHENA.MIT.EDU (John Kelsey)
Mon Nov 11 17:40:24 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <527FF917.30307@deadhat.com>
From: John Kelsey <crypto.jmk@gmail.com>
Date: Mon, 11 Nov 2013 13:58:49 -0500
To: David Johnston <dj@deadhat.com>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

On Nov 10, 2013, at 4:22 PM, David Johnston <dj@deadhat.com> wrote:

...
> Some of my comments were about the way the spec and FIPS make it hard to add multiple sources. I would like to enable users to add their own trusted sources so they can ensure randomness is robust.

There are two separate issues here:

a.  Allowing additional input that's not credited with entropy, but which may add security.  
b.  Allowing the combination of two or more approved, validated entropy sources.

I'm still not sure where we run into problems with (a) (there's some 140-2 guidance that requires callers of RNGs to be authenticated at higher validation levels--that may cause problems), and at least so far I don't have an actual example of a FIPS lab refusing to allow a 90A DRBG to use additional input from an off-module unauthenticated source, (if you have one, please let me know) but I think this is something we can address in guidance on 90A.  

Dealing with (b) is going to have to wait for 90C to be finished.  It's relatively easy to allow this for entropy sources that live within some kind of separate boundaries, but not for entropy sources that have access to the same physical processes or internal state.  But combining independent entropy sources is something that should make it into 90C.  

As an aside, most of the content of 90A, B, and C *did* go through a normal standardization process in X9F1.  And since then, we've had a public workshop and a couple rounds of public comment, trying to hammer out things that might cause problems.  So I'm not sure if this is a normal standards process, but it sure is allowing for a fair bit of public comment.   

--John
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post