At what point can you you implement crypto algorithms? 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.
"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.