Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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).
share|improve this question
    
This is perhaps too many questions at once. –  Thomas Dec 15 '12 at 4:23
    
@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 ... –  makerofthings7 Dec 15 '12 at 12:09
add comment

migrated from security.stackexchange.com Dec 14 '12 at 9:16

This question came from our site for Information security professionals.

1 Answer

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 )

share|improve this answer
    
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? –  Nathan Cooper Dec 19 '12 at 12:55
1  
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. –  Thomas Dec 20 '12 at 14:31
1  
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). –  Thomas Dec 20 '12 at 14:34
    
Great points, I agree. –  Nathan Cooper Dec 20 '12 at 14:35
    
Perhaps more importantly, it also helps you identify and steer clear of snake oil.. –  Thomas Dec 20 '12 at 14:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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