|
Hi David, I don’t know if there’s a good
answer, I believe the answer is essentially that there are several implementations
already using the compact representation. And that is also what http://tools.ietf.org/html/draft-solinas-rfc4753bis-00,
currently in IETF last call, specifies. Thanks, Yaron From: David McGrew
[mailto:mcgrew at cisco.com] Hi Yaron, many thanks for your useful comments, they will improve the next
version of the draft. If there is uncertainty about whether or not IKE uses compact output
for ECDH, I wonder: why don't we just not use it? It is probably the
simpler option, at least conceptually. Sorry for the slow reply, I have been on vacation recently. David On Jul 8, 2009, at 8:54 AM,
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