IETF Logo Mail Archive

Re: [Cfrg] Elliptic Curves - poll on specific curve around 256bit work factor (ends on February 23rd)

Jon Callas <jon@callas.org> Fri, 20 February 2015 23:32 UTC

Return-Path: <jon@callas.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 964D01A0155 for <cfrg@ietfa.amsl.com>; Fri, 20 Feb 2015 15:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Qu3rsRTEYT99 for <cfrg@ietfa.amsl.com>; Fri, 20 Feb 2015 15:32:55 -0800 (PST)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAA11A017D for <cfrg@irtf.org>; Fri, 20 Feb 2015 15:32:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 971C069FBCCC for <cfrg@irtf.org>; Fri, 20 Feb 2015 15:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD-icVNU+1+M for <cfrg@irtf.org>; Fri, 20 Feb 2015 15:32:23 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 30B9B69FBCAA for <cfrg@irtf.org>; Fri, 20 Feb 2015 15:32:23 -0800 (PST)
Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 20 Feb 2015 15:32:23 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 20 Feb 2015 15:32:23 -0800
From: Jon Callas <jon@callas.org>
Message-Id: <756326C8-8B1A-4B48-9CF3-01FD99506400@callas.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Fri, 20 Feb 2015 15:32:21 -0800
References: <54E46EA4.9010002@isode.com> <CAHOTMVKCD+DK6QbSuy8R63FVnu_WBNmwMvByqicx=sK6_k63HQ@mail.gmail.com> <D10CAF3B.3F266%kenny.paterson@rhul.ac.uk> <CAMm+Lwhj9H_NK22QbTB7=EFd7GBg0WprwRMN8RxH3+7r_buf7g@mail.gmail.com> <CACsn0c=eqcXm+ir75Qm9PvP5QhdZf_kfVYn2sE-mcHwNtqbP7A@mail.gmail.com> <8B1CC23A-EF57-44D5-BBA2-4BA6C6E21B83@shiftleft.org> <CAHOTMVL7m=J+QRyEnx8uj7dGp+nOfoErUGcXB5Nc6N4+ekXWCg@mail.gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
In-Reply-To: <CAHOTMVL7m=J+QRyEnx8uj7dGp+nOfoErUGcXB5Nc6N4+ekXWCg@mail.gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-PGP-Encoding-Format: MIME
X-PGP-Encoding-Version: 2.0.2
Content-Type: multipart/signed; boundary="PGP_Universal_8475C693_7585A20B_8CCC6A52_473954CC"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/P9bca7Ar58013RhizgPJWxJ6ccU>
Subject: Re: [Cfrg] Elliptic Curves - poll on specific curve around 256bit work factor (ends on February 23rd)
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: Fri, 20 Feb 2015 23:32:57 -0000

The actual question as it appears to be in the poll is, I believe:

Q3: (For people who want CFRG to recommend a curve at 256bit level) Is bandwidth cost of going to p521 worth the speed win over primes closer to 512 bits?

No.

Explanation:

I have a great need for over 128 bits of security. The specific security level is not exact. Until recently, P-384 was my compromise and chosen because it was what was available. 521 is inherently slow because it's greater than 512 and that has issues into the hardware. 414 is good enough security with ~205 bits of security and fast enough, even in naive implementations.

Alternate sizes -- 389, 448, 480, 512, etc. even 379 are all good enough from a security standpoint. At this point, we're looking at considerations of code speed, code size, etc.

I've explained why I've picked 414 as secure enough and fast enough.

	Jon

v2.23.0 | Report a Bug | By Email