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 > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cfrg mailing list Cfrg at ietf.org https://www1.ietf.org/mailman/listinfo/cfrg