Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as a RG document

[Joppe Bos <[e-mail]>]

Hi all,

The current version of the draft contains methods for parameter selection
(section 6) and a single recommended curve (section 7). 
IMO the natural approach would be to first agree upon a parameter selection
procedure (one draft) and subsequently, when a large portion of the
community agrees that this selection procedure is sound, use this procedure
to select new curves (another draft). Currently, we are changing the
selection procedure to match an existing curve. If we want curve25519
because it is fast and widely deployed then we should state this clearly and
refrain from modifying the selection procedures because this might have a
negative impact on the potential selection of curves in the future. 

Please find below some comments on the current version of the draft.

Section 7: 
- The specification of the parameters is done either in formula form (p), in
decimal (d) or a formula + hexadecimal (order). Maybe use the same notation
(e.g. either decimal or hexadecimal) everywhere to avoid confusion?
- For completeness it might be good to give the corresponding (short)
Weierstrass form of the curve(s).

Section 8-10:
These sections are curve25519 specific, this should be stated much clearer.

Section 8:
As far as my understanding goes there was no consensus on the wire format of
field elements. 
This section states that "when transmitting field elements in the
Diffie-Hellman protocol below, they MUST be encoded as an array of bytes, x,
in little-endian order". Maybe some notation got confused here, what is this
x-coordinate? The only x defined are on the Edwards curve while I think here
the Montgomery curve is meant (the u-coordinate from section 7). This should
be fixed or stated clearer to avoid confusion.

Section 9:
- It is not entirely clear to me why such low-level details are provided in
this draft. Is it expected from the CFRG to deliver implementation details
for algorithms or just a specification of curves plus related info (such as
wire formats)? If we want to provide such low-level details then why not
also state how to implement the field arithmetic?
- Why is only the approach based on the Montgomery ladder stated in this
section? There is nothing wrong with the Montgomery ladder but it is not the
best solution for all reasonable definitions of best. The implementer has
the choice, as stated before on this list, to compute DH on (for instance)
the corresponding Edwards or Weierstrass curve. Currently it looks as if the
CFRG recommends to use the Montgomery ladder for all scenarios;  something
we know is suboptimal in terms of performance for higher security levels.
Moreover, imagine the scenarios where people use (twisted) Edwards curves
for signatures. Then implementing DH using the Montgomery ladder implies
managing code for both the Montgomery and the twisted Edwards curve and,
following the reasoning expressed by some people on this list, a larger code
base implies more room for errors which implies a less secure approach. 
- This ladder implementation defines the usage of cswap ("due to the
existence of side-channels in commodity hardware"). Although this adds some
protection this algorithm is not secure in many realistic threat models
(e.g. in hardware security). To me, it looks quite arbitrary to just protect
against one type of attack and not against a whole range of other
side-channel attacks. The threat model should depend on where the
implementation will be used and therefore it is up to the implementer to
make the appropriate design decisions and introduce the adequate
countermeasures. 

Best regards,

Joppe

-----Original Message-----
From: Cfrg [mailto:[e-mail]] On Behalf Of Alexey Melnikov
Sent: Monday, January 05, 2015 8:15 PM
To: [e-mail]
Subject: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as a RG document

This message starts 2 weeks adoption call (ending on January 19th 2015) on:

https://www.imperialviolet.org/cfrgcurve/cfrgcurve.xml

as the starting point for the CFRG document which describes an algorithm for
safe curve parameter generation for a particular security level and also
recommends a specific curve (2^255-19) for the 128-bit security level.

Please reply to this message or directly to CFRG chairs, stating whether you
support (or not) adoption of this document. If you do not support adoption
of this document, please state whether you support adoption of any
alternative document or whether you want a particular change be made to the
document before adoption.

Chairs ask not to reiterate previously expressed technical opinions or
arguments. But clarifying questions on the adoption call are welcome.

While making your decision, please keep in mind

http://www.ietf.org/mail-archive/web/cfrg/current/msg05813.html

Alexey,
On behalf of CFRG chairs.

P.S. Editors of draft-black-rpgecc-01 and
draft-turner-thecurve25519function-01 can become co-editors of the adopted
document, if they choose to do so. Email chairs directly if you are willing
or not willing to do so.

_______________________________________________
Cfrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/cfrg