On 12/21/2010 04:24 AM, Niels Möller wrote:
which spec to implement,
Well, for my purposes, i'd start with the curves slated for use in the upcoming OpenPGP ECC extension:
https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-06#section-4
I think this has allows for conformance to the NSA's Suite B recommendations, for whatever that's worth.
patents situation,
Unfortunately, the patent system seems to be such that even if i were a patent lawyer (i am not, fortunately), i could make no iron-clad guarantees. The best i can offer is a sort of suggestive inference:
In addition to the list of other free implementations of ECC i started this thread with, it looks like NSS ("netscape security services", the crypto toolkit supporting firefox and its peers) has been shipping on major distros with ECC support not only in source, but enabled for over a year now:
http://bugs.debian.org/490826 https://bugs.launchpad.net/ubuntu/+source/nss/+bug/232392
libgcrypt is also about to add ECC support, according to a recent conversation on the libgcrypt mailing list. This should result in gpg 2.1 having ECC when it releases.
Anyway, this is no guarantee that there aren't patent trolls lurking, but there are certainly some tastier/deeper-pocket/higher-profile targets who don't seem to have been attacked on account of shipping functional ECC implementations.
ecc usecases,
As you mentioned, embedded devices and devices (like smartphones) with metered or severely limited connectivity will all benefit from the reduced keysize. Also, attacks against traditional asymmetric crypto are expected to continue apace, and expected power of machinery will keep improving; so tools that use RSA and DSA will need to keep expanding keysize to keep up. ECC offers a chance to stay within the current overhead size for a while longer still.
expected performance
sorry, i don't have good figures for this, but i'd be happy to help you set up performance comparisons with other free implementations if you're interested in that.
--dkg