This recent paper “From Collisions to Chosen-Prefix Collisions – Application to Full SHA-1” by G. Leurent and T. Peyrin puts another nail in the coffin of SHA1. The authors present a chosen-prefix collisions attack to SHA1 which allows client impersonation in TLS 1.2 and peer impersonation in IKEv2 with an expected cost between 1.2 and 7 Million US$. The authors expect that soon it will be possible to bring down the cost to 100.000 US$ per collision.
For what concerns CA certificates, the attack allows, at the same cost, to create a rogue CA and fake certificates in which the signature includes the use of SHA1 hash, but only if the true CA does not randomize the serial number field in the certificates.
It is almost 15 years that it is known that SHA1 is not secure: NIST deprecated it in 2011, it should not have been used from 2013 and substituted with SHA2 or SHA3. By 2017 all browsers should have removed support for SHA1, but the problem is always with legacy applications that still use it: how many of them are still out there?
Obviously the title of this post is provocative, but reading some recent news it is evident that us, IT professionals and IT industry, are not good in managing cryptography. The consequence is that we deploy cryptography in IT products and give a false sense of security to the users. This actually can have worse consequences than if we would not use cryptography at all. I will give just a couple of examples.
This research paper shows how a well-known brand of hard disks has implemented disk encryption in totally faulty ways, to the point that for some disk models hardly any security is provided by the built-in disk encryption functionalities. This is just another of many similar cases, where cryptographic protocols and algorithms are incorrectly implemented so to cancel all or most of the security that they should provide.
Another research paper shows how a well-funded agency or corporation can in practice break the encryption of any data encrypted with the Diffie-Hellmann (DH) key exchange algorithm using keys up to 1024 bits included. Should we be shocked by this news? Not really since already 10 years ago it was known that a key of 1024 bits is too short for DH. Indeed, as per RFC 7525, a 1024 bit DH key offers a security less than a conventional bit security of 80 bits, but again RFC 7525 states that the absolute (legacy) minimum required conventional bit security must be 112 bits, and the current minimum required conventional bit security is 128 bits, that would practically correspond to a 2048 bits DH key. Even if we, IT professionals and IT industry, have known for at least 10 years that 1024 bits DH keys are too short to offer security to the data that they should protect, as of today a too large number of HTTPS websites, VPNs and SSH servers use DH keys of 1024 bits or less (see again the research paper mentioned above).
Unfortunately these are not two isolated examples, recent news are full of similar facts. So I start to wonder if we are good enough to manage cryptography or if we should look into something else to protect IT systems.
Besides CRIME, BEAST and Lucky13, two new attacks for SSL/TLS have been just announced. One attack exploits weaknesses in the RC4 cypher, which is used by most websites starting from Gmail, and many cryptographers had been thinking about this possibility for a long time, now they found out how. The second attack, called TIME; is a new timing attack, in part a refinement of CRIME.
As of today, both attacks are not practical, but they could become real threats in the future. Notice that the adoption of RC4 by many websites has been mostly to withstand BEAST attacks. Now that Lucky13 and this new attack aim at RC4, it is not clear what to do in practice.
Of course, we should seriously consider what to do with SSL/TLS and even more the CA model, but it will take a long time and I do not see among the big internet players, enough motivation or incentive to change the current situation.
You can find a summary description of these new attacks for example in this article by ArsTechnica.