Hi,
I have reviewed this document as
part of the security directorate's
ongoing effort to review all IETF
documents being processed by the IESG.
These comments were written primarily
for the benefit of the security
area directors. Document editors and WG
chairs should treat these
comments just like any other comments.
Abstract
1. First sentence: Should >are< rather be >were<
?
Introduction
2. Introduction (p.2): I would insert the word >finite< before
>fields<.
3. Introduction (p.4): >ECDH< should be replaced by >Elliptic
Curve Diffie-Hellman (ECDH) <.
Mathematical
Background
4. Mathematical Background (p.1): Should >is< rather be >are<
? The same holds in Sec.~2.2 (p.1).
5. Sec.~2.2 (p.3): The term >g< is undefined. Hence, >g^N<
should be replaced by >a^N<. The same holds for >Note that a^M is equal
to g^ (M mod R)< in (p.9).
6. Sec.~2.3 (p.2):
From this
description, it appears to me that all elements in Z_p can perform division
operation. However, only non-zero elements, namely elements in the set
Z_p^* =
Z_p-
{0}
can perform the division operation. Moreover, all the mathematical
operations over Z_p are in the sense of mod p. In addition, a prime number p is
called the
characteristic
of a field, if
1+…+1=0 (add p times); in this case F_q contains the prime field F_p, where
q=p^n, n>=1. So I think the definition of the F_p lacks
precision.
Elliptic Curve
Groups
7. Elliptic Curve Groups (p.1): I think the last sentence is too abstract
to understand. More precisely, the elliptic curve satisfies the
equations,
y^2+cy=x^3+ax+b,
y^2=x^3+ax^2+bx+c,
when the
characteristic of the field is 2 and 3,
respectively.
8. Elliptic
Curve Groups (p.3): The first sentence says that >when both points are the
point at Infinity<. Maybe such statement is not accurate enough due to the
fundamental fact that each elliptic curve abelian group has only one
infinity
, i.e., the identity
element.
9. Sec.~3.1
(p.2): It seems to me that the projection space representation >x=X/Z mod p ,
y=Y/Z mod p< is a special case of x=X/Z^
{c_1}
mod p and y=Y/Z^
{c_2}
mod p when both c_1 and c_2 are equal to 1. If
so, should it be clearly explained ?
10.
Sec.~
3.3.1
: I would simply state the reason for the
non-zero discriminant, namely, to ensure that the elliptic curve is chosen to be
a non-singular one, i.e., it has no self intersections or
cusps.
Elliptic Curve Diffie-Hellman
(ECDH)
11.
Elliptic Curve Groups (p.1): >an arbitrary cyclic group<
instead of >an arbitrary mathematical
group< ?
Elliptic Curve ElGamal
Signatures
12.
Sec.~5.1 (p.1): Insert >Galois< before >field
GF(2^w)<.
13.
Sec.~5.3 (p.2): Why not denote the generator >alpha< as >g< for
consistency in this draft ?
14.
Sec.~
5.3.2
(4): As the symbol >*< denotes
the scalar multiplication, why use such a symbol in Sec.~2.2 to represent the
addition operation in a group ? Needs to be modified
?
15.
Sec.~
5.3.3
(p.1): Insert >the generator g,
the group order q< before >the public key Y< in that these two
parameters must know in advance before the signature verification
procedure.
16.
Sec.~
5.3.2
(1): Should >0s_
1
in
Z_q< for consistency ? The same holds for
>0*< in the equation
>R'=alpha^
{u_1}
*
Y^
{u_2}
< represents the addition
operation of two points on the elliptic curve; while in >u_2=s_1 * s_2 mod
q<, it means the scalar multiplication
operation.
18.
Sec.~5.6 (p.2): In the equations >A=m< and >m=-r*z+s*k (mod q)<,
does the symbol m represent a message digest ? If so, I think m should be
replaced by h(m), although the hash function is not necessary here. If not, it
should be transformed to an integer since it has been defined to be a bit string
in Sec.~5.2. The same holds for the equation >m*s=-r*s*z+k (mod
q)<.
Converting between integers and
octet strings
19. the title >Converting between integers and octet strings<, why
not >Converting between Integers and Octet Strings< for consistency ? The
same goes for other titles and subtitles.
Security
Considerations
20. Sec.~10.1 (p.3): I
think it is necessary to explain the physical meaning of the
cofactor
and the reason that a
number of attacks are possible against ECDH when the cofactor is not equal to
1.
B. R.
Tina
http://tinatsou.weebly.com/contact.html