Re: [Cfrg] On "non-NIST"

Paul Hoffman <> Sat, 28 February 2015 15:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8A9AD1A1BEF for <>; Sat, 28 Feb 2015 07:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CWNTf_dbJCNL for <>; Sat, 28 Feb 2015 07:41:10 -0800 (PST)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE7BD1A1BEE for <>; Sat, 28 Feb 2015 07:41:10 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.1/8.14.9) with ESMTPSA id t1SFf5P7027567 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2015 08:41:06 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Sat, 28 Feb 2015 07:41:05 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] On "non-NIST"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Feb 2015 15:41:11 -0000

On Feb 28, 2015, at 12:59 AM, Peter Gutmann <> wrote:
> Paul Hoffman <> writes:
>> The term "non-NIST" is predictive, and the crypto community kinda sucks at
>> predictions. We have no idea what NIST will do in the future if a bunch of
>> IETF WGs adopt specific elliptic curves that are not P256/P384.
> Why is NIST seen as the ultimate arbiter of what's appropriate though?  

Not "the", but "an". The reason is that NIST controls what can and cannot be given a FIPS-140 certification, and that certification is considered important both by companies who want to sell to the US Govt and companies that use their certification as a statement that "we did it right". If you make an HSM that uses an algorithm not allowed by NIST, you cannot get it certified in the CMVP regime. Thus, when NIST is slow to keep up with the best practices adopted by the community, it becomes a roadblock to deploying better crypto.

This is why we hope that, when this RG finally moves on both the the curve and the signing algorithm, NIST adds those to its list of acceptable crypto for the FIPS 140 testing. If they don't, people can still deploy it, but deployment will be hampered.

--Paul Hoffman