First off, this feels like it should be a common question, so I'm sorry if I've missed an older thread.

Note that in my question, I'm talking about "implementing AES" rather than "designing AES2" or something.

I am of course familiar with the saying that you should "never implement your own crypto" and I've recently also learned some about why, in terms of all the attacks and common mistakes, etc. However, I've never really liked that answer, because if no one ever implemented it, we would never have it. And since we do have it, someone must not have listened, and implemented it.

My question is: At what point is a person "allowed" to implement a crypto library? Be it for a new platform, a newly released algorithm, etc.

  • $\begingroup$ @gowenfawr I'd be happy to move it over there if people think that that's best. Let me know what you'd like me to do, as I admitted wasn't quite sure where to put it. $\endgroup$
    – Leonhart231
    Commented May 8, 2015 at 21:22
  • 2
    $\begingroup$ Applied Cryptography is dated, and more targeted at people who design algorithms. His book Cryptography Engineering is more recent and more relevant to crypto implementers. $\endgroup$ Commented May 8, 2015 at 21:23
  • 2
    $\begingroup$ @gowenfawr This is mainly about risk management, it isn't about crypto itself. So it's far better for Information Security than for Cryptography. I'd vote to close it as off-topic on Crypto. $\endgroup$ Commented May 8, 2015 at 21:24
  • 1
    $\begingroup$ BTW, there's no problem implementing crypto whenever you feel like it. The concern comes from using your implementation in a production setting that requires security. $\endgroup$ Commented May 8, 2015 at 21:27
  • 4
    $\begingroup$ I'm voting to close this question as off-topic because it is about risk management, not about cryptography. It was on-topic on Information Security. $\endgroup$ Commented May 9, 2015 at 12:07

3 Answers 3


"Allowed" or "forbidden" are not the right terms; the Pope won't excommunicate you if you dare implement your own algorithms. The question is rather whether doing your own implementation is a smart move or not.

For learning, doing your own implementation is a good idea. It will teach you a lot on how the said algorithms work. A lot of details on how cryptographic algorithms are designed, in particular symmetric encryption and hash algorithms, come from implementation considerations -- the algorithm designer always tries to find the structure that will ensure the required security properties with the maximum efficiency (speed, code size... on a variety of architectures).

For "production", beware. Cryptographic algorithms, by design, are meant to process confidential elements (in particular keys, that concentrate a lot of secret in a few bits), so it is of the utmost importance that the implementation does not leak information. This is a lot harder than usually assumed. For instance, a very common and, I dare say, highly fashionable theme is about timing attacks through cache behaviours on software platforms (both the L1 cache for RAM access, and the in-CPU cache for jump prediction). This kind of attack can be used, at least conceptually, to extract keys from running systems, typically from another VM that runs on the same hardware (such attacks have been repeatedly demonstrated in lab conditions, so it seems plausible that they may be applicable in practice). Writing an AES or RSA implementation that is immune to cache timing attacks is possible, but it requires a lot of care, and very clear notions on how they work and how computers work. Even if you do not write assembly code, you must at least think about how the compiler for the language you are using will translate your code into assembly.

The bottom-line is that deploying your own implementations in the wild is rarely a good idea. Sometimes you have no choice, because (for instance) there is no available implementation for your target architecture and language, with a license compatible with what you want to do. This is not the common case, though.

Using the same libraries as everybody else means that whenever a nasty bug is found in your products, then your competitors have it too. From a business point of view, this is a good thing.

So you should really write your own cryptographic library... and not use it. If you can write a library, let two months pass, read it again, and not find anything wrong or suboptimal in it, then you are not trying hard enough.

  • $\begingroup$ I think the last paragraph does a great job summarizing it. I assume that new attacks are being regularly discovered, so such an approach would force you to stay on top of those issues. By extension, I guess that also means that a crypto implementation is never "done." I wish this could be combined with Mike Ounsworth's information on the business/economic aspects, but I'll accept this by popular vote. $\endgroup$ Commented May 10, 2015 at 4:09
  • $\begingroup$ What resource would you recommend if one wants to implement cryptography for learning purpose? $\endgroup$ Commented May 9, 2016 at 18:50

A lot of software security vendors will implement their own crypto libraries simply because they don't want to depend on outside code. Usually for security reasons ("we don't know who wrote it, or who's allowed to push updates to it") and/or for maintenance reasons ("every time they push an update, we have to also") Note that these companies then spend lots of time and money on quality assurance and security assurance to mitigate against vulnerabilities.

As an example: the recent SMACK vulnerability discovered in many of the standard TLS implementations (including OpenSSL, Java's JSSE, Apple's Secure Transport, etc). Anybody who linked against any of those implementations was vulnerable. If you have your own implementation, you may well have bugs, but hopefully they will be different bugs from other implementations. It's not a great answer, but it is something.

The bottom line is: only implement your own crypto libraries if you have the testing man-power and expertise to be fully satisfied that your libraries are vulnerability-free, which is inaccessible to most small- and medium-sized companies.

  • 1
    $\begingroup$ You may even need special hardware to test for things like timing attacks. $\endgroup$ Commented May 8, 2015 at 21:26
  • 1
    $\begingroup$ @NeilSmithline Also power analysis. $\endgroup$
    – Polynomial
    Commented May 8, 2015 at 22:25
  • 1
    $\begingroup$ People overestimate how hard it is to find bugs in proprietary crypto implementations. Most people will make very similar, well-known mistakes that do not require anywhere near as much skill as people assume to understand, detect, and exploit. $\endgroup$
    – ZoFreX
    Commented Nov 12, 2015 at 0:50

The problem is not really in the design of an algorithm. In published papers, an algorithm description takes only a few lines. Then you have done 0% of the crypto work: You have to find a provable lower bound for its security level, something O(the minimum amount of work a clever attacker will require). This fills pages and pages of mathematical papers, and many additional reviews by mathematicians and by cryptoanalysts. It might take years of community vetting before it would be reasonable to assume that no attack would succeed within a claimed security level. Then comes politics, where any link between you and government's agencies (apart being a taxpayer) might be perceived as the suspicion of the potential existence of a hidden backdoor in the algorithm. With enough credibility and lobbying, your algorithm might finally get accepted as a candidate in a standard. DJB's ed25519 took 10 years to take off, from description in 2005 to first RFC 7479 in 2015.

It takes a lot of investment for crypto algorithms to go thru all the steps. In fact, there are many papers every week about "authenticated third party this" and "secure iot that" and "efficient new this". And then nobody hear about them anymore. The follow-up is extremely costly in terms of dedication, resources and time.

You might try to consider your algorithm "secret", run it between your own servers and own clients, never publish it, and take the risk. But "security by obscurity" doesn't survive more than a few hours to a dedicated attacker. In an industrial environment. "secret sauce" is considered completely unsecure as soon as their author leave the company (which can happen at any time). So nobody would invest money that way, a better rational investment is to use an existing public algorithm with a proven security level which can guarantee the security of data for days, years or centuries. Back to your question : the economics of reinventing the wheel are very poor.

  • 1
    $\begingroup$ While good information, the OP clearly stated that they are asking about implementing an already existing standard, not about inventing a new algorithm. This is a great answer to a different question. $\endgroup$ Commented May 9, 2015 at 14:49

Your Answer

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

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