JP: Fighting Snake-Oil and Analysing Security v Performance - Analysed, Attacked, Wounded and…
JP: Fighting Snake-Oil and Analysing Security v Performance - Analysed, Attacked, Wounded and Broken
I try to always have a research paper which I read (which I define as my “45 bus into work paper”), and try and make sense of. I normally give it around a week’s reading time and make notes on my iPad. A major challenge is always to try and understand the method in a way that other could understand. And so my favouriate research paper of the year has just been posted on IACR [here]:
The paper has a sole author of Jean-Philippe (JP) Aumasson and who works at Teserakt AG, Switzerland. Overall it is a highly readable paper, and provides a great background on the tension between security and performance. In the NIST scoring systems, for example, for SHA-3 and AES, the scorecard tried to balance security and performance, but in a world of IoT, would it be better reducing the security levels, in order to support less power drain, or faster computations on limited capacity devices?
On the way to the NIST standardization process, researchers have the chance to compromise the ciphers, so the authors of the methods tended towards the side of making them as secure as possible. Thus 256-bit AES requires 14 rounds of S-boxes, and row and column scrambling. But why 14? Why not 10?
So if the current level of key discovery is around 2⁸⁰ (with the best cloud-based GPU cracking rig), is it worth it to increase the security from 2¹²⁰ to 2²⁰⁰, when 2¹²⁰ is already 2⁴⁰ (nearly a million million) more times difficult than with current methods?
JP has never really been one to hold back on his viewpoints, and here is a tweet related to the TIME AI presentation from Crown Sterling at a recent Black Hat event:
And so in the paper JP outlines the history of attacks against the leading symmetric key encryption methods: AES (Rijndael) and ChaCha20, and the leading hashing methods: SHA-3, SHA-1, SHA-256 and BLAKE2.
In a brilliant turn he drives against those snake-oil actors who say that something is vulnerable, if it has even the smallest sign of a vulnerability, with the classifications of:
- Analyzed: This is where an attack is less efficient than a known attack, but it is important to publish it for its methodology. The example given is a key-recovery time of 2¹⁰⁰ for a 128-bit key cipher.
- Attacked: This is where it is shown there is an attack, but where the security levels make it practically impossible to break. The example given is a key-recovery time of 2²²⁰ for a 256-bit cipher.
- Wounded: This defines where an attack puts a method into the “at danger: zone, and where any further improvements would push it into the broken region. A example of this would be a key recovery time of 2¹⁰⁰.
- Broken: This defines when an attack becomes realistic at the current time or some time in the near future. An example of this is a key recovery in 2⁸⁰ operations.
The current state of the art of key recovery is around 2⁸⁰, and where we have 80 bits of entropy. Anything defined as broken is likely to be cracked for a reasonable expense and within a reasonable time. The wounded methods are the ones — such as SHA-1 — which are at risk.
In the end, JP steams home with his viewpoint on how we can balance security [1]:
- AES: 9 rounds instead of 10 for AES-128, 10 instead of 12 for AES-192, 11 instead of 14 for AES-256. This yielding respectively a 1.1×, 1.2×, and 1.3×speed-up.
- BLAKE2: 8 rounds instead of 12 for BLAKE2b, 7 rounds instead of 10 for BLAKE2s(we’ll call these versions BLAKE2bf and BLAKE2sf), yielding respectively a 1.5×and1.4×speed-up.
- ChaCha: 8 rounds instead of 20 (that is, ChaCha8), yielding a 2.5×speed-up.
- SHA-3: 10 rounds instead of 24, yielding a 2.4×speed-up.
It is not just a speed-up that provides the key benefits here. We can also reduce the crypto footprint on limited capacity IoT devices. With these devices we often have a limited amount of processing, and memory and limited capabilities for the power drain. Limiting the number of rounds for the crypto process could thus reduce the power drain on the device.
Wow! Not many researchers would be so bold to say that we should be reducing the rounds, but he goes ahead and boldly does it! I am so pleased to share a research space with JP, and who uses evidence-based work against those who sell security as snake-oil.
Postscript
If you are interested, here’s AES: https://www.youtube.com/watch?v=rSyvUYbMok8
BLAKE2: https://asecuritysite.com/encryption/blake
SHA-3: https://www.youtube.com/watch?v=bTOJ9An9wpE&feature=youtu.be
References
[1] Too Much Crypto, JP Aumasson, Teserakt AG, Switzerland, https://eprint.iacr.org/2019/1492.pdf