Usually, in programming, reusing code is always a better idea than writing your own implementation of an algorithm. If an implementation has been around for a long time and is still used by lots of projects, it is likely to be pretty well designed to begin with, have received plenty of testing and debugging, and perhaps most important someone else is in charge of maintaining it which means more time to focus on the specific software product that you are building.

However, I was wondering if this principle still holds true for security-critical code, which performs tasks such as encryption and authentification, or which runs with high privilege for any reason. If one implementation of an algorithm is shared by lots of software systems, then there is a strong incentive for people to crack it, and when a flaw is found in it, it is likely to be a massive security disaster. Heartbleed and Shellshock are two recent examples that come to mind. And for closed-source examples, pick anything from Adobe :)

Many different pieces of software sharing a single security-critical library also makes this library a target of choice for attackers wanting to insert a backdoor in it. In a large open-source project with lots of activity, a backdoor commit which also features plenty of other corrections (such as a code style cleanup) as a decoy is unlikely to be noticed.

With all this in mind, is code reuse still considered a good practice for code doing security-critical tasks? And if so, which precautions should be taken to mitigate the aforementioned weaknesses of that approach ?

The important thing is maintenance. Regardless of whether you reused existing code or wrote your own, you will achieve decent security only if there is someone, somewhere, who understands the code and is able to keep it afloat with regards to, say, evolution of compilers and platforms. Having code without bugs is best, but in practice you must rely on the next best thing, i.e. prompt fixing of bugs (especially the bugs that can be leveraged for malicious usage, also known as vulnerabilities), within a short time frame.

If you write your own code, then the maintenance job relies squarely on your own shoulders. And that job can be very time-consuming. For instance, if you decide to write and maintain your own SSL/TLS library, and use it in production, then you must understand all the peculiarities of cryptographic implementation, in particular resistance to side channel attacks, and you must keep an eye on published attacks and countermeasures. If you have the resources for that, both in time and competence, then fine ! But the cost of maintenance must not be underestimated. Reusing an existing library, especially an opensource one that is widely used, can be quite cheaper in the long term, since maintenance is done by other people, and widespread usage ensures external scrutiny. As a bonus, you cannot be blamed for the security holes in an external library if half the World shares them.

To sum up, the question is not really about code reuse, but about maintenance effort reuse.

(I write all this independently of the great pedagogical qualities of writing your own code. I encourage you to do your own implementations -- but certainly not for actually using them in production. This is for learning.)
