I'm trying to understand ECC from an IT layman's perspective and am trying to separate the theory from the standards, and understand why certain features are implemented or not implemented in the common ECC stacks.


Namely, I'd like to know when should a non-standard ECC library (or related hardware) should be used versus when a standard ECC library should be used.

Second, I'd also like to know what trade-offs were considered in the common implementations such as DHE in MSFT or Java versus what's implemented in other software

What I think I understand so far:

  1. There are several mathematic properties that can be used in encryption

  2. Many protocols have been created on those properties to facilitate key exchange. The common standards are broken into the following categories

    • NIST - Only
    • The NIST / SECG overlap
    • SECG - Only
    • ECC Brainpool
  3. Real world implementation of the above properties and standards are dictated by:

    • Patent concerns on the math and the key exchange (Certicom)
    • Security through obscurity (some haven't been released, and some "compatible" derivatives have been created)
    • Government approval (why did the government approve it? Backdoors, patents, the country that 'invented' it?)
  4. What I haven't been able to figure out is:

    • Are some implementations faster, more secure, or more suited for (or against) hardware optimizations?

    • Are some standards preferred simply because a vendor (or government) paid for their patent fees and will not be legislated?

  5. For a given implementation above, is there any risk of (or benefit depending on whose side you're on) of patented techniques like:

    • implementation of curves over binary fields using normal bases;
    • point compression;
    • acceleration of Koblitz curves using the Frobenius endomorphism;
    • various optimization tricks on dedicated hardware architectures (FPGA, GPU, ASIC).
  • $\begingroup$ This is perhaps too many questions at once. $\endgroup$ – Thomas Dec 15 '12 at 4:23
  • $\begingroup$ @Thomas FYI The +3 votes came from Security.SE, not the more discriminating Crypto.SE site, who could (and probably already did) write a book on this. I'd have to think about how to slice this up, but feel free to edit as you think ... $\endgroup$ – goodguys_activate Dec 15 '12 at 12:09

By non-standard do you mean when to use custom curves? Like in crypto++ where you can specify your own parameters?

Given that the standards recommend certain sets of domain parameters (and interesting enough US government departments are forbidden from using their own parameters) it's sounds like the answer is no, for reasons of avoiding the risks of self implementation and the worthlessness of "security by obscurity". Tiresome, but this is how i answer all the "should I do my own" question, sorry.

I do know that NIST curves have certain computational advantages over any old curves because there are some just more convenient numbers for the Projective coordinates calculations. Also this wikipedia page seems to think the number of prime curves and binary curves affects security and implimentation efficiency (I have no idea why though, but there is a link in the "NIST-recommended elliptic curves" section )

| improve this answer | |
  • $\begingroup$ Answers one question, links should be of use as well. Also, do you think crypto is like amateur asbestos removal, in that the skills we acquire are often ones we should never use? $\endgroup$ – Nathan Cooper Dec 19 '12 at 12:55
  • 1
    $\begingroup$ I disagree about your comment - while a certain amount of standard, general-purpose schemes already exist for most situations, it is sometimes necessary to roll your own cryptographic protocol for your particular use-case. Knowing the difference between a HMAC and a KDF, what IND-CCA means and what a birthday attack is, is crucial to get it right, or at least not fail as much. Seriously, someone has to implement all of this at the end of the day, and if you have the skills, why the hell wouldn't you apply them? Security professionals are not superior beings, they are humans like you and I. $\endgroup$ – Thomas Dec 20 '12 at 14:31
  • 2
    $\begingroup$ This applies to high-level protocols, of course - implementing your own cipher is almost always a terrible idea because that actually requires years of training and analysis, whereas by just putting together cryptographic constructions you are using existing primitives which are assumed to have specific properties, which you can use to prove your construction is secure assuming the underlying primitives are (which is more reasonable). $\endgroup$ – Thomas Dec 20 '12 at 14:34
  • $\begingroup$ Great points, I agree. $\endgroup$ – Nathan Cooper Dec 20 '12 at 14:35
  • $\begingroup$ Perhaps more importantly, it also helps you identify and steer clear of snake oil.. $\endgroup$ – Thomas Dec 20 '12 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.