So, should a company ever implement a published protocol for a commercial product? And if so, what guidelines should they follow?
I'm going to elaborate on the last question; The other answers cover the other parts pretty thoroughly.
The first thing to be aware of is that writing code for cryptography that will be used in practice is not a standard exercise in application programming. We recently had a question about implementation practices in cryptography, and some developers who were not that familiar with crypto coding were in literal disbelief at some of the practices used when writing crypto code.
So the first thing to watch out for is:
> Do(es) the developer(s) have any experience implementing cryptographic algorithms?
If the answer is "no", then implementation should be avoided. There are plenty of ways to turn a theoretically invulnerable cryptographic algorithm into something that can be broken in practice for surprisingly little effort and time.
Standard programming bugs with common data types are now security problems. You need developers that are consciously aware of this fact.
Some algorithms are vulnerable to side channel attacks: Certain algorithms may be implemented in certain ways that leaks internal information through alternative information channels; Here's a list of concerns that can require an active, conscious effort to mediate:
- Cache attack — attacks based on attacker's ability to monitor cache accesses made by the victim in a shared physical system as in
virtualized environment or a type of cloud service.
- Timing attack — attacks based on measuring how much time various computations take to perform.
- Power-monitoring attack — attacks that make use of varying power consumption by the hardware during computation.
- Electromagnetic attack — attacks based on leaked electromagnetic radiation, which can directly provide plaintexts and other
information. Such measurements can be used to infer cryptographic keys
using techniques equivalent to those in power analysis or can be used
in non-cryptographic attacks, e.g. TEMPEST (aka van Eck phreaking or
radiation monitoring) attacks.
- Acoustic cryptanalysis — attacks that exploit sound produced during a computation (rather like power analysis).
- Differential fault analysis — in which secrets are discovered by introducing faults in a computation.
- Data remanence — in which sensitive data are read after supposedly having been deleted.
- Row hammer — in which off-limits memory can be changed by accessing adjacent memory.
- Optical - in which secrets and sensitive data can be read by visual recording using a high resolution camera, or other devices that have such capabilities.
Formal Proofs of Implementation Correctness
If you were really serious about implementing whatever it is, you could win much favor by creating an implementation that is formally proven correct. There are specialized languages for doing this.
Basically, if you:
- Are implementing a standardized algorithm
- It has already seen sufficient peer review
- Have an implementation that is secure against at least basic side channel attacks
- Have an implementation that is formally proven correct
I cannot see a good reason for anyone to complain about such an implementation; Few existing libraries offer such a collection of features, and the world would probably better off if we had more software that did meet these requirements.
But...
It is very unlikely that your average web, application, or system developer will be familiar with the tools/languages/techniques required to produce such implementations, regardless of how long they have been working for.
Many of the developers who are familiar with such things studied them in pursuance of a doctoral degree - formal proofs of correctness and active counter measures against DPA attacks are simply not something the average programmer is concerned about, let alone even aware of.
Put simply...
You would know whether or not your team of developers was prepared to produce an acceptable/successful implementation.
If your development team does not consist of members with prior experience implementing algorithms securely and/or proving their correctness, it is probably a bad idea to have them implement anything. As for the reasons why...
The cost of failure
When you have a bug in a normal piece of software, the worst case scenario is something like your application crashes while in use by a client.
When you have a bug in your crypto software, your clients information becomes at risk:
- If your clients are using your software because they cared about protecting their information, you failed to deliver this result
- If they paid you for it, they may be extra upset
- This could damage the reputation of your business
- This could cost your business money
The bottom line is the one a business is obviously most concerned with. The rest apply even if you are not charging for your software.
Before implementing a cryptographic algorithm/service to offer to clients, be sure to weigh the risks versus the potential for profit - do not become so focused on the potential profit that you overlook all the very real possibilities for your venture to incur losses and cause real damages to the lives of those that use it.