Subject: RE: [Cfrg] Defining inter operable ECC keys in for IETF protocols

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 17:00:19 -0800

Would the recently proposed extended DSA with larger key sizes be a workable
alternative?

The key size is still large (does someone know how large a key has to be to
give 2^128 equivalent security). But the signatures are small, 256 bits,
that’s only 32 bytes.

I would prefer ECC or something else that gives me small keys and small sigs
if it is free. Getting to a state where we are confident that an ECC scheme
is free as in beer is hard. 

> -----Original Message-----
> From: Ólafur Guðmundsson [mailto:[email-masked]] 
> Sent: Wednesday, March 15, 2006 9:04 AM
> To: [email-masked]
> Subject: [Cfrg] Defining inter operable ECC keys in for IETF 
> protocols 
> 
> 
> I apologize for this open ended question but the WG I 
> co-chair DNSEXT has added security extensions to the base DNS 
> protocol (DNSSEC), currently RSA/SHA1 is the main signing 
> algorithm. DSA is also defined. DSA is reaching end of life, 
> safe RSA signatures and keys are large.
> 
> As DNS messages are carried over UDP packets there is 
> interest in being able ECC due to the fact the keys and 
> signatures are much smaller.
> A proposal has been made for a ECC key format.
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-08.txt
> 
> Our worry is that the format proposed is open ended and 
> people can publish/use keys in fields that the rest of the 
> world can not use due to lack of support in common crypto libraries.
> 
> What the DNSEXT working group is looking for is some guidance 
> on how to create a SHORT list of fields/curves to use by ECC 
> in the DNS context and/or wider IETF context.
> 
> Nice feature: In the DNS world we are more interested in 
> keeping Verification time down than signing time, RSA with 
> small exponent is quite nice in this regards. I do not know 
> if the choice of ECC variant has any impact on the difference 
> between signing and verification time.
> If due to the shorter length of ECC key the signature 
> verification times are on-par with equivalent strength RSA 
> key this is a non issue.
> 
> In some environments due to the large number of signatures 
> that need to generated in short time, hardware 
> implementations might be required.
> 
> Any guidance will be greatly appreciated.
> 
> 	Olafur 
> 
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
> 
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Scott Fluhrer <[email-masked]>
Date: Wed, 22 Mar 2006 17:22:37 -0800 (PST)

> give 2^128 equivalent security). But the signatures are small, 256 bits,

Obnit: for 2^128 equivilent security, the signatures would be 512 bits (64 
bytes) -- the signature is the pair (r,s), which both r and s being the 
size of the subgroup, which in this case would be 256 bits.

---

From: "Hal Finney" <[email-masked]>
Date: Wed, 22 Mar 2006 20:51:54 -0800

On 3/22/06, Hallam-Baker, Phillip <[email-masked]> wrote:
> give 2^128 equivalent security).

The new draft specifies two subgroup size choices for 2048 bit moduli:
224 and 256 bits. Or you can go to 3072 bit modulus also with a 256
bit subgroup. But I guess they think that a 2048 bit modulus isn't too
bad a match with a 256 bit subgroup, for 128 bit security.

http://csrc.nist.gov/publications/drafts/fips_186-3/Draft-FIPS-186-3%20_March2006.pdf

Hal