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

_MiW <miwmailing@gmail.com> Tue, 24 February 2015 11:13 UTC

Return-Path: <miwmailing@gmail.com>
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 97FBA1A07BD for <cfrg@ietfa.amsl.com>; Tue, 24 Feb 2015 03:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.654
X-Spam-Level: *
X-Spam-Status: No, score=1.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, US_DOLLARS_3=1.754] 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 F-nOwGFb7bN7 for <cfrg@ietfa.amsl.com>; Tue, 24 Feb 2015 03:13:13 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128FB1A0673 for <cfrg@irtf.org>; Tue, 24 Feb 2015 03:13:13 -0800 (PST)
Received: by paceu11 with SMTP id eu11so35246463pac.10 for <cfrg@irtf.org>; Tue, 24 Feb 2015 03:13:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=m4G/dv7c5o+fDOQJ01EZebN1c8QCmbREbA3Q5+4UA0c=; b=TvNTXMXqB7WGZDaqyz9lvjaP5p/lW6xY9dVhn/U0oSw2suMLM0usqVoyvoT+V0H8gB T1iVHF2VGB0wKnjsGTWU/RDoFRMsEUC06dlzzaYGxl3+GNPFg/sX5wPz3jnyag7x84YV 7WD1ty6G13hV6vjAmMHLgRXpp/6fgPsLRJmwdLIhRQenjTYUdNWCajc9m9j5F/aY7juY gaQba0EUWzASUQvhpIanD1tcyd/AsmIbRKqf0Sw9+a+pSAvxuMf5hEjUF1vUzQy0yDXw lU6LmUbwFv05yUPV4TyT3E+PIWXNQh5PP/3gwsgSE+H3yYwPQulmxO/f1eNiW/rSsRdx RraA==
X-Received: by 10.66.124.225 with SMTP id ml1mr27929983pab.142.1424776391120; Tue, 24 Feb 2015 03:13:11 -0800 (PST)
Received: from [192.168.1.25] (ppp118-210-227-32.lns20.adl6.internode.on.net. [118.210.227.32]) by mx.google.com with ESMTPSA id ot6sm32694279pdb.28.2015.02.24.03.13.09 for <cfrg@irtf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 03:13:10 -0800 (PST)
Message-ID: <54EC5CC2.7090100@gmail.com>
Date: Tue, 24 Feb 2015 21:43:06 +1030
From: _MiW <miwmailing@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <54E46EA4.9010002@isode.com>
In-Reply-To: <54E46EA4.9010002@isode.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/JPhroUIUXLJNlZJfgJTFFu1crqw>
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: Tue, 24 Feb 2015 11:13:14 -0000

Q3: Yes.

A little extra uncompressed/compressed prime curve slight above 512
(1024b public key) is negligible cost difference to store and send in
the grand scheme of things.
It is after the end date but I wanted to contribute, at least because
there was no post interpreting the question as a monetary cost for data.
djb's answer in Subject: [Cfrg] network traffic
<20150223032102.23370.qmail@cr.yp.to> was awesome and inspired me to
post these scratchings.
The poll form is cool and I have been enjoying peoples responses.

These are fuzzy Fermi Equations :-) The total number of keys is going to
increase as humans engage in more cryptosystems. 10k xchg wtf? also
machines.

Early 2015.
Yearly key rotation, so cost are per annum and will decrease over time
as rest and transit costs decrease per GB.
Only raw key material considered, not cert or key meta (which is in the
order of kilobytes per key) but is mostly constant between key sizes.

Data at Rest cost per GB SSD:    0.40    $/GB
Data at Rest cost per GB HDD:    0.03    $/GB
Data in Transit cost per GB:    0.04    $/GB
Earth humans:    7000000000    persons
x keys per person    50   
key size    512 bits   
Total keys for people    350000000000   
Bytes to store every humans 50 private keys @ key size EC:   
22400000000000   
Bytes to store every humans 50 public keys (x2) @ key size EC:   
44800000000000   
GB of public keys    41723.25   
GB of private keys    20861.63   
Lifetime Key transfers    10000   
Cost to store on SSD    $16,689.30   
Cost to store on HDD    $1,251.70   
Cost to transmit every key lifetime_transfer_n times    $16,689,300.54   

Now we consume 66 bytes for our private key in secp521r1, but log2(521)
= 65.125 so we are wasting 7 bits we could use
for no additional cost at the data layer.
So our range of primes is for same cost as secp521r1 is 2^528 but I
don’t know of any at this size.

Even a modest 5% key size increase over 512b is going to cost us
something like $800 extra to store on SSD's and
$800,000 to transfer over the life of all the keys per year somewhat
divided up among all players.
Totally worth it in my opinion.

Thanks for reading,
_MiW


On 18/02/2015 9:21 PM, Alexey Melnikov wrote:
> CFRG chairs are starting another poll:
>
> 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?
>
>
> Once this issues is settled, we will be discussing implementation 
> specifics and coordinate systems for Diffie-Hellman. We will then make 
> decisions on signature schemes. Please don't discuss any of these future 
> topics at this time.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>