[Cfrg] Comments on draft-irtf-cfrg-curves-11

[John Mattsson <[e-mail]>]

Hi,

I took some time during Christmas to review draft-irtf-cfrg-curves-11.
Very good. I have some comments, mostly editorial:

- Sec 1: The equation “y^2 = x^3 + A*x^2 + x” is used in Section 1 and A
even though the notation in section 3 says that x, y are coordinates on
Edwards curves. Shouldn’t this be “v^2 = u^3 + A*u^2 + u”?

-Sec 3: The notation ‘P’ for the generator base point is not used except
in ‘X(P)’ and ‘Y(P)’, I think you should either use the ‘P’ notation or
drop it.

- Sec 3: I do not see the point of the ‘X(P)’ and ‘Y(P)’ notations. It is
only used twice. Why not just say that “The base point is x =
1511222134953540...., y = 46316835694926478169...”?

- Sec 4: You should point out that the ‘order’ is the order of the
prime-order subgroup and not the order of E(F_p). It would also be good to
point out that this subgroup has prime order. In appendix A, the notation
‘r’ is used for the order of the prime-order subgroup. Furthermore in the
findCurve function, ‘order’ means #E(F_p) and in the findBasepoint
function ‘order’ means point order. Would be good with some clearer
notation for the different orders.

- Sec 4.1, 4.2, I think it would be good with some indention or
subsubsections to make the separation of e.g. curve25519 and edwards25519
clearer.

- Sec 5: “MUST mask the most-significant bit in the final byte”
I think the ‘mask’ operation should be explained.

- Sec 5: The heading capitalization is different in section 5, i.e. the
first letters in “functions”, “considerations”, “vectors” are non-capital.

- Sec 6.1: “key-derivation function that includes K, K_A and K_B to derive
a key”
Probably helpful for some readers to specify that the key is a “symmetric
key”, 

- Sec 6.1: “the co-factor , h”
The spelling “cofactor” is used in the rest of the document and the
notation ‘h’ is not used anywhere else.

- Sec 6.1: Calling Bob’s private key ‘g’ may confuse some readers as ‘g’
is very often used to denote the generator in Diffie-Hellman protocols.
I.e. here Bob computes 5^g and not g^5.

- Sec 6.1: If implementors must calculate the ORing of all the bytes, it
might be good to force them to do so by recommend the ORing of all the
bytes to be an input to the KDF.

- Sec 6.1: “The check for the all-zero value results from the fact that
the X25519 function produces that value if it operates on an input
corresponding to a point with order dividing the co-factor, h, of the
curve”.
Am I missing something or doesn’t X25519 only produce the all-zero value
if the point order divides the input scalar? In this case the text should
say something like “may produce” or “produces with high probability”.

- App A: the variable ‘r’ (order of the basepoint/order prime order
subgroup) is not defined. The variable ‘k’ (embedding degree) has already
been used to denote a scalar in section 5.

- Unclear why some values are given in hex and others in decimal. E.g. the
order Sec. 4,1 and 4,2 is given in hex, while the base point is given in
decimal. Some hex values use the ‘0x’ prefix, others do not.

- Most of the document seem to have adopted the style of having space
around ‘+’ and ‘-’, but this is not followed in a few places e.g.
s4.1: “2^255-19” -> “2^255 - 19”
s4.1: “1+y” -> “1 + y”
s4.2: “2^448-2^224-1” -> “2^448 - 2^224 - 1”

Cheers,
John



 

JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB
Ericsson Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]
www.ericsson.com <http://www.ericsson.com/>


 <http://www.ericsson.com/>
 
This Communication is Confidential. We only send and receive email on the
basis of the terms set out atwww.ericsson.com/email_disclaimer
<http://www.ericsson.com/email_disclaimer>