We’ve done a pretty good job in the software world of propagating an idea: “don’t roll your own crypto.” This phrase has two meanings. The first meaning is that you should not be inventing your own cryptography. Don’t invent encryption algorithms, hashing algorithms, proof of work algorithms, signature algorithms, or really any sort of algorithm that is used to achieve security. And the second is that you should not even implement algorithms which are already known to be secure. Don’t write any code related to cryptography, use a library that was written by an expert and reviewed by several other experts.

Why? Cryptography itself is not too bad. I’ve seen middle schoolers with a strong grasp of RSA, and the code to implement it is just some math, nothing a high school programmer couldn’t figure out in a weekend. So if it’s really not that hard to understand cryptography and create working demonstrations of the cryptography in action, why does the industry stress so aggressively that you absolutely should not do it yourself?

It comes down to the fact that attackers are very clever. The gamut of potential attacks against cryptography is very wide. Some attacks are weird , some feel like the attacker is cheating, and many attacks demonstrate a high degree of creativity and intelligence. The only way to write secure cryptography is to know every single type of attack and to be able to defend against every single attack simultaneously, without making a single mistake. That is what makes cryptography hard, and it’s something that experts regularly struggle with even when working as a team.

If a team of experts regularly has trouble writing secure cryptography, what chance does a non-expert have of writing secure cryptography? None. If you are not an expert, it is unlikely that you will write secure cryptography. People are instructed to leave it to the experts for a very good reason: defending against intelligent attackers is very difficult.

You Missed a Spot

Smart contracts, though not technically cryptography, suffer from the exact same problem: they need to be secure against intelligent attackers. Smart contracts are worse in a few ways. First, there’s a monetary bounty for certain types of attacks. If you can find a vulnerability that enables theft, your reward can be tens or even hundreds of millions of dollars of digital currency. So not only do smart contracts have to deal with attackers, they have to deal with attackers that are highly motivated. One single mistake can mean millions of dollars in losses.

Smart contracts span a much wider domain than cryptography. This isn’t to downplay cryptography — writing secure cryptography already requires expertise in several intellectual domains. But smart contracts also bring in domains such as economics, game theory, and social studies. Someone looking to attack a decentralized system has far more tools available to them than someone looking to attack a piece of cryptography code. And attackers already make mincemeat of amateur (and even expert) cryptography code. As the blockchain ecosystem matures and attackers get more familiar with the tools available to them, attacks will become more common and more sophisticated.

The DAO is a great example, primarily because they made so many mistakes. Ultimately only one mistake ended up taking down the DAO, but had that mistake been corrected in time, there were plenty of other places for attackers to abuse the DAO. A nice writeup can be found here. The writeup describes something like 5 different attacks, as well as several additional weaknesses in how it was designed. As popular as the DAO was, it was terribly designed.

I wish I could say that it’s one of the worst things I’ve seen in the ecosystem, but quite honestly most projects that have done an ICO have multiple critical vulnerabilities in addition to many points of just general bad design.

Blockchain design is much harder than smart contract design. Smart contracts deal with tens to hundreds of lines of code. A secure blockchain is going to have at least ten thousand lines of code (if it’s got less, you missed something important — secure blockchains are complex), and a single mistake can leave the entire project vulnerable to something dramatic. Most non-Bitcoin blockchains have significant systemic vulnerabilities, but systemic vulnerabilities often don’t reveal themselves until you wipe out a multi-hundred-million-dollar project in one bad day. There are often few warning signals, which makes these types of issues easy to write off until it’s too late.

Typical Blockchain Security

Even experts can make simple mistakes which result in millions of dollars of loss. I can’t stress enough: to write secure applications, you need to be perfect. You need to have an expert level understanding of every type of attack, and you need to defend against them all simultaneously. Attackers can be very creative, making it easy to falsely believe that you are safe when really there’s some weird external factor you’ve never even heard of that allows an attacker to compromise your code.

Thanks to Bitcoin, blockchain design is better studied. And, the vast majority of altcoins and altchains have multiple design decisions which are well known by researchers to be insecure or otherwise problematic. Common weak spots include the peer network, strategic mining strategies, anything related to Proof of Stake, and the stubborn embrace of GPU mining. Though there are a lot of published works, most of the known vulnerabilities and antipatterns associated with poor blockchain design have never been turned into an academic paper, and are instead tucked away in IRC logs, buried forum posts, or are otherwise generally not widely known. This is not intentional, it’s just a consequence of the immaturity of the space as a whole.

The blockchain industry is having a security crisis. Your average high-profile blockchain project has multiple well studied vulnerabilities, not only failing to be perfect, but failing to demonstrate any awareness of blockchain security at all. This isn’t something you get right on accident, and working code does not imply secure code. People have already gotten hurt, and people will continue getting hurt. The software industry already understands very well that security needs to be left to experts. The blockchain and smart contract industry needs to realize that they are writing security sensitive applications, and that the same expertise that is required of cryptography also needs to be required from smart contracts and blockchains. Don’t write your own smart contracts, don’t design your own blockchains, and realize that the vast majority of high profile projects in this space were written by people who are not following this advice.