Crypto APIs

For decades the security community has waited for cryptographic software to become ubiquitous. To some extent we've achieved that goal—hundreds of modern applications employ strong cryptography. Many of these applications are not security tools per se, which means that non-expert developers have increasingly become consumers of cryptographic technology. Unfortunately our cryptographic libraries have not been redesigned with this consumer in mind. Most of the popular libraries sport complex and non-intuitive APIs that present the developer with numerous choices, many of of which are insecure. The result is that even experienced developers routinely select dangerous combinations. The visible consequence is a superabundance of security vulnerabilities in recent cryptographic software, including: SSL implementations that fail to properly check certificates, widespread use of unauthenticated encryption, RSA with exponent 1, and the continued use of dangerous and obsolete encryption padding schemes.

These flawed library APIs are often viewed as a mild eccentricity, or at worst a way to dissuade non-experts. In this session I argue that this view is fundamentally dangerous and counterproductive. Thousands of open source projects currently list OpenSSL's libcrypto as a core dependency—and a surprising number are finding their way into critical niches within our ecosystem. Indeed, years of careful security research are often foiled by the design of library interfaces. Perhaps worst of all, these legacy APIs are being reflected in brand new efforts such as the proposed W3C Web Cryptography API for browser-based cryptography. As a consequence. we'll be facing these problems for years to come.

In this session we'll discuss the future of cryptographic APIs, ranging from libraries to encryption applications. We'll discuss the difficulty of using these tools correctly and how cryptographers and security researchers can contribute to actually making them useful.