Re: [Cfrg] big-endian short-Weierstrass please

Andrey Jivsov <crypto@brainhub.org> Sun, 01 February 2015 07:32 UTC

Return-Path: <crypto@brainhub.org>
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 95ABB1A874D for <cfrg@ietfa.amsl.com>; Sat, 31 Jan 2015 23:32:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] 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 Vzmze5s_V6OJ for <cfrg@ietfa.amsl.com>; Sat, 31 Jan 2015 23:32:20 -0800 (PST)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05381A8749 for <cfrg@irtf.org>; Sat, 31 Jan 2015 23:32:20 -0800 (PST)
Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-04v.sys.comcast.net with comcast id mvYK1p0014ueUHc01vYKDp; Sun, 01 Feb 2015 07:32:19 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-03v.sys.comcast.net with comcast id mvYJ1p0074uhcbK01vYJcq; Sun, 01 Feb 2015 07:32:19 +0000
Message-ID: <54CDD682.9050503@brainhub.org>
Date: Sat, 31 Jan 2015 23:32:18 -0800
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net> <87386ug2r7.fsf@alice.fifthhorseman.net> <810C31990B57ED40B2062BA10D43FBF5D4413B@XMB116CNC.rim.net> <87r3ueedx7.fsf@alice.fifthhorseman.net> <CAMm+Lwj6eG_KAhb-r5QrDeui7w8AoSN=71X8ywEyn9jj0rALQg@mail.gmail.com> <54C9DD8E.9040302@akr.io> <54CA0591.3070308@cs.tcd.ie> <CAMm+Lwi5skMnsaPxSzdVmDtHTjjGPRJ54xpaF8GL84ihMHePrA@mail.gmail.com>
In-Reply-To: <CAMm+Lwi5skMnsaPxSzdVmDtHTjjGPRJ54xpaF8GL84ihMHePrA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1422775939; bh=WSfttU+3VnuRHvv0SAxGA3eZaow1a+e2PoFzzt4bJWs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VlaxZfvHB+TMkAdNa1ftk5e22WZCnzI97DlhQvx9joTYYSl4nsdZY/m1+n0Mu3y3k mxbrANfEMXuARx2sIv1Rwdt0k/3SgqZGCe55w+nyloVIIe2hxM7hH7hWQdPwkjvG2o i5oam0VzWYQ8SLWUqHERIE4O32Q3PlXzedjdMQpAYXo8MYQ8BmqqgOESpjH1LDGFRj P2OJSHUWeYtG3XFBmsBDVDRaHCwBEVvJQrd1R8VAVvP78xVemH2uDDhNrsUwVOU1dx dn1xN1hPhjzuSVeNXwvKbPkI+vuhZwaVpI/v4rqstfg+DPr9/73c8IVA5sRlT6XAg6 lqG7oNWNn+GxQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/AypgF-bvE7fNVLawdebaap249Z8>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
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: Sun, 01 Feb 2015 07:32:22 -0000

On 01/29/2015 05:21 AM, Phillip Hallam-Baker wrote:
> So by FIPS-140 equivalent, what is meant is something that we can get a
> group of experts to agree is equivalent and safe. It probably means that
> the hardware is certified FIPS-140 but not necessarily for the
> particular algorithm. This may or may not require wording changes but I
> don't expect they would be controversial.

Unless the new curve is accepted along the lines of P-256 by NIST, it 
will be treated no much differently than CAMELIA (or DES).

Without this change, the new curve is a Non-Approved security function 
and it can only be used in non-Approved modes of operation. Crypto 
module documentation will need to make this clear, per FIPS 140-2.

It's a known trick to certify only AES and then somehow make an 
impression that other algorithms are covered by the same module. NIST 
put multiple notes to make this harder. Thus, NIST will need to 
explicitly bless the new curve. A precedent for this is the TLS KDF.