Project Wycheproof Reveals Bugs In Popular Crypto Libraries
Written by Nikos Vaggalis   
Wednesday, 21 December 2016

Google has released Project Wycheproof, a set of security tests that check cryptographic software libraries for known weaknesses. Having developed over 80 test cases more than 40 security bugs have been uncovered.

googlelogo color 120x44dp

In order to have good cryptography two ingredients require to be in place. The first is the strength of the cipher primitive itself. This is a property that  classifies it as suitable or not to build an application on. For example in the TLS protocol, documented in "SSL and TLS Deployment Best Practices-Use Secure Cipher Suites" not all ciphers are recommended for use. In that list for example, we find some obsolete cryptographic primitives that are not secure and must be avoided:

  • Anonymous Diffie-Hellman (ADH) suites do not provide authentication

  • NULL cipher suites provide no encryption

  • Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken

  • RC4 is insecure

  • 3DES is slow and weak

The second factor is the library that implements the cipher. Are you sure that it's bug free? One such counter-example is the mcrypt function from library libmcrypt, popular in PHP applications despite the many weaknesses as documented in If You're Typing the Word MCRYPT Into Your PHP Code, You're Doing It Wrong

Code auditing is the norm when looking for such bugs, and now Google engineers join the cause with Project Wycheproof in an attempt to address the concerns regarding the (in)security of software libraries, as a direct result of internal code audits of the crypto components that Google uses in its products, that finally found its way to the public as well.

Project Wycheproof is thus a collection of unit tests that check cryptographic software libraries for known weaknesses in RSA, elliptic curve crypto and authenticated encryption.
 
In the short amount of time that the project is alive, more than 40 bugs were already uncovered through undertaking 80 complete unit tests.
The tests available on GitHub cover some of the most widely used algorithms like :

  • RSA
  • DSA
  • ECDH
  • Diffie-Hellman

against their implementations in Java Cryptography Architecture providers such as Bouncy Castle, Spongy Castle, and the default providers in OpenJDK.

In order to run those tests, say for Bouncy Castle or OpenJDK, you need to have Bazel installed and then run the test as following:

bazel test BouncyCastleAllTests

or

bazel test OpenJDKAllTests

One of the most worrisome of the bugs uncovered is the leakage of private keys by Bouncy Castle's ECDHC implementation, since ECDCH will totally replace RSA for key transporting in the forthcoming TLS 1.3 version, as such a library hosting a weak  implementation poses a matter of prime importance.

Many things can go wrong when implementing algorithms, and as a matter of fact in the TLS 1.3 draft there is a whole section dedicated to implementation pitfalls that can be potentially encountered when designing a library or application:

  • What countermeasures do you use to prevent timing attacks?

  • When verifying RSA signatures, do you accept both NULL and missing parameters?  Do you verify that the RSA padding doesn't have  additional data after the hash value? 

  • When using Diffie-Hellman key exchange, do you correctly preserve  leading zero bytes in the negotiated key ?

  • Does your TLS client check that the Diffie-Hellman parameters sent      by the server are acceptable?

  • Do you use a strong and, most importantly, properly seeded random      number generator when generating Diffie-Hellman private values, the ECDSA "k" parameter, and other security-critical values?  It is RECOMMENDED that implementations implement  "deterministic ECDSA" as specified in [RFC6979].

  • Do you zero-pad Diffie-Hellman public key values to the group size?

  • Do you verify signatures after making them to protect against RSA-CRT key leaks?  

As such Project Wycheproof becomes a valuable addition to the pursuit of applying cryptography correctly, as getting it right is much too difficult, therefore the case for rigorous testing or the use of proven secure products such as in the CMS field, Paragonie's open source AirShip CMS in contrast to the known vulnerable ones the likes of Drupal, Joomla or Wordpress.

 

googlelogo color 120x44dp

More Information

Project Wycheproof on GitHub

TLS 1.3 draft

Related Articles

Airship, a truly secure PHP CMS

Crypto 101 - A Free Ebook 

 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

 

Banner


Pico 2W Announced But There Is A Surprise!
25/11/2024

Raspberry Pi released the Pico 2 a few months ago and we have been waiting for the Pico 2W since then. But Pimoroni beat them to the draw with the Pico Plus 2W based on the RM2 radio module and hinted [ ... ]



Swimm Releases Copilot Extension For Documentation
03/12/2024

Swimm, best known for its AI-driven software documentation tools, has announced an extension for GitHub Copilot. The Swimm team says the extension means developers using GitHub Copilot Chat can turn C [ ... ]


More News

 

espbook

 

Comments




or email your comment to: comments@i-programmer.info

 

Last Updated ( Wednesday, 21 December 2016 )