Yaron Sheffer | 8 Jul 17:54 2009
Picon

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, 6902 bytes
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Sean Shen | 23 Jul 09:14 2009

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
Andreasyan Ashot-C23793 | 28 Jul 22:31 2009

IKEv1 and 800-56A

Hi All,
 
Recently NIST published "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"
 
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
David McGrew | 30 Jul 20:34 2009
Picon

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
David McGrew | 30 Jul 22:10 2009
Picon

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"
 
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
Yaron Sheffer | 30 Jul 22:40 2009
Picon

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

 

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

 



Scanned by Check Point Total Security Gateway.

Attachment (smime.p7s): application/x-pkcs7-signature, 6902 bytes
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Andreasyan Ashot-C23793 | 30 Jul 23:30 2009

Re: IKEv1 and 800-56A

Hi David,
 
Thank you for your response.
 
I have already read that paper and it looks like they are OK for now with IKEv1 KDF but
you are right that consolidation is long term project and IETF needs to take care.
 
Ashot
From: David McGrew [mailto:mcgrew <at> cisco.com]
Sent: Thursday, July 30, 2009 1:10 PM
To: Andreasyan Ashot-C23793
Cc: cfrg <at> irtf.org
Subject: Re: [Cfrg] 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"
 
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
Jack Lloyd | 31 Jul 21:35 2009
Picon

Re: [saag] GOST algorithms descriptions

On Sat, Jun 13, 2009 at 12:29:07PM +0400, Basil Dolmatov wrote:
> Hello,
>
> the fact that the GOST cryptography algorithms descriptions are not easily 
> accessible in English was repeatedly mentioned when discussing related 
> subjects.
> Now, these descriptions are posted as I-Ds, we hope that will serve the 
> community to get acquianted more closely with these sets of widely used 
> algorithms.
>
> http://www.ietf.org/internet-drafts/draft-dolmatov-cryptocom-gost341194-00.txt
>
>
> http://www.ietf.org/internet-drafts/draft-dolmatov-cryptocom-gost34102001-00.txt
>

The examples use a set of sboxes for GOST-28147 which are referred to
in RFC 4375 as id-GostR3411-94-TestParamSet, whereas the text of RFC
4375 itself uses the other param set
(id-GostR3411-94-CryptoProParamSet) in all situations. Given that all
(?)  IETF GOST standards use this param set, why not provide test
vectors for it rather than the (otherwise unused) TestParamSet?

Regards,
  Jack Lloyd

Gmane