|
First and foremost, I would like to thank the author for
making this compilation available to the community. It certainly helps to cut
through some of the IPR fog. - Sec. 2.1: Using Zp for a general group (not necessarily of
prime order) is confusing. Can we have Zn instead? - 2.1: with all due respect, Knuth is probably unavailable
to most of our readers. There must have been something published in the last 28
years to replace it... - 2.2: similarly for Deskins. Or (if the pre-1994 provenance
is critical) add a reference to some modern tutorial coverage. Cormen,
Leiserson, Rivest and Stein chapter 31, for example. Or better still, a URL. - 3: the formula pair for x3, y3 "if P is equal to Q"
(the last one) is confusing, since the preceding formula refers to a sub-case
of this case. Maybe change to "otherwise", or "if P is equal to
Q and the previous condition does not hold". - General: the term "characteristic" (and once, "character")
is used multiple times without definition. - 3.2: "the order n" (not indented, by the way) - is
it part of the specification, or a dependent property of the group which is
defined by the other parameters? - 4: can you say something about the security of ECDH? Specifically,
are there validity checks required by both parties on the other party's value, so
that an attacker cannot force "bad" values that will reveal the
private key. Sec. 9.3 mentions that each party should check that the received
value is in the group. Is this sufficient? - 4.1: is group element -> is a group element - 4.2: since all group operations have been defined in terms
of full point (x and y), it is unclear how "compact representation" works,
i.e. how both parties compute the shared secret when only X values are
transmitted. - 7.1: when the dust around RFC 4735, its errata etc. settles,
IKE (v1 and v2) will use compact output. Thanks, Yaron |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature