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

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 22 Mar 2006 20:07:00 -0500

I would MUCH prefer ECC - but my lawyers (yuk!) are telling me that there are licensing problems, and supposed NSA contacts don't call them back.

Anybody knows anything useful about licensing of ECC GF(p), that he can share with me? 

Tnx!

P.S. Out of hand - I think that DSA should be workable (I assume small devices won't need that service???).

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Wednesday, March 22, 2006 8:00 PM
To: Ólafur Guðmundsson; [email-masked]
Subject: RE: [Cfrg] Defining inter operable ECC keys in for IETF protocols 

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: [email-masked] (Peter Gutmann)
Date: Thu, 23 Mar 2006 14:40:34 +1200

"Blumenthal, Uri" <[email-masked]> writes:

>I would MUCH prefer ECC - but my lawyers (yuk!) are telling me that there are
>licensing problems, and supposed NSA contacts don't call them back.
>

Certicom have done such a good job of creating FUD about ECC legal issues
that, unless you're a Certicom licensee, it's easier to not use it at all.  So
far every time I've been asked about ECC support (which admittedly is once a
blue moon anyway), I've asked the organisation who want it to come back to me
with either proof of a Certicom license or a clear statement of which non-
infringing mechanisms they want me to implement.  In every case, after looking
at what's involved, they've decided they didn't need ECC that much anyway.
It's like the conclusion from Wargames, the only way to win is not to play.

Peter.