Subject: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00.txt

From: Yaron Sheffer <[email-masked]>
Date: Wed, 8 Jul 2009 18:54:13 +0300

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

---

From: David McGrew <[email-masked]>
Date: Thu, 30 Jul 2009 11:34:28 -0700

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, Yaron Sheffer wrote:

> 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".
> 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.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
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 30 Jul 2009 23:40:08 +0300

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:[email-masked]] 
Sent: Thursday, July 30, 2009 20:34
To: Yaron Sheffer
Cc: [email-masked]
Subject: Re: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00.txt

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.  

David

Thanks,

            Yaron

Scanned by Check Point Total Security Gateway.