Cryptography in Your House: 10 Mistakes You Probably Make and How to Avoid Them

In this post, I will talk about a few mistakes that are often made by those who work with cryptography. This happens more often than you think, even when you do not design cryptographic protocols explicitly: when you work with authentication, communication channels, plan the architecture for your project or discuss scalability issues — cryptography is involved.

Of course, you want to avoid mistakes. You have heard many hacking stories where million-dollar thefts were made possible by webmaster mistakes. With cryptography, it is even worse. If you have weak crypto, attackers will read your communications, log into your servers, take your money — and you will never notice it until it is too late. Mistakes in cryptography are often exploited without leaving a footprint.

This article summarises a presentation made at ZKLux#1 — Luxembourg Zero Knowledge Days on 27 June. A video of the presentation is available here.

Mindset

First, you have to change your mindset. Crypto tools are not just another framework — they are rather the skeleton of your application upon which the rest sits. As with the framework of a building, cryptography involves higher risks (you lose more in case of error), is more expensive to work with and is difficult to repair during the lifetime of the finished product. Worse yet, if there is a problem, you will only know about it after everything falls to pieces.

Mistake 1: Inventing your own crypto

Creating a new crypto scheme is surprisingly hard, error-prone and risky. Even professional cryptographers often fail at it. Academic conferences are full of attack papers that break cryptographic designs, both in theory and practice. 80% of cryptographic schemes designed by cryptographers get broken, and this rate reaches 99% for those designed by non-cryptographers. Of course, sometimes you do need your own cryptography, for example, when you need a new protocol. Then you have to hire a specialist.

Mistake 2. Security by obscurity

Are you often tempted to design an algorithm or protocol but hesitant to tell others the details? You might think that a mistake might damage your reputation. However, this is wrong-headed: the details of the scheme are often easy to reverse-engineer. Instead, ask for third-party analysis. The more such reviews you get, the better protocol you obtain. Later, reveal your design to a wider audience and ask for feedback (it might even come for free). Remember, after centuries, cryptographers have come to a conclusion: “the only secret part of a scheme should be the secret key”.

Protocol Design

Sometimes you need a new protocol that is tailor-made for your business, and you have checked that no analogue is available. Then indeed, you need a cryptographer.

Mistake 3. One cryptographer is enough. You hired a good guy, gave him the task and the money, and you are now waiting for the result. Apparently, even the best cryptographers do not work alone. A big part of security comes from public scrutiny, so first, review the crypto design with other team members, even non-cryptographers. Then, go to the public, using rewards or competitions if you can. In the design, favour clarity and brevity over complexity (this can be asserted even by a non-cryptographer; see something complex — ask for simplification).

Mistake 4. It works, so it is good

Suppose you mentioned a serious problem to a friend, and in a week he suddenly came up with a solution. It works and is reasonably fast. Should you accept it right away?

In cryptography design, the answer is often “No”. The solution might not be optimal, or it may be less secure than potential alternatives. And it turns out that a week is too short, particularly if the implementation is also done and optimized in that time.

Mistake 5. Just some privacy is enough

Suppose you design a privacy-preserving money transfer system. However, transfers are not fully anonymous because it would be too expensive (computationally, in internal currency, etc.) to make it so. A cheaper system allows the candidate senders to be narrowed down to 10,000. Is it good enough?

Apparently not, as there are many ways to amplify the privacy loss. Suppose an attacker saturates the network with dummy transactions, sending 99.9% of all of the traffic. Then the problem of identifying one sender is only 1-in-10.

The rule is that there is no ‘some privacy’ — there is privacy or no privacy.

Mistake 6. Complex setup

Your team comes up with a fast and secure solution. However, it requires a lot of time and work to initialize. Should you adopt it?

Probably not. A sophisticated setup may be difficult to repair. For example:

1. In March 2018, a researcher for the anonymous cryptocurrency Zcash found out how to print fake coins. The problem was in the setup phase, which used some privately-generated random numbers, and some of them were present in the public setup data due to poor design.
2. A call for a new setup would reveal the problem with the old one, which could then be identified and exploited. The Zcash team decided to keep the problem secret for a few months (!) until a scheduled new setup, risking an attacker finding the problem himself and exploiting it covertly.

If the setup had been easy to change and roll out, it would not have been necessary to take this risk.

Implementation

OK, the problem has been solved: a beautiful and secure protocol has been found. Now it is time to implement it.

Mistake 7. Key stored everywhere

You deal with secret keys in many components. Should you store them everywhere where they are used to minimize the risks of transmission?

Apparently not. A better solution is to design a special component that stores all keys and to guard it properly.

Mistake 8. Old libraries and old coding style

You see a set of well-established open-source libraries for cryptography in a familiar programming language. Should you use them?

First, check the following:

• Support of the primitives (curves or ciphers) that you need
• Protection from recent attacks (proper key and nonce length, data format, etc.)
• Side-channel protection, if applicable
• Conformance with standards
• As usual: support and licensing

Also, open-source does not imply the absence of bugs.

Mistake 9. Programmers who design and optimize

Good programmers are keen on cryptographic design, often thinking it is as easy as regular architecture design.

Crypto designed by good coders has cleaner code but has questionable design decisions.

A cryptographer and programmer should work in a pair and review each other’s work.

Mistake 10. Wrong source of randomness

Most programming languages have built-in randomness generators.

However, these might be enough for statistical tests only.

• Use one master seed from a proper randomness source, or ideally a combination of sources.
• Derive further randomness deterministically and irreversibly from the seed using standard techniques (like HKDF).

Summary

1. Do not invent your own crypto.
2. Make the design public and auditable.
3. One person is never enough.
4. Working does not mean `good`.
5. A little privacy means no privacy. The same goes for security.
6. Secure your keys in one place.
7. Reevaluate third-party code.
8. Good programmers are not crypto designers.
9. Use cryptographically strong randomness and derive further randomness from it.