> 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?
I asked the NSA about this last year and was told that they
will sublicense their ECC license only for national security
applications.
Certicom certainly know something about licensing of ECC.
Why not contact them directly?
William
>
> 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:pbaker at verisign.com]
> Sent: Wednesday, March 22, 2006 8:00 PM
> To: Ólafur Guðmundsson; cfrg at ietf.org
> 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:ogud at ogud.com]
> > Sent: Wednesday, March 15, 2006 9:04 AM
> > To: cfrg at ietf.org
> > 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
> > Cfrg at ietf.org
> > https://www1.ietf.org/mailman/listinfo/cfrg
> >
> >
>
> _______________________________________________
> Cfrg mailing list
> Cfrg at ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
>
_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg