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

Kohei Kasamatsu <kasamatsu.kohei@po.ntts.co.jp> Tue, 04 February 2014 09:30 UTC

Return-Path: <kasamatsu.kohei@po.ntts.co.jp>
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 AFB5A1A03D4 for <cfrg@ietfa.amsl.com>; Tue, 4 Feb 2014 01:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.972
X-Spam-Level: *
X-Spam-Status: No, score=1.972 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.535, 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 Hn_xtK1ZIE0s for <cfrg@ietfa.amsl.com>; Tue, 4 Feb 2014 01:30:36 -0800 (PST)
Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id AB2021A03C7 for <cfrg@irtf.org>; Tue, 4 Feb 2014 01:30:36 -0800 (PST)
Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.14.4/NTTSOFT) with ESMTP id s149UZ4p006587; Tue, 4 Feb 2014 18:30:35 +0900 (JST)
Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id s149UZni014099; Tue, 4 Feb 2014 18:30:35 +0900 (JST)
Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id UAA14098; Tue, 4 Feb 2014 18:30:35 +0900
Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id s149UZlu022933; Tue, 4 Feb 2014 18:30:35 +0900
Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id s149UX6c001874; Tue, 4 Feb 2014 18:30:33 +0900
Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id s149UXuB001871; Tue, 4 Feb 2014 18:30:33 +0900
Message-ID: <52F0B309.8090000@po.ntts.co.jp>
Date: Tue, 04 Feb 2014 18:29:45 +0900
From: Kohei Kasamatsu <kasamatsu.kohei@po.ntts.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Mike Hamburg <mike@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> <C75DEAE1-9E26-443B-8D5B-8C2610F59E96@shiftleft.org>
In-Reply-To: <C75DEAE1-9E26-443B-8D5B-8C2610F59E96@shiftleft.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ccmds32.silk.ntts.co.jp id s149UZlu022933
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: Tue, 04 Feb 2014 09:30:38 -0000

Hi Mike,


Thank you for your comments.

> 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.

I misunderstood your intentions.

I also think it is better that we use non-BN curve with k=18 or k=24
if we need more higher security than 128-bit.
(For example, the comparison of [1] supports it:-) )

On the other hands, our I-D focuses on BN-curves, as you understand.
I hope new I-Ds which are submitted in the future will achieve the
requirement which you pointed out and such activities will become active.

And, although I also don't expect that most implementers will consider 
using a 512-bit BN curves which are specified in our I-D, we think it is 
valuable to provide parameters and additional information (on security 
and differences between M-type and D-type) of curves with international 
standard.

[1]  http://eprint.iacr.org/2012/232

Cheers,
Kohei KASAMATSU

(2014/01/30 3:31), Mike Hamburg wrote:
>
> 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
>
>
>


-- 
Kohei KASAMATSU

NTT Software Corporation
TEL: +81 45 212 7908 FAX: +81 45 212 9800
E-mail: kasamatsu.kohei@po.ntts.co.jp