It’s been almost a year since we released our 2016 Crypto Recommendations to coincide with the launch of our crypto service discovery and analysis tool. These rules also form part of the analysis set for our application crypto Analyzer.

Since then, there have been a number of interesting results in cryptanalysis as well as new implementation bugs found in common crypto software. It’s time to update our recommendations to take this into account. Here are the main changes we’ve made to our ruleset:

SHA-1

The hash function SHA-1 has been creaking for some time. Despite some interesting bets between cryptographers, no public full collisions on the function emerged this year. However, web browser vendors have all moved to cease treating SSL certificates with SHA-1 digests as trusted in 2017, hence we penalise more harshly such certificates in our TLS analysis rules.

Diffie-Hellman Key Exchange

There were more interesting results this year on backdoors and “fishy” standard groups for Diffie-Hellman key exchange. Here, “fishy” means that the group parameters appear in a standard without any justification that they are in some sense “random” or “safe”. The danger is that the group may be backdoored, for example by using values that create a small subgroup a so that malicious actor could force you to choose a key in a small range. We now test for the dubious groups highlighted in recent research in our tools (and we open-sourced our group list).

64-bit blocksize ciphers

We already penalized use of 64-bit blocksize ciphers like 3DES and Blowfish because of the possibility of birthday attacks. In 2016 new results showed that in many real world deployments such as in VPNs, generating the conditions required for an attack is practical or near-practical. In any case there is very little need to use these ciphers in TLS configuration any more, so we now flag it up.

SSLv3 and RC4 in SMTP

In last year’s recommendations we suggested removing weak SSL and ciphersuites from mailserver configurations even though some guides suggest this is a bad idea (because if no SSL exchange can be negotiated, the exchange falls back to plaintext). We argued that bad cryptography is worse than no cryptography. A few weeks later, the DROWN attacks were announced, using old SSL v2.0 to break sessions that employed modern TLS v1.2. Later in the year, Google turned off SSL v3.0 and the creaking stream cipher RC4 on their mailservers. So we’re now penalizing SSLv3.0 (as well as SSLv2.0 of course) even on mailservers in our assessments (previously it was only an informational warning for anything other than HTTP).

You can try out the updated rules on network protocols at discovery.cryptosense.com, or get in touch to try our Analyzer on an application.