Should a company ever implement a (recent) published cryptographic protocol

Question

I understand that you should never, EVER, EVER implement your own unpublished cryptographic protocols. This topic has been well discussed in many places, e.g. here.

However, once a protocol has been published, peer-reviewed and been around for a few years, what are the general guidelines about implementing this protocol for yourself?

The general advice I've heard is don't. (e.g. SEJPM's comment to this question). Instead, use a pre-existing open source implementation that has been well reviewed such as SSL. But this has a few problems:

1. There may be restrictions on the use of such implementations.

2. Sometimes no implementation exists. The protocol may be only have been implemented 1-2 years ago, and no-one has got round to implementing it yet.

3. An implementation you find may also be faulty. Of particular concern, it is possible the authors may be aware of the fault (such as a backdoor).

And it seems that companies do implement crypto protocols without publishing the implementation, such as the product "Sharemind".

So, should a company ever implement a published protocol for a commercial product? And if so, what guidelines should they follow?

Answer 1

So, should a company ever implement a published protocol for a commercial product?

Yes, if it's something that really adds value for your users. No if it's about saving 4 signature bytes and 112 CPU cycles.

And if so, what guidelines should they follow?

• Publish the source code, at least for the crypto part, so it can be peer reviewed.
• Hire experts in the field as consultants to review the implementation.

Both of the above points will help make a strong case for adoption to clients who may have conservative attitudes to security.

Answer 2

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.

Answer 3

(I'm afraid that my approach to this question will come out as opinion based, but I'll try to support my point as well as I can)

I understand SEJPM's point of view and fully support the urgent underlying disclaimer: crypto implementations can (and likely will) go wrong. They require a lot of effort, knowledge, experience and even luck. For most purposes, good enough implementations exist and have been improved (read: in terms of performance, correctness, security, ease of use, etc.) as time goes by, but I agree with you in that some powerful and strongly recognized concepts from academy (e.g. homomorphic encryption, zero knowledge proofs) are severely lacking in the implementation department.

In my opinion, the main step to break that limitation is a serious standardization effort. This would need to cover at least encoding, accepted protocols and good practices (but most likely won't stop there). The risk of it is that a huge amount of effort might end up being nothing more than splashing on the sea: ignored, wasted and not profitable at all. But that needs to be addressed: if non-security-critical important decisions (e.g. how to encode a Zero Knowledge proof?) have to be made once and again, a lot of time will be wasted and every solution ever created will be incompatible with the rest (not to mention the fact that hardware acceleration hangs between "non-existent" and "possible as a hack for a very specific functionality"). I can only think of the hell Internet would be if every vendor implemented its own way to encode a digital certificate or chose to implement AES from scratch (even with standards like X.509 and PGP compatibility is not trivial these days).

So, the effort needs to be undertaken by a group of people who are very familiar with the topics and can turn good ideas into an industry standard. Most likely a group of big companies or a standardization group. Otherwise it will likely be just a toy project, and I've seen several of those in GitHub, abandoned after a few months.

So the questions to ask are clear: can the security objectives be achieved by using an existing, tested implementation? If the answer is no, are said objectives so critical to be worth an industry-shaking project?

If so, there are a lot of details to juggle. The concept should be simple (as in "non-complex", not necessarily as in "easy"), proven, submitted to a lot of scrutiny (it seems this point is covered in your case) and the development process needs to be realistic in scope and keep risks in mind (and act to respond to them). Security needs to be regarded with a lot of care at every stage of the process and testing needs to be thorough. Most likely, the development process will take years and the most valuable parts of the intelectual property will need to be made public.

So, in short, my point of view is that such implementations are a dire need for the industry, but the effort required is overwhelming and not so many use cases have been identified to justify it. Which in general leads to one conclusion: very very very likely, it won't be worth it.