Re: [Cfrg] I-D Action: draft-kasamatsu-bncurves-00.txt

Mike Hamburg <mike@shiftleft.org> Wed, 29 January 2014 18:31 UTC

Return-Path: <mike@shiftleft.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 6B93C1A029B for <cfrg@ietfa.amsl.com>; Wed, 29 Jan 2014 10:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.455
X-Spam-Level: ***
X-Spam-Status: No, score=3.455 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no
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 YKxCzY30mVIX for <cfrg@ietfa.amsl.com>; Wed, 29 Jan 2014 10:31:54 -0800 (PST)
Received: from aspartame.shiftleft.org (199-116-74-157-v301.PUBLIC.monkeybrains.net [199.116.74.157]) by ietfa.amsl.com (Postfix) with ESMTP id E43551A021B for <cfrg@irtf.org>; Wed, 29 Jan 2014 10:31:54 -0800 (PST)
Received: from [192.168.1.147] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 0C15C3AA03; Wed, 29 Jan 2014 10:29:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1391020152; bh=K5JacAP/uhs6K/zjYxG2WY1bcZms0CSPfZrtx/me7YM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OmKEmr15ksND+W+c6Qr0qWjE8F9jxc3ns/ZqgncF1PeLAAaJkkJwfNvEaKue8NMBy I/GRJT1BXLO4aw2u9gxK/dBCPeiN3STwULnmV7337oDDPsrdnkU4LjfWkaN2YDL/+z 9IMgcebQnjz8OicWENcyeAxRqSkwxvGYPORk1xno=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Mike Hamburg <mike@shiftleft.org>
In-Reply-To: <52E8DF9D.5070106@po.ntts.co.jp>
Date: Wed, 29 Jan 2014 10:31:50 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C75DEAE1-9E26-443B-8D5B-8C2610F59E96@shiftleft.org>
References: <20140110051303.25816.17055.idtracker@ietfa.amsl.com> <52E05C7C.2030400@po.ntts.co.jp> <2A62E87D-89CF-47E9-A0A2-F213F6D079BE@shiftleft.org> <52E8DF9D.5070106@po.ntts.co.jp>
To: Kohei Kasamatsu <kasamatsu.kohei@po.ntts.co.jp>
X-Mailer: Apple Mail (2.1827)
Cc: kobayashi.tetsutaro@lab.ntt.co.jp, kawahara.yuto@lab.ntt.co.jp, cfrg@irtf.org
Subject: Re: [Cfrg] I-D Action: draft-kasamatsu-bncurves-00.txt
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, 29 Jan 2014 18:31:56 -0000

On Jan 29, 2014, at 3:01 AM, Kohei Kasamatsu <kasamatsu.kohei@po.ntts.co.jp> wrote:

>> But isn’t 512 bits rather large for a BN curve?  If you’re going to
>> have a curve that large, it seems to me that you’d want an embedding
>> degree of at least 18 even though it costs you a giant cofactor.  A
>> curve with a 512-bit prime and a 384-bit subgroup might get you to
>> the 192-bit security level.  This would take a 640-bit BN curve at
>> minimum, with 720 a more conservative guess.
>> 
>> Source: Freeman 2006, http://eprint.iacr.org/2006/372.pdf.  My
>> knowledge on this subject is dated, so I’m sure you know better...
> 
> Thank you for your comments and information on security of our memo.
> 
> Our memo specifies parameters for compatibility with ISO/IEC document and parameters for high performance. 512-bit curve and 384-bit curves which are compliant with ISO/IEC have 128 security levels because of the following reason.
> ...
> If there are parameters of bn-curves with higher security level and high performance, we would like to add it into our memo.


There are no such BN curves.  I just don't expect that most implementers will consider using a 512-bit BN curve, because at that size a non-BN curve with k=18 or k=24 has a better trade-off of security vs performance.  But I suppose that such curves might not be ISO/IEC compliant, because of their cofactors.

Cheers,
-- Mike