IETF Logo Mail Archive

Re: [Cfrg] On "non-NIST"

stephen.farrell@cs.tcd.ie Wed, 25 February 2015 18:38 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBB71A1B9A for <cfrg@ietfa.amsl.com>; Wed, 25 Feb 2015 10:38:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox5Y0ErOcwFQ for <cfrg@ietfa.amsl.com>; Wed, 25 Feb 2015 10:38:17 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D621A1B96 for <cfrg@irtf.org>; Wed, 25 Feb 2015 10:38:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 64F01BE5C; Wed, 25 Feb 2015 18:38:15 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-eAmizQdQSm; Wed, 25 Feb 2015 18:38:14 +0000 (GMT)
Received: from [127.0.0.1] (unknown [86.41.57.139]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4758BBE56; Wed, 25 Feb 2015 18:38:14 +0000 (GMT)
X-Priority: 3
To: paul.hoffman@vpnc.org
From: stephen.farrell@cs.tcd.ie
In-Reply-To: <D02DF679-9485-467F-A47C-FFF15139278B@vpnc.org>
References: <54EDDBEE.5060904@isode.com> <54EDEE67.1010102@cs.tcd.ie> <D02DF679-9485-467F-A47C-FFF15139278B@vpnc.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 25 Feb 2015 18:38:11 +0000
Message-ID: <q0xidr.nkcbrp.2vaesh-qmf@mercury.scss.tcd.ie>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/1MToExr71IbOyRifkgNN646OKbU>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] On "non-NIST"
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2015 18:38:18 -0000


On Wed Feb 25 18:05:47 2015 GMT, Paul Hoffman wrote:
> On Feb 25, 2015, at 7:46 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> > I do "prefer" that CFRG document only one of those as being
> > the usual non-NIST choice for >128 bit work factor.
> 
> 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. Unfortunately, I suspect current NIST folks also have no idea what NIST will do in that case either. In the past, NIST has sometimes (but not always) responded to pressure from the real world about crypto algorithms and modes; let's hope for the best here.

Sure, I agree it'd be good if NIST also annoint the output from this cfrg process. But right now non-NIST is the correct distinguishing term for what I meant. I see no reason that term will be needed in an RFC though if that helps assuage some sensitivity somewhere in the universe :-)

S.


> 
> --Paul Hoffma

v2.20.3 | Report a Bug | By Email