Why another set of crypto recommendations?
National and international standards bodies like NIST, ENISA and PCI already make recommendations about key-lengths and algorithms, so why write another set? At Cryptosense we've been working on a simple web-based tool to discover external-facing crypto services, and we needed a pragmatic set of best-practice standards for evaluating the results. If we used the ENISA "future application" standards, for example, pretty much the whole Internet would get an F.
So, we've compiled our criteria from what's considered secure for current and "near-term future" applications in NIST, ENISA, ANSSI and BSI standards, advice from our colleagues at INRIA team Prosecco, what's recommended by specialist sites like SSL Labs, and some ideas from the excellent Better Crypto project. Below we explain the reasoning behind the rules we use, and then how we apply them to TLS- and SSH-based services our tool discovers. At discovery.cryptosense.com you can see them in action - we also use them as the basis for the default rules in the Java App Tracer and our PKCS#11 tools.
Algorithms and Key-Lengths
Symmetric Block Ciphers
We follow ENISA and endorse AES and CAMELLIA for future applications. ENISA consider 2 and 3 key DES and Blowfish OK for legacy use but not for future use, because though they do not have practical attacks, they have some results on reduced-round versions and a small blocksize (64 bits) that makes them unsuitable for some applications. Following their logic, we also add SEED and IDEA to the list of ciphers which are OK but only for legacy, as they have similar results and blocksizes.
Although widely used, the stream cipher RC4 is increasingly considered broken. In 2015, more examples emerged of practical attacks when RC4 is used for HTTP over TLS. Replacements considered secure by ENISA that are currently available in some common APIs include ChaCha20.
RSA is still considered secure if correctly used, which means with OAEP padding. In 2015, we saw more real-world occurrences of the Bleichenbacher attack on RSA encryption when the old, insecure PKCS#1v1.5 padding mode was used. There will no doubt be more in the future.
RSA-PSS is considered secure though again RSA-PKCS#1v1.5 is more widely used. There have also been recent occurrences of Bleichenbacher's other attack on this scheme, though they rely on the public key exponent being low.DSA and ECSDA are only endorsed by ENISA for legacy applications. In some practical settings, DSA is not even suitable for this. For example, in SSH, the maximum DSA keysize is 1024 bits, which is not long enough to be considered secure even for legacy applications.New signatureschemes currently considered secure and available in some APIs include Ed25519. This seems almost certain to become the standard curve for use in TLSv1.3, though argument still rages on the IETF CFRG list.
New results emerged in 2015 about the practicality of collision attacks on SHA-1. So, this is no longer considered a secure hash function for applications where collision-resistance is important. The SHA-2 family are still considered secure, for the moment. We consider MD5 broken.
HMAC is still secure even when the underlying hash function is not collision-resistant. So we still consider using SHA-1 in an HMAC as OK. However, HMAC-MD5 gets a warning because the tag length is short, meaning that collisions could be found using brute force by powerful adversaries. As the recent SLOTH attacks showed, HMAC collisions can often lead to surprisingly powerful attacks.
We base our 2016 recommendations on the "near term future" keylengths recommended by the major standards bodies. As they are not always in agreement, we sometimes have to choose, as shown in the table below. (Note that for longer-term future use, all the standards bodies recommend much longer keys, partially motived by the possibility of practical quantum computing. If this seems like something you don't need to worry about yet, try attending one of Dan Bernstein and Tanja Lange's talks on the subject).
Elliptic Curve keylength
StandardNISTENISABSICryptosense 2016Near-term p3072307220482048q256256256256
Applying the rules to Crypto Services
As we recently discussed, 2015 was the year of FREAK, LOGJAM, and several other TLS vulnerabilities. These showed the need to eliminate weak ciphersuites even if look like they won't be used, and to apply rigorously guidelines on Diffie Hellman groupsize and RSA keylength. One exception we make in our analysis is that we still mark 2048 bit RSA keys used as TLS certificates as OK, but with an information point that this is less than ENISA recommend for the future but more than the legacy cut-off. Since TLS 1.2 makes the use of RSA PKCS#1v1.5 mandatory, we don't mark down for this (even though the countermeasures against Bleichenbacher attacks are somewhat fragile). However, we do mark down if you don't have any alternative key exchange methods available that provide forward secrecy. We score SSL V2 and V3 as insecure (both are officially deprecated by the IETF), but we judge TLS 1.0 and TLS 1.1 as OK, even though they have issues and are slated to be deprecated, for example, by PCI DSS in 2018. TLS has in the past mostly been examined for its security when serving webpages, i.e. HTTP traffic. Some attacks are specific to this usage. However, it is increasingly employed to protect other services, for example mail transport (SMTP) and reading (IMAP, POP3). Since TLS coverage is patchy in SMTP, some guides recommend leaving all ciphers and protocols enabled, arguing that any encryption is better than no encryption at all (which is the fallback if a successful TLS session cannot be negotiated). We disagree. Bad cryptography can be detrimental to security of otherwise secure sessions. Hence we still rate use of SSL V2 in SMTP STARTTLS as insecure. SSL V3 is more tricky since attacks like POODLE don't seem to work on SMTP. Hence for the moment we mark it as an information point rather than a failure, but this we expect to change.
We flag up servers that offer RC4 as insecure. Rare occurrences of SSH version 1.0 are marked as insecure. We apply the keylength rules above to DH groups and RSA keys. We also check for DSS keys, which are limited to 1024 bits in SSH and hence insecure.