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

"Paterson, Kenny" <> Sat, 03 January 2015 18:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C72B81A912A for <>; Sat, 3 Jan 2015 10:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fnm3lqkg9VS6 for <>; Sat, 3 Jan 2015 10:16:22 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe00::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FA1B1A1BB3 for <>; Sat, 3 Jan 2015 10:16:21 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 3 Jan 2015 18:15:57 +0000
Received: from ([]) by ([]) with mapi id 15.01.0049.002; Sat, 3 Jan 2015 18:15:57 +0000
From: "Paterson, Kenny" <>
To: Watson Ladd <>
Thread-Topic: [Cfrg] Benchmarks: 384 vs 389 vs Goldilocks vs ... on Haswell
Thread-Index: AQHQI701KGpxET6GdkKNiBIGv4KjYZyqIa6AgAAQ24CABIibgA==
Date: Sat, 03 Jan 2015 18:15:57 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
authentication-results: spf=none (sender IP is );
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;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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
Cc: "" <>
Subject: Re: [Cfrg] Benchmarks: 384 vs 389 vs Goldilocks vs ... on Haswell
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" <> wrote:

>On Wed, Dec 31, 2014 at 3:01 PM, Paterson, Kenny
><> 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
>> 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

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