3
$\begingroup$

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.

Question

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).
Improve this question
$\endgroup$
2
  • $\begingroup$ This is perhaps too many questions at once. $\endgroup$
    – Thomas
    Dec 15, 2012 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$
    – makerofthings7
    Dec 15, 2012 at 12:09

1 Answer 1

Reset to default
1
$\begingroup$

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
$\endgroup$
5
  • $\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, 2012 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, 2012 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, 2012 at 14:34
  • $\begingroup$ Great points, I agree. $\endgroup$
    – Nathan Cooper
    Dec 20, 2012 at 14:35
  • $\begingroup$ Perhaps more importantly, it also helps you identify and steer clear of snake oil.. $\endgroup$
    – Thomas
    Dec 20, 2012 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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