As the snows of Crypto Winter melt and a thousand seed rounds bloom, too many Web3 teams are making the mistake our forebears have warned about for decades: They’re rolling their own crypto.
Crypto, in this case, means cryptography — the software and mathematical techniques that secure the internet, your credit card and the Web3 protocols we know and love.
Why is crypto different from, say, general app development? Think of it this way. If you’ve just developed the hottest new platform for streaming bird videos to tech-savvy cats, you’re probably thrilled if it works 99.9% of the time. But if instead you’ve built the hottest new crypto wallet, preventing attempted thefts 99.9% of the time obviously won’t work: Attackerswill just keep trying until they’ve drained your users’ funds. Persistence is worthwhile when the payoff is a payout.
Unfortunately, as computer security legend Bruce Schneier says, “Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break.” The tough part, as Schneier says, is building systems other people can’t break. Sadly, Web3 teams emboldened by inexperience (and overworked auditors) keep rolling their own crypto. What’s the result?
Bad crypto implementations
Cryptographic algorithms are incredibly delicate. Even a well understood, secure algorithm is easy to break if it’s implemented poorly.
Consider the hundreds of millions of dollars stolen in the last two years because of a textbook mistake: Generating secret keys in a predictable way that’s easy for attackers to guess. We still see these bugs a few times a year, even though avoiding them is Cryptography Engineering 101.
But not all bugs are that simple. Some take engineering intuition and expertise to spot, and not all cryptographers specialize in engineering. Applied cryptographers and crypto engineering specialists are well-versed in subtle implementation bugs because (hopefully) they’ve written Web2 crypto code, Web3 crypto code, and maybe even papers about how to write crypto code. In contrast, theoretical cryptographers are well-versed in theory, but are much less concerned with code-level intricacies.
In short, don’t be fooled: Not everyone with “cryptographer” in their title has the training or expertise to write cryptographic code that’s used by real people to protect real things.
Broken deployments
Even if a system is theoretically sound and implemented well, it can still be deployed poorly.
Take the Ronin bridge, which lost over half a billion dollars in 2022. Users’ funds were supposed to be protected by a five-of-nine majority voting mechanism, but a series of stunningly poor deployment decisions led to its demise. In the end, five of the nine voting keys were effectively controlled by one company (Sky Mavis), allowing attackers to hijack a majority of the votes with a single compromise.
Designing and deploying secure systems that resist attackers is another specialty that’s distinct from cryptography theory and engineering — and it’s one that’s often overlooked in Web3. That’s probably why, in the aftermath of the Ronin attack, commentators tut-tutting about “more decentralization” completely missed the point. The issue was with quality, not with quantity.
Harmful complexity
Finally, there’s a Web3-specific disease that’s making all of this worse: A fetish for unnecessary use of bleeding-edge buzzword crypto — things like “fully homomorphic encryption,“ multi-party computation” or “zero-knowledge proofs” — for problems that simply do not need big-iron solutions. These polysyllabic crypto heavyweights aren’t just immature, they’re even more brittle and even harder to implement correctly. And in most cases, they’re being used to attract attention (and investment), not because they’re the right tool for the job.
Read more from our opinion section: Crypto crime is too easy
What’s the problem with that? Well, if you asked a landscaper to plant some azaleas and they showed up with a backhoe, you’d have some questions (especially if a minor slip maimed the neighbor’s dog). And if the landscaper replied with a jargon mad-lib, you probably wouldn’t interpret your confusion as a sign of the landscaper’s deep azalea wizardry.
The same is true in Web3. When the sales pitch is just technobabble conveying little more than “we have the heaviest cryptography on the block,” ask yourself: Has the team made it clear that they need the big guns, specifically, that nothing simpler could solve this problem? Usually, the answer is no.
So we’ll say it again: Don’t roll your own crypto! Maybe start checking the “About Us” page before trusting a project with your — or worse, your users’ — cryptographic secrets.
And if the answers to your security questions have a low signal-to-buzzword ratio — or if the team acts like their product is too advanced for mere mortals to understand — consider looking somewhere else.
Riad is co-founder and CEO of key management infrastructure provider Cubist and an Assistant Professor at Carnegie Mellon University. He is an applied cryptographer and leading academic researcher on zero-knowledge proofs and their applications. He is a co-inventor of proof systems including Lasso, Hyrax, and Brakedown, and he has co-authored cryptographic specifications including RFC9380 and the BLS signatures standard used by Ethereum, Avalanche and many other blockchains. Riad received his SB and MEng in Electrical Engineering and Computer Science from MIT, and his PhD in Computer Science from Stanford.
Fraser is co-founder and CTO of Cubist and an Assistant Professor at Carnegie Mellon University. She is an expert in software correctness: her research focuses on systems security, automated bug finding and formal verification, from verifying (parts of) production systems like browser JITs, to finding exploitable bugs in real codebases. Her tools have found many zero-day bountied bugs and CVEs in the Chrome and Firefox browsers and multiple operating systems. Fraser received her BA in English and her MS and PhD in Computer Science from Stanford.