Re: [Cfrg] On "non-NIST"

Watson Ladd <> Sat, 28 February 2015 23:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C76F51A00A8 for <>; Sat, 28 Feb 2015 15:41:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6stDdxxzznNI for <>; Sat, 28 Feb 2015 15:41:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8FFB1A0097 for <>; Sat, 28 Feb 2015 15:41:23 -0800 (PST)
Received: by ykq19 with SMTP id 19so10346958ykq.4 for <>; Sat, 28 Feb 2015 15:41:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4SXGHn5d8fZoix29MNvY+csfCVhb2BM0ehR+OI5MhJE=; b=uN+/TPwxWa2Hakncbm3J2taR5TceQKqgPCIVTwRyM28tENTUv6iJ4i98MTfioVsuvf bhoYePkbAHvsCneb0r9QeXuYk2GQkhzangSRrYBinnyLQJUXZTXottOEMclGGdWxQptg BRgnEAyuqECEciNK36Pz9oKsfy67O1TmlRqI0x14qQbGzzRkz6VuxmEKa0kU1bI6e4t0 claWaCiPdl7ZnNv4rsCiI8sHs1lHPjHcmFw4634eBpc6+80ew0M4W/lFZeTS6nvQzZHz XmfG+RIY5wyh3QoTYLBRmKWMWWlBvSADXQmcPu4EAVCcrVwLk1o5m0sFlBhoc/p9XSkT 8ucw==
MIME-Version: 1.0
X-Received: by with SMTP id n61mr19407617yhp.44.1425166883011; Sat, 28 Feb 2015 15:41:23 -0800 (PST)
Received: by with HTTP; Sat, 28 Feb 2015 15:41:22 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sat, 28 Feb 2015 15:41:22 -0800
Message-ID: <>
From: Watson Ladd <>
To: Paul Hoffman <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, Peter Gutmann <>
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 23:41:25 -0000

On Sat, Feb 28, 2015 at 9:40 AM, Paul Hoffman <> wrote:
> On Feb 28, 2015, at 9:17 AM, Watson Ladd <> wrote:
>> On Sat, Feb 28, 2015 at 7:41 AM, Paul Hoffman <> wrote:
>>> 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 factually untrue: CMVP certified modules are permitted to
>> implement other algorithms: they just can't be in FIPS mode when those
>> are used.
> That sentence assumes a few things: an HSM that has multiple signing algorithms *and* a lab that would allow non-certified signing algorithms to be within the crypto module that gets the Level 2+ certification *and* the CMVP program allowing the lab's evaluations. To the best of my knowledge, this has never happened. (Disclaimer: NIST once paid me to become an expert on the CMVP process and how crypto vendors and labs dealt with it, but I have not kept my day-to-day knowledge of it up to date in recent years.)
> What you describe is quite common in devices that get Level 1 certifications, but it is not clear that something that normally is expected to have a Level 2+ validation, specifically like HSMs, would be able to do so.

Safenet's Luna SA Network-attached HSM claims FIPS 140-2 Level 3
certification and support Brainpool. Granted, I only know about this
because it's the one Amazon provides and I had occasion to read the

But you're right that somehow we may need HSM and certification. But
this works fine for Brainpool, despite not NIST, and there are
alternatives to FIPS testing for HSMS for use with PKI.

> --Paul Hoffman

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin