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

[Watson Ladd <[e-mail]>]

On Wed, Jan 15, 2014 at 10:42 PM, Paul Lambert <[e-mail]> wrote:
>
>
>
>>
>>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
>>tables.
>>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
> curves
> work well for signatures and key establishment.
>
> A truly ‘unified' public key system would support both signatures and key
> establishment
> with the same key.

ECDH with Edwards is still extremely fast, and if you have devices with code
size limitations, is a fine way to fit signatures and ECDH into a limited space.
However, there is a mandatory check of the square root when decompressing
points that must take place, and whose omission harms security without affecting
interoperability. I'll add text explaining this more clearly.

As for same key, I'm not an expert on the security implications of key reuse.
So far the draft is silent on this issue, and I don't feel capable of
saying anything
about it.

>
>>
>>>   - 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
>>>>>relevant
>>>>> 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
>>>>>value
>>>>> 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
>>>transformation’
>>>
>>> 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
> curve.
>
>>> 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
>>here
>>helps an implementor understand what the document says about Montgomery
>>and
>>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
> new.
>
>
> Paul
>
>
>
>
>>
>><rest omitted>
>>Sincerely,
>>Watson Ladd
>>
>>--
>>"Those who would give up Essential Liberty to purchase a little
>>Temporary Safety deserve neither  Liberty nor Safety."
>>-- Benjamin Franklin
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin