Crypto Forum Research Group ()

Yaron Sheffer | 8 Jul 2009 17:54

Comments on draft-mcgrew-fundamental-ecc-00.txt

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): application/x-pkcs7-signature, 5107 bytes

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

headers

Sean Shen | 23 Jul 2009 09:14

Comments on draft-mcgrew-fundamental-ecc-00

Hi, David,

Thank you for providing such a document. As a ecc fan, I like this document very much, :)

I was not able to finish reading the whole document yet, but get a few comments so far:

#1
section 2.1
When you are discribing "set Zp = { 0, 1, 2, ..., p-1 }", looks like you do not limit p to be a prime.

Usually Zn is used for arbitary modular group, Zp refer to modular group with prime order.

#2
section 2.2
By definition, the operation "*" defined on any group have a property of associative law: (a*b)*c=a*(b*c).

The operation "*" is called "+" when it also has another good property called commutative law, i.e. a+b=b+a.

#3
section
This document only cover curves over finite fields with Characteristic>3. Is there a reason for this? I

imagine becuase Certicom's recent IPR disclosure provide royalty free license for 3 ECP curves? I don't

know whether IETF will more recommend ECP curse because of this disclosure, but I think this is a good

reason to only describe ECP curves. If it is the reason, might be good to mention it.
I took a brief looks at EC groups defined for IKE and TLS:
For IKE and IKEv2:
RFC2409 and subsequetly IANA defined, 10 EC2N groups (Characteristic=2)
(http://www.iana.org/assignments/ipsec-registry)
RFC4753, 3 ECP groups (Characteristic>3)
For TLS:
RFC4492, 14 EC2N groups, 11 ECP groups
This is a very rough look and can not be considered a survey.

I will keep reading and hope to add more comments.

Best,

Sean

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

headers

Andreasyan Ashot-C23793 | 28 Jul 2009 22:31

IKEv1 and 800-56A

Hi All,

Recently NIST published "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"

http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf

How does this this document is going to interconnect with IKEv1?

Thanks,

Ashot

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

headers

David McGrew | 30 Jul 2009 20:34

Re: 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.

Sorry for the slow reply, I have been on vacation recently.

David

On Jul 8, 2009, at 8:54 AM, Yaron Sheffer wrote:

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

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

headers

David McGrew | 30 Jul 2009 22:10

Re: IKEv1 and 800-56A

Hi Ashot,

On Jul 28, 2009, at 1:31 PM, Andreasyan Ashot-C23793 wrote:

Hi All,

Recently NIST published "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"

http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf

How does this this document is going to interconnect with IKEv1?

that's a good question. The Diffe-Hellman protocols in the NIST key management documents are based on ANSI and IEEE standards that were developed concurrently with ISAKMP/OAKLEY/IKE. They are functionally equivalent in some ways, but they are different and incompatible in other ways.

Personally, I would like to see these standards be reconciled, with preference going towards what they industry is actually implementing and using whenever it is reasonably secure. I would expect this reconciliation to be a long term project. Other opinions are welcome.

If you are interested in the NIST key management documents, you might want to review the NIST White Paper on transitioning algorithms and key sizes, see http://csrc.nist.gov/groups/ST/key_mgmt/ Note that the review period closes on August 3.

David

Thanks,

Ashot

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

headers

Yaron Sheffer | 30 Jul 2009 22:40

Re: Comments on draft-mcgrew-fundamental-ecc-00.txt

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