I think that question has not been answered in some countries, like the US. In the US, it will likely cost you 10's of thousands and a few years to decide. And you can't really be sure if the US courts will get it right.
–
jwwJan 4 at 8:27

5 Answers
5

The ECC implementation in OpenSSL has been contributed by Sun (now Oracle) and was, supposedly, written that way precisely to avoid any patented method. Otherwise, as AviD suggests, using an implementation which is already provided by the platform you use (Java, .NET...) is a neat way to avoid any patent trouble: if there was such trouble, it would first strike the platform provider (i.e. Oracle, Microsoft), not you.

To my knowledge (but I am not entitled, in any way, to give law-related advice), parts of ECC cryptography which may still be patented are:

Umm... @Thomas, I have no idea what most of the above means, but that doesn't mean that if I used ECC, I wouldnt use them without knowing it... But I guess one could specifically look out for these.
–
AviD♦May 3 '11 at 13:04

1

"using an implementation which is already provided by the platform you use (Java, .NET...) is a neat way to avoid any patent trouble" - I'm not sure that's true. I think you would need an indemnity clause, and I doubt Oracle or Microsoft are supplying them (at least not in their run-of-the-mill license agreements).
–
jwwJan 4 at 8:40

According to Wikipedia, it shouldn't be a problem (if you're careful):

At least one ECC scheme (ECMQV) and some implementation techniques are covered by patents.

(Which of course implies that other schemes are patent-free.)

As for opensource implementations, that same WP article has a good list.
Though you didn't specify what language/platform you're on, I would recommend going with OpenSSL, the most well-known and most reviewed package in the bunch.
Though I've also heard good feedback on some others, such as BouncyCastle, OpenSSH, ...
Depending on what platform, Java and .NET both have built-in support, as do the latest versions of Windows - so you won't have to worry about patents there. (That is to say, it is a safe assumption that these are either patent-free or legally licensed.)

"Which of course implies that other schemes are patent-free" - I'm not sure that one leads to the other... All the preceding sentence does is make a statement about one particular algorithm; and not the other remaining algorithms.
–
jwwJan 4 at 8:38

This is more of a comment than an answer, but the fact that point compression is patented is utterly ridiculous. In essence, it's patenting the process of storing point (x, y) by storing x, and the using y = f(x).

Anyway:

Another thing that's interesting, regarding the 'if you use an implementation provided by someone else, you're fine' argument:
At least one hardware security module provider, which includes an ECC implementation, will not guarantee people who use their modules against patent claims. That's food for thought.

Of course, it's also important to note that in some countries (like Japan, iirc) ECC is completely unencumbered, and that many of the other patents only apply in the U.S.

Both RHEL and Fedora have long restrained from shipping OpenSSL with it's ECC support activated, out from concern about infringing patents.

As of RHEL 6.5 Beta, and the 14 October 2013 update to Fedora Core 18, 19, and 20, this is no longer the case, and ECC is activated by default on those two OS, the associated bug is resolved.

IMPORTANT EDIT : Finally Fedora will only include support for a specific subset of ECC NIST Suite B curves, which means they probably rely on the various agreements by which Certicom releases it's IPR on ECC in some specific cases, and not on an analysis of the OpenSSL code concluding that it does not infringe the ECC patent.