Re: [Cfrg] When's the decision?

Mike Hamburg <> Thu, 09 October 2014 06:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F04A1A9114 for <>; Wed, 8 Oct 2014 23:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.555
X-Spam-Level: *
X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y2gPgbXWIp1f for <>; Wed, 8 Oct 2014 23:43:03 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7728C1A9113 for <>; Wed, 8 Oct 2014 23:43:03 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8300FF2208; Wed, 8 Oct 2014 23:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1412836896; bh=J1qij6Oku2wiCFUzVlYJV1kqV9/cZFnlvzWhm9OPQmQ=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=XgStZqHD78RaWJB4e2x+2Nzx/KQNYw5SV8oQWqlKdOEmbc9KFkKFuLf8KhWAV39O9 ANglWvCcp1DdQygCuJnnnhY3O6sfZL9kHe+DEV192PXphIAeM/zP8jcswmEszKsPxz hKI6Gf2gJ6Sv2c7U5FPv85rbdI4YjxQo4AP/xoVo=
Message-ID: <>
Date: Wed, 08 Oct 2014 23:43:01 -0700
From: Mike Hamburg <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [Cfrg] When's the decision?
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: Thu, 09 Oct 2014 06:43:04 -0000

On 10/8/2014 10:20 PM, Phillip Hallam-Baker wrote:
> On Wed, Oct 8, 2014 at 11:42 PM, Mike Hamburg <> wrote:
>> This is basically the point of Ed448-Goldilocks.  It's received a mixed
>> response in this forum, since some people would prefer the most constrained
>> curve, for some definition of "constrained" which doesn't consider
>> performance.
> I am happy to consider performance but only if the differences are
> large and consistent.
> This is not a competition where more is better. I don't want more than
> exactly one high strength curve and exactly one exceptionally high
> curve. I don't want to see any options or parameters either. Either we
> are all doing the twist again or nobody is. Either we are all doing
> compression or not.
I agree, which is why I prefer "NUMS but untwisted" over the current 
NUMS.  Everyone else avoided specifying twisted curves because of the 
incomplete addition formulas.
> And if there isn't a clear basis for a decision we can throw darts.
> Some performance issues are show stoppers. Anything that is not less
> than a clean multiple of a power of 2 is going to cause severe
> performance hits on future architectures. 512 bit memory buses are
> common in graphics cards, 521 bit buses are not.
Maybe.  It depends what's the limiting factor in the algorithm.  It 
might not be the memory bus.
> If ED448 is twice as fast as the exactly 512 bit curve then there is a
> decisive performance advantage. Anything less than 20% is noise.
Ed448 is about twice as fast as ed-512-mers, and about 6% slower than 
ed-384-mers using currently published implementations.  That is, using 
the last round of benchmarks I took on my SBR machine before selling it, 
and the published NUMS numbers.

The footing is surely not entirely even.  The Ed448 software uses a 
Montgomery ladder for ECDH and has a unified compressed point format, 
whereas MS ECCLib uses fixed-window Edwards with no point compression.  
Ed448 uses vectorized Karatsuba with C+asm as its lowest level (except 
on NEON where it's basically all asm), and ECCLib uses Comba in all 
asm.  They're benchmarked on different platforms with different loops.  
And so on.

Ed448 also has a pretty efficient ARM NEON implementation.  I believe it 
will have a larger advantage over NUMS on that platform, because I kept 
32-bit vector performance in mind when designing it.
> The point is elimination, to vote people off the island so we can have
> a winner, not to get more people in.
Sounds like a plan.

-- Mike