Re: [Cfrg] Benchmarks: 384 vs 389 vs Goldilocks vs ... on Haswell

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Sat, 03 January 2015 18:16 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 C72B81A912A for <cfrg@ietfa.amsl.com>; Sat, 3 Jan 2015 10:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 fnm3lqkg9VS6 for <cfrg@ietfa.amsl.com>; Sat, 3 Jan 2015 10:16:22 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0642.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA1B1A1BB3 for <cfrg@irtf.org>; Sat, 3 Jan 2015 10:16:21 -0800 (PST)
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.1.49.12; Sat, 3 Jan 2015 18:15:57 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0049.002; Sat, 3 Jan 2015 18:15:57 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [Cfrg] Benchmarks: 384 vs 389 vs Goldilocks vs ... on Haswell
Thread-Index: AQHQI701KGpxET6GdkKNiBIGv4KjYZyqIa6AgAAQ24CABIibgA==
Date: Sat, 3 Jan 2015 18:15:57 +0000
Message-ID: <D0CDB6A2.3B631%kenny.paterson@rhul.ac.uk>
References: <54A1E049.9000404@shiftleft.org> <D0CA0568.3B27A%kenny.paterson@rhul.ac.uk> <CACsn0cnyWY7Z1iK09zwEmfsH1v5zt3H1W7hZfqFabQb8tN3a8A@mail.gmail.com>
In-Reply-To: <CACsn0cnyWY7Z1iK09zwEmfsH1v5zt3H1W7hZfqFabQb8tN3a8A@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [78.146.61.145]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk;
x-dmarcaction: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR03MB383;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB383;
x-forefront-prvs: 0445A82F82
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(43784003)(377454003)(189002)(479174004)(199003)(51704005)(19580395003)(87936001)(2656002)(110136001)(21056001)(122556002)(19580405001)(106116001)(76176999)(64706001)(101416001)(105586002)(50986999)(31966008)(99396003)(2900100001)(36756003)(83506001)(62966003)(102836002)(106356001)(77096005)(107046002)(40100003)(74482002)(120916001)(46102003)(68736005)(1411001)(20776003)(77156002)(97736003)(4396001)(66066001)(86362001)(2950100001)(92566001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3950C80D210E184F91D792EC3EC1CFEE@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2015 18:15:57.7058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB383
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/10Sdp1AjnyUUoP87fnsMvWe6RNI
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Benchmarks: 384 vs 389 vs Goldilocks vs ... on Haswell
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: Sat, 03 Jan 2015 18:16:25 -0000

Hi Watson,

Following up on a recent message that specifically asked a question to me.

On 31/12/2014 21:01, "Watson Ladd" <watsonbladd@gmail.com>; wrote:

>On Wed, Dec 31, 2014 at 3:01 PM, Paterson, Kenny
><Kenny.Paterson@rhul.ac.uk>; wrote:
>> Hi Mike,
>>
>> Thanks a lot for doing this work, especially over the holiday season -
>> it's much appreciated.
>>
>> My take-away from your work is that there's no strong reason (in
>> performance terms) to prefer P389 over P384-mers or vice-versa - the
>>8-9%
>> difference is there, yes, but could easily disappear or increase with
>> further optimisations on either side.
>
>Would you say the same about 2^255-19 vs 2^256-189? That also had a 8%
>performance increase iirc, for very similar reasons.

Yes, I would. But there, we have running code and deployment in favour of
the curve Curve25519 (used in various algorithms which may or may not be
the ones we want to recommend - still tbd). That's not the case at WF192.

> One could also try 2^382-31, which would be much more similar to the
>gain at the lower security level.

"One" could try many things. But someone has to do the work to implement
and benchmark. I asked Mike to do some work here, because he had the tools
at his disposal, and he very kindly agreed to help - thanks again Mike. In
the interests of making progress, I'd encourage others to do more of the
same.

>Furthermore, if the faster one was more optimized, and the slower one
>not as much, that would be a reasonable conclusion. But we are
>comparing a C implementation written yesterday to a handwritten
>assembler one, with the C outperforming the assembly.

Yes, I'm aware of this. And so, like you (I infer), I'd expect the
currently faster one to improve more and the gap to widen further.

Cheers,

Kenny