[147946] in cryptography@c2.net mail archive

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

Re: [Cryptography] FIPS 140 testing hurting secure random bit

daemon@ATHENA.MIT.EDU (Paul Hoffman)
Fri Nov 1 13:52:05 2013

X-Original-To: cryptography@metzdowd.com
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <E1VcDaP-0001zF-C7@login01.fos.auckland.ac.nz>
Date: Fri, 1 Nov 2013 08:10:57 -0700
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: John Kelsey <crypto.jmk@gmail.com>,
	Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

On Nov 1, 2013, at 5:12 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:

> Paul Hoffman <paul.hoffman@vpnc.org> writes:
> 
>> - The NIST CMVP people have a reputation (that may or may not be deserved)
>> for taking much longer to validate systems from boat-rockers. I have been
>> told by implementers that their labs explicitly told them not to complain
>> about anything during the 140-3 development process because of this.
> 
> +1 (by "CMVP people" I assume you mean "the labs").

Actually, I meant both the CMVP staff at NIST *and* some of the labs. Both have that reputation (that may or may not be deserved).

>  What the labs apply is
> what they interpret the requirements to be.  Interpretations (it might be more
> appropriate to label them "guesses" in some cases) vary between labs, so that
> something that's OK'd by one lab is rejected by another.  In the worst case,
> two labs can set mutually exclusive requirements.  As an implemeter, your
> options are either (a) do the appropriate silly-walk or (b) escalate the issue
> to NIST.  The latter is sufficiently painful that you'd have to be facing a
> serious showstopper before trying it.
> 
> It's difficult to get people directly involved in this to talk about it in
> public (although many are happy to complain at length in private).  Vendors
> are reluctant to publicly criticise the organisation that they depend on for
> access to government markets.

+1 to all that. When I interviewed about a dozen vendors about CMVP a few years ago, the overall themes were:

a) The way this program is run hurts security, and it would be easy to change it

b) But NIST won't change it because they have no idea about operational security

c) You must not quote me because my lab might rat me out to NIST

There was no differentiation between NIST CMVP and NIST CSD except for maybe two vendors.

--Paul Hoffman
_______________________________________________
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