Evaluating Crypto Libraries Without Being a Crypto Expert

So now we’ve ruled out low-level crypto libraries. What should we use instead? High-level crypto libraries with secure defaults written by experts.

But how do we know experts when we see them? Evaluating people based on skills we don’t have ourselves is a tough problem with no great solution. We encounter it in other parts of our life. How do we evaluate doctors, mechanics, lawyers, plumbers, and other specialists with skills we don’t have? We tend to use a few techniques. We can look for professionals with certifications. Sometimes we can look for professionals who have written helpful books, articles, or blog posts. We ask our friends or look to the wisdom of crowds and check ratings online.

When we apply any of these, we find folks like Bernstein and Lange (authors of NaCl) and Bleichenbacher and Duong (authors of Tink) pass with flying colors. But since we’re in cryptography, we have one more technique we can bring to bear. When we evaluate a library, we can look at the track record of its authors. What have they broken? What have they built and how has that held up to scrutiny? Add this metric, and you’ll find Bernstein, Lange, Bleichenbacher, and Duong have about as impressive a trophy case as you’re going to find.

Track record of reputable libraries

So what have the authors of these libraries done that should inspire confidence?

Bernstein and Lange

Bernstein and Lange are accomplished academics with a strong body of work. In addition, their work on NaCl has stood up to widespread scrutiny for many years. NaCl uses Bernstein’s Salsa20 cipher extensively. Bernstein’s related ChaCha20 cipher has been used by Google for securing TLS communication since 2014, which is a nice compliment on the strength of ChaCha20. Additionally, Bernstein’s earlier work on programs such as djbdns and qmail has also stood up to widespread usage and scrutiny for many years.

Bleichenbacher

Daniel Bleichenbacher is most famous for the “Bleichenbacher attack” against RSA. He first described this attack in 1998. His attack allows for decrypting RSA encryption without direct access to the decryption key. Twenty years later, this attack is still relevant. It was the inspiration for Hanno Böck, Juraj Somorovsky, and Craig Young’s ROBOT (Return Of Bleichenbacher’s Oracle Threat) attack. The ROBOT attack even won the 2018 Pwnie Award for Best Cryptographic Attack.

Duong

Thai Duong co-discovered the BEAST, CRIME, and POODLE vulnerabilities in SSL/TLS. The BEAST attack, discovered by Duong and Rizzo, allows an eavesdropper to decrypt TLS 1.0 communication. Its discovery was a major factor in the adoption of the TLS 1.1 standard. The CRIME attack, also discovered by Duong and Rizzo, leverages HTTP compression to decrypt HTTPS traffic to steal cookies and hijack sessions. Finally, we have the POODLE attack, discovered by Bodo Möller, Thai Duong, and Krzysztof Kotowicz. POODLE allows a man-in-the-middle attack during the TLS handshake that allows the attacker to downgrade what would have been a TLS connection between a browser and a server to a much weaker SSL 3.0 connection.

So when we look at the achievements of these four library authors, we can have more confidence in their implementations and configuration choices than we’d have in some other library chosen at random. They’re only human and can certainly make mistakes just like anyone else. But we can be pretty sure that, at the very least, their libraries won’t be vulnerable to the attacks that the authors are famous for.

We haven’t talked about the authors of libsodium. They’re smart people as well, but we don’t need to focus on their careers as much because they’re porting NaCl, not designing a system from scratch. So we don’t have to trust their API choices, just their implementation abilities.

NaCl, libsodium, and Tink are high-level cryptography libraries. When we look at their APIs, we see that the authors have made all of the low-level design choices for us. We don’t have an opportunity to choose or misconfigure obscure cryptographic settings. This combination of a misuse-resistant API and distinguished authors is what makes these libraries good choices.

This takes care of how we encrypt and decrypt arbitrary data. As we’ll see in the next section, encryption and decryption aren’t what we want for storing the passwords of our clients. Instead of encryption, which is reversible if we have the password, we’ll want to use one-way algorithms that can’t be reversed aside from brute-forcing.

                                                 Q U I Z