Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]

Tanja Lange <> Tue, 23 December 2014 01:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51FBE1ACC8A for <>; Mon, 22 Dec 2014 17:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.895
X-Spam-Level: **
X-Spam-Status: No, score=2.895 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 32UfGslT2iSi for <>; Mon, 22 Dec 2014 17:54:28 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 78E4E1ACC84 for <>; Mon, 22 Dec 2014 17:54:28 -0800 (PST)
Received: (qmail 13075 invoked from network); 23 Dec 2014 01:54:46 -0000
Received: from (HELO ( by with SMTP; 23 Dec 2014 01:54:46 -0000
Received: (qmail 31207 invoked by uid 1000); 23 Dec 2014 01:54:30 -0000
Date: Tue, 23 Dec 2014 02:54:30 +0100
From: Tanja Lange <>
To: "Paterson, Kenny" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.11
Cc: "" <>
Subject: Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]
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: Tue, 23 Dec 2014 01:54:30 -0000

Dear Kenny,
This is a late reply to your reply to Watson. 

> >> >* Adoption of draft-black-rpgecc-00 would reward its authors, both by
> >> >  crediting them as authors of CFRG's resulting document and by giving
> >> >  them greater control over CFRG's product.  It is inappropriate for
> >> >  IETF to reward the authors of draft-black-rpgecc-00 for submitting a
> >> >  document to CFRG that they knew to be inferior to a previous
> >> >  submission.
> >>
> >> This is not about rewards. It's about meeting the request of the TLS WG.
> >> And I contend that it's not inferior to
> >> draft-turner-thecurve25519function-01,
> >> but a different beast entirely.
> >
> >Which one is closer to meeting the express desires of the TLS WG? The
> >TLS WG does not want a generation method, but rather new curves. And
> >they don't want new "curves" but rather want us to do the hard work of
> >specifying a better mechanism. We've already ruled out random primes,
> >and short Weierstrass cofactor 1, in some cases in the face of
> >determined opposition. What's so special about the minority holding
> >out for slow choices of c that we need to appease them also?
> I don't think it's really a minority - things seem more balanced than that
> to me, based on my reading of the list.
> A minute ago you said that it was not hard work to specify multiple curves
> and algorithms - just a matter of changing some constants! If that's the
> case, then great, I'd hope you'd get involved in developing
> draft-black-rpgecc-00-.txt and help do that work there, to turn it into
> what you think we need to deliver.
To me this sounds like an ideal moment to follow through on the plans
made earlier. Is there a final requirements list? Is there a date when
the list of curves to evaluate will be stable? What will be the deadline
for comparing performance of arithmetic in different prime fields and
comparing performance of arithmetic on different curve shapes? What
will be the deadline for quantifying wiggle room in generation

We will not get optimal results by tweaking one meta proposal when 
creating a meta proposal was not the original mission and there has 
been very little discussion about requirements for meta proposals
while we discussed requirements for curves. We will not receive 
transparency by engaging in horse trading.

'Compromise' is a word that should be banned from this discussion; we
already have (potentially) compromised curves!

> I'd be grateful if the folks from the MGN team could say more on the list
> why they chose this particular prime, and give some insight into the
> performance impact of choosing it over near neighbours such as 2^389-21.
> Others should chime in too - for example, people should feel free to
> repeat performance numbers from earlier in our discussions (they are out
> there in the archive somewhere!).
> Please let's collaborate and see if we can swiftly resolve whether there
> is a significant performance impact or not.
I think a competition has more to offer than a 'collaboration' where 
parties get more influence by having more people send emails to the list.
What should count are the merits of papers, implementations, and internet 
drafts so that proposals get more influence by being objectively better.

So, I would very much like to support what Kenny said:
> Let's get past instinct to hard numbers.
... but I think this needs clear requirements, deadlines etc.