[Cfrg] Validation performance Re: new curves vs. algorithms

Olafur Gudmundsson <ogud@ogud.com> Fri, 21 March 2014 17:20 UTC

Return-Path: <ogud@ogud.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 9ABEE1A07A0 for <cfrg@ietfa.amsl.com>; Fri, 21 Mar 2014 10:20:13 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ypcU9-R6f1aT for <cfrg@ietfa.amsl.com>; Fri, 21 Mar 2014 10:20:11 -0700 (PDT)
Received: from smtp93.ord1c.emailsrvr.com (smtp93.ord1c.emailsrvr.com [108.166.43.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2B90C1A098A for <Cfrg@irtf.org>; Fri, 21 Mar 2014 10:20:07 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D12A0141AEB for <Cfrg@irtf.org>; Fri, 21 Mar 2014 13:19:57 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A0F3C270024 for <Cfrg@irtf.org>; Fri, 21 Mar 2014 13:19:57 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <52D928A1.6070201@cs.tcd.ie>
Date: Fri, 21 Mar 2014 13:19:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3851D33B-3201-498C-84E1-AAD2FAA0418A@ogud.com>
References: <52D928A1.6070201@cs.tcd.ie>
To: Cfrg@irtf.org
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/XXW564RQLpkeQ06PBOKJu4SkgUU
Subject: [Cfrg] Validation performance Re: new curves vs. algorithms
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, 21 Mar 2014 17:20:13 -0000

While we are it, here is another criteria to keep in mind when designing/recommending new curves. 
This relates to an old question I asked on CFRG in 2006 (wow that is a long time ago) 
in regards to using ECC in DNSSEC 
http://www.ietf.org/mail-archive/web/cfrg/current/msg01170.html

Since then DNSSEC has specified the use of 3 curves P256, P384[RFC6605] and ECC-GOST[RFC5933], 
none of these seems to be in wide spread use, as support is rolling out. 

What we have learned in the mean time (from DNS perspective), is verification time is the most critical part
as the world wants happy eyeballs to work and any microseconds that verification takes add up.
Consider the case that most web pages have in excess of 50 links and many of those are unique
and can not be reused by resolvers/validators. 

Fast signing is nice as that may enable on the fly signing off unique names. 

As for criteria I would propose the following, as starting point for discussion 
	verification time < verification of 2048 bit RSA signature
	signing time      <  signing with 1024  bit RSA key 

As an example comparing here is comparison of 
performance of RSA1024 and 2048 bit keys  vs NIST P256 and P384 on modern hardware, only relative performance should
be derived. 

> OpenSSL> version 
> OpenSSL 1.0.1 14 Mar 2012
> OpenSSL> speed rsa1024 rsa2048 ecdsap256 ecdsap384
> Doing 1024 bit private rsa's for 10s: 38935 1024 bit private RSA's in 9.97s
> Doing 1024 bit public rsa's for 10s: 621683 1024 bit public RSA's in 9.98s
> Doing 2048 bit private rsa's for 10s: 5792 2048 bit private RSA's in 9.98s
> Doing 2048 bit public rsa's for 10s: 187826 2048 bit public RSA's in 9.97s
> Doing 256 bit sign ecdsa's for 10s: 58772 256 bit ECDSA signs in 9.98s 
> Doing 256 bit verify ecdsa's for 10s: 23120 256 bit ECDSA verify in 9.97s
> Doing 384 bit sign ecdsa's for 10s: 34564 384 bit ECDSA signs in 9.97s 
> Doing 384 bit verify ecdsa's for 10s: 7695 384 bit ECDSA verify in 9.98s
> OpenSSL 1.0.1 14 Mar 2012
> built on: Tue Jun  4 07:26:06 UTC 2013
> options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) 
> compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
>                   sign    verify    sign/s verify/s
> rsa 1024 bits 0.000256s 0.000016s   3905.2  62292.9
> rsa 2048 bits 0.001723s 0.000053s    580.4  18839.1
>                               sign    verify    sign/s verify/s
>  256 bit ecdsa (nistp256)   0.0002s   0.0004s   5889.0   2319.0
>  384 bit ecdsa (nistp384)   0.0003s   0.0013s   3466.8    771.0


As you can see these ECC curves verification performance SUCKS big time when we compare smallest sizes. 
I know the RSA code is much more mature than the ECC code but the verification code needs to improve by 25x 
For these curves Signing speeds meets the criteria. 

	Olafur