Encryption issues account for minority of flaws in encryption libraries – research

‘Complexity is an even worse enemy of security in cryptographic software’

An analysis of cryptographic libraries and the vulnerabilities affecting them has concluded that memory handling issues give rise to more vulnerabilities than encryption implementation errors.

The study by academics at Massachusetts Institute of Technology (MIT) involved an examination of eight widely used cryptographic libraries using a combination of sources, including data from the National Vulnerability Database, individual project repositories, and mailing lists, among other sources.

Vulnerabilities in any of these widely used crypto libraries puts portions of web traffic and e-commerce transactions in danger, but the study concluded that coding rigour in the development of encryption technologies compares poorly with comparably complex mainstream software.

For example, a flaw in the widely used OpenSSL library in 2014 gave rise to the infamous Heartbleed vulnerability.

Roll the dice

The study, entitled ‘You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries’, by researchers Jenny Blessing, Michael Specter, and Daniel Weitzner, found “evidence of a strong correlation between the complexity of these libraries and their (in)security, empirically demonstrating the potential risks of bloated cryptographic codebases.”

Only 27.2% of vulnerabilities in cryptographic libraries are cryptographic issues compared to 37.2% of vulnerabilities that are rooted in memory safety issues.

Catch up with the latest encryption-related news and analysis

Non-cryptographic source code generally has a lower density of CVEs introduced compared to cryptographic libraries, the researchers found.

“Our findings suggest that cryptographic source code is indeed more brittle and prone to producing security bugs than a comparable amount of source code in a web browser or operating system,” the researchers conclude.

“The empirical data leads us to conclude that complexity is an even worse enemy of security in cryptographic software than in non-cryptographic software.”

Speaking the same language

The researchers call for a systems-based approach to cryptographic software, as well as emphasizing the dangers of “rolling your own crypto” – meaning that software developers should rely on established libraries and tools instead of developing their own.

The paper provoked a debate on the merits of different coding languages for cryptographic libraires on Twitter, in which a move away from C and C++ towards memory safe programming languages such Rust was advocated.

Open source isn’t really the answer because even in open source code, such as OpenSSL, errors like Heartbleed can go undetected for years.

Professor Alan Woodward, a computer scientist at the University of Surrey, told The Daily Swig: “Languages such as C/C++ are complex to write in and even though modern compilers and tool sets provide some safeguards against memory issues, they continue.

“As an empirical study it’s quite useful as a means of showing anyone that wishes to roll their own that they should get a real expert in both cryptography and the languages they are using to check to ensure they haven’t made a choice or used a construction that will render the cryptography insecure.”