Re: [Cfrg] Outline -> was Re: normative references

Paul Lambert <> Thu, 16 January 2014 06:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 47B4C1AE2DB for <>; Wed, 15 Jan 2014 22:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.367
X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pCYH2K8h6VOZ for <>; Wed, 15 Jan 2014 22:42:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D50731AE2D7 for <>; Wed, 15 Jan 2014 22:42:53 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s0G6gaUI005309; Wed, 15 Jan 2014 22:42:36 -0800
Received: from ([]) by with ESMTP id 1hcwyws2am-21 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Jan 2014 22:42:36 -0800
Received: from ([]) by ([::1]) with mapi; Wed, 15 Jan 2014 22:42:34 -0800
From: Paul Lambert <>
To: Watson Ladd <>
Date: Wed, 15 Jan 2014 22:42:32 -0800
Thread-Topic: Outline -> was Re: [Cfrg] normative references
Thread-Index: Ac8ShiMG2XWBDqf5R2WNOTT2tW/N+g==
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-16_03:2014-01-15, 2014-01-16, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401150268
Cc: Yaron Sheffer <>, David McGrew <>, "" <>
Subject: Re: [Cfrg] Outline -> was Re: normative references
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, 16 Jan 2014 06:42:55 -0000

>Signatures are going separately.
>>       - Signature Alg with Edwards Curve
>>       - Montgomery Curve Signatures ...
>If you have a method that will work on a Montgomery curve naturally I
>would love to hear it.

That’s the point of having the section … you need a section to say it
is not a good idea… or transform or whatever.

>Montgomery curves are here for their blazing speed in ECDH without large
>Edwards curves are here for their blazing speed in signatures where we
>can't toss out
>one coordinate. I'ld much rather use Montgomery for ECDH and Edwards
>for signatures
>than Edwards for everything.

Again the point of the outline was to provide a framework to possibly make
such recommendations.

These all seem like severe issues with these new curves.  The Weierstrass
work well for signatures and key establishment.

A truly ‘unified' public key system would support both signatures and key
with the same key.

>>   - Curve Catalogue
>>     (include curves def’s, origins, refs, strength, NUM+NUTS whatever)
>>      - Overview
>>      - Edwards
>>      - Twisted Edwards
>>      - Montgomery
>>   - References
>>  Annex
>>    - int to string / string to int per ANSI
>>      (could be up front also in intro )
>>    - other stuff / recomendations / math options
>>>> I was pointing to specific examples that we could emulate in a perhaps
>>>> more simple manner.  The next step would be get a summary of the
>>>> details required and emulate one or more of these documents.
>>>>>>  ⨳|If we aren't specifying any twisted Edwards curves, why would we
>>>>>>  ⨳|define the formulas?
>>>>>>  ⨳|I suppose for use with Montgomery form, ala Ransom's suggestion.
>>>>>> [ ⨳]
>>>>>> Yes ... and why did you leave out Ed25519?       It's being used and
>>>>>>should at least be discussed/reviewed/
>>>>>It's the same as Curve25519, and not in safecurves. Let's be real
>>>>>clear: isogenies don't change anything substantial.
>>>> Substantial???
>>>> Curve22519 is not interoperable with Ed25519. What could be more
>>>> substantial.  A point on one curve would have a different x and y
>>>> than a curve on the other.
>>>If I transmit to you a Curve25519 point, you can treat it as an
>>>Ed25519 point (after appropriate transformations) and I
>>>will never know the difference.
>> But if you do not identify that it is a Curve25519 point versus a
>> Ed25519 point you will not know when to do the ‘appropriate
>> So .. both are needed - especially if we are restricting Montgomery
>> Curves to DH operations … which you imply.
>Well, there are Edwards curves of about the same size. I've put it in
>because I
>take your point: we do need something that has a strongly unified
>complete addition law
>with that size that can be used for signatures.
>The only way I know of to use Montgomery curves for signatures loses
>the extreme speed.
>As for the transformation, if I tell you that protocol x uses
>Curve25519 ECDH, I hopefully
>have told you enough to know exactly what will be sent, regardless of what
>you chose to do to think about it. Anything in the draft that makes that
>not the case is a major issue.

… And if you are using Ed25519a or Ed25519b you also need to identify the

>> My point above on Weierstrass was for clarity of implementation.  The
>> parameters have names (like ‘a’).  NIST curves have an ‘a’ that is
>> different
>> from the usage in Montgomery curves.  You simply need to show both
>> equations
>> and define what an ‘a’ means in each context (text already provided to
>> you).
>> That was the point of an early discourse on these being ‘new’ curves.
>I'm having trouble visualizing why putting in the short Weierstrass form
>helps an implementor understand what the document says about Montgomery
>Edwards curves.

You simply need to put the new curves in the context of the old.
No need to describe everything about them since they are well known.
They should be mentioned to show that the math is not the same.
The outline provided a section to briefly mention the old to introduce the


><rest omitted>
>Watson Ladd
>"Those who would give up Essential Liberty to purchase a little
>Temporary Safety deserve neither  Liberty nor Safety."
>-- Benjamin Franklin