When preparing the Methodology for calculating the "HTTPS Reliability Index", we rummaged through a lot of thematic literature and more than once came across a recommendation to support cipher suites based on the CHACHA20 encryption algorithm on a web server in order to reduce the load on mobile clients that cannot use hardware AES. In this context, Mediatek processors and "old budget mobile processors" were usually mentioned.
Does CHACHA20 with its trusty companion POLY1305 really keep mobile clients cool and is it worth supporting it on a web server? Let's discuss it!
CHACHA20 was created by renowned cryptographer Daniel Bernstein, whom we love for Curve25519 in particular, and for his advocacy work that only oldfags remember what _EXPORT_ stood for in a cipher suite. The algorithm is well researched, operates in AEAD mode, has no known weaknesses or vulnerabilities, and is one of two encryption algorithms approved by the IETF for use in TLS 1.3 (the other is immortal AES).
Its theoretical cryptographic strength when used in TLS is estimated differently, in the interval between AES-128 and AES-256 in GCM mode, which is considered sufficient by today's standards and for the foreseeable future. At the same time, it is notedthat CHACHA20 is "faster" than AES, i.e. "Consumes less processor resources to provide the same level of cryptographic strength." This formulation not only smells like telemarketing (with all due respect to its author), but also misses an important detail: on processors without AES hardware support.
And here we finally return to "budget mobile processors" that overheat under AES, start to throttle and demand liquid nitrogen (sarcasm). Processor manufacturers are aware of the problem and have solved it by adding an appropriate set of instructions. In x86-compatible processors, this is AES-NI, in others - their names (and their own set). And here we come to the most interesting part: AES support by processors.
Intel introduced AES-NI support in 2010 in Westmere processors, and not all: Atom, Celeron, Pentium and Core i3, it has not been relied on for a long time. You can be sure of AES-NI support without digging into the specifications only starting with the Goldmont architecture (Apollo Lake and Denverton), and this is already 2016.
For AMD, these are the Bulldozer (2011) and Jaguar (2013) architectures, with ARM everything is more complicated: support for AES instructions is provided in the ARMv8-A architecture (2011, the first device is 2013), but their actual implementation in silicon depends on the manufacturer processors and I personally would not whistle so confidently about "old budget mobile processors", rather it is worth talking about "non-flagship mobile processors" in general, incl. produced to this day.
Simply put, it's not that hard to come across a processor without AES hardware support. So CHACHA20 is really a great alternative to AES? Let's take a look at the results of this study , for example . On processors without AES support, CHACHA20 noticeably outperforms it in performance, often several times. Unfortunately, we were not shown temperature measurements, but if we are talking about a server processor, it is obvious that the difference in the consumed processor resources is significant.
The situation is reversed when it comes to AES-capable processors. It is hardly worth blaming CHACHA20 for this, to whom no one offered a personal set of instructions in the processor, and what happens when both players play by the same rules, we saw on old processors (I remind you: AES merges).
So, let's go for CHACHA20 support on web servers? Why not, at least for the reason that all eggs are not put in one basket, and if suddenly tomorrow a hole is found in AES itself or its implementation in a specific crypto library, we can turn it off "until clarification" with a slight movement of our hand, staying on CHACHA20, and not frantically looking for something to replace AES, but how it turns on.
The question of the place of CHACHA20 in
Let's remember how the cipher suite is generally negotiated when establishing an HTTPS connection: the client sends the server a list of the cipher suites it supports, in order "from the bully" and this order can be changed only through Windows group policies and only for
The priority of cipher suites on the server is usually set on the basis of the principle of maximum available security: the stronger cipher suites are listed first, less - the last. A modern client stumbles upon a strong cipher suite and agrees on it, an "outdated" client jumps further down the list to a less strong cipher suite and agrees on it. Everyone is happy, everything works, from each according to his ability, to each using HTTPS.
And here a cipher suite based on CHACHA20 fits into this harmonious picture of the world, which we add for reasons of reducing the load on clients "weak" from the hardware point of view, without knowing anything about whether they are simultaneously "outdated" or not (i.e. this year's flagship from a third-tier Chinese company, or a mid-range five-year-old from a top-tier brand). Customer advises that it supports TLS 1.3 and a full suite of associated cipher suites, both AES and CHACHA20. Your solution, admin, what cipher suite are we agreeing to the client? Here I am about the same ... I
summarize the above about the CHACHA20 encryption algorithm.
- The algorithm is quite good for itself and is suitable for use in TLS.
- Cipher suites based on it are supported only by fairly modern browsers , so there is no need for AES at all.
- The performance gain from its use can be obtained not only on "old budget mobile processors", but also on desktops and servers. On processors with hardware support for AES, the situation is reversed.
- When establishing an HTTPS connection, there is no way to know if the client's processor supports AES in hardware. Accordingly, there is no way to know which cipher suite will be "faster" in each case.