At what point can you you implement crypto algorithms?

Question

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.

Answer 1

"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.

Answer 2

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.

Answer 3

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.