6 ms·
How does ChaCha20 compare to the established AES standard? Is it stronger? weaker? faster? slower? easier to implement correctly? harder to implement correctly?
by vog 10y ago
How does ChaCha20 compare to the established AES standard? Is it stronger? weaker? faster? slower? easier to implement correctly? harder to implement correctly? better for some other reason? worse for some other reason?
- cwmma 10y agoIt's main claimed benefits are that it is resistant to side channel timing attacks, simpler (easier to implement correctly) and faster. all things being equal, in practice AES is often implemented in hardware which gives it an advantage.
- wolf550e 10y agoAES is hard to implement on a general purpose computer in a way that is both fast and doesn't leak through cache timing attacks. The safe way to use AES is by using a hardware implementation, like modern x86 and some ARM CPUs. The best software implementations use bitslicing and SSE, but are still slow. The best I saw is an Emilia Kasper and Peter Schwabe paper[1] from 2009 on bitsliced AES-GCM has 21.99 cycles/byte performance for constant-time implementation authenticated AES-GCM. For comparison, Intel shows[2] 0.77 cycles/byte for same with a hardware implementation, albeit on a newer CPU. Chacha is fast on modern general purpose CPUs without the need for a hardware implementation of chacha. One reason it's fast is that it was designed so that a normal compiler can generate machine code from regular-looking C code in such a way that it uses vector (wide) registers and uses independent operations to use as many operations in the CPU in parallel in the same clock cycle, without requiring an assembly wizard to do that. Intel can afford assembly wizards (i.e. Shay Gueron), other people can't. Modern TLS stacks prefer AES when running on a CPU that has AES hardware and fallback to chacha otherwise. They of course fallback to either a slow or an insecure implementation of AES if the other side doesn't support chacha. 1 - https://eprint.iacr.org/2009/129 https://eprint.iacr.org/2009/129 2 - https://software.intel.com/en-us/articles/improving-openssl-performance#_Toc416943489 https://software.intel.com/en-us/articles/improving-openssl-...
- floodyberry- 10y agoBasic Chacha C implementations do not get auto-vectorized down to ultra-efficient code. The most efficient implementations are intrinsic/assembler that process 4 (SSE2/AVX/NEON) or 8 (AVX2) Chacha20 blocks at once. This is due to layout of variables and operations being designed for efficient SIMD use and the blocks being independent of each other. (Shay's Chacha20 implementation is also not the fastest!)
- koverstreet 10y agoBut ChaCha is simple enough that even implementing it in assembly with AVX or whatever isn't all that hard.
- rstuart4133 10y agoBasic GNU C implementations don't get auto-vectorised full stop. But with a little bit of effort Chacha20 can be made to vectorise. The implementation in here is vectorised by GNU C: https://sourceforge.net/p/pbkdf2/code/ci/default/tree/pbkdf2.c If "ultra-efficient code" means what could be produced by a programmer highly skilled in some amd64 implementation (intel core2, amd bulldozer, ...) for that implementation then yes I doubt GNU C produces it. But the odds are GNU C's output runs faster than that's guru's code on other amd64 implementations.
- floodyberry- 10y agoThat Salsa implementation is not being vectorized? Salsa also requires some values to be shuffled around to actually work in SSE registers, djb made a bit of a boo-boo when designing it. Chacha fixes that, so its SIMD implementations are a bit more straightforward.
- JoachimS 10y agoIf you don't have HW-acceleration, for example AES-NI instructions in x86-64, ChaCha will normally be quite a lot faster. Esp on 32-bit and 64-bit architectures. Being a stream cipher you can also precompute the keystream. This reduces encrypt/decrypt to a simple XOR when handling the message - depending on message length of course. And yes, AES-CTR can also be used like this.
- TillE 10y agoAES is a block cipher, Salsa/ChaCha are streams. This makes them very useful for, say, file encryption with random access.
- wolf550e 10y agoThese days people use AES-CTR (or authenticated encryption modes based on AES-CTR, like AES-GCM), which can be treated as stream ciphers.
- tptacek 10y agoThere's virtually no difference in utility, since pretty much the only thing we ever do with a block cipher is adapt it to encrypt streams --- this is true conceptually even when we're not literally turning the block cipher into a PRF with something like CTR mode.
- the8472 10y agoUnder the hood chacha is a block cipher too. It just happens to have counter mode baked in, which turns it into a stream cipher.
- nightcracker 10y agoUnder the hood ChaCha is a 128 bit -> 512 bit hash function with a 128 bit key, running in CTR mode to get a stream cipher. It is most assuredly NOT a block cipher under the hood.
- loup-vaillant 10y agoErr, the key can be 256-bits. This is the preferred key size these days.
- nightcracker 10y agoOops, that should indeed be 256 bits (8 * 32 = 256). The rest of the comment stands though.
- tptacek 10y agoChacha/Salsa is: * Intrinsically simpler than AES * Easier to implement * As an ARX design, doesn't need S-boxes, and so doesn't leave a cache footprint * Has free key setup AES is: * A global standard * Available in hardware on most platforms (extremely important) * A conventional block cipher for which a bunch of modes (in particular: wide-block and AEAD) are already defined But unlike Salsa, AES: * Has relatively complicated key schedule (you have to expand its key input to a series of per-round keys, which imposes a cost when you switch keys) * Relies on S-boxes for security and so must carefully avoid microarchitectural side channels * Is much harder to implement * Is not a native stream cipher, so requires an adapter (usually: GCM mode) to use safely. AES is usually faster on modern systems because it's implemented directly in silicon. Salsa is usually the fastest pure-software option. Both are so fast that the speed difference is not particularly important, but most systems will prefer AES when hardware support is present. Salsa is almost certainly the better choice for new designs just because of its simplicity. It's harder to screw up Salsa20 or its derivatives than it is to screw up AES (it is very easy to screw up AES), and its performance is more than satisfactory.
- the8472 10y ago> * A global standard ChaCha is standard enough to make it into TLS and IPSec
- tptacek 10y agoYes, but that's true of all sorts of things that aren't really global standards. Don't get me wrong: you should use Salsa ciphers. I'm just trying to provide the most honest possible accounting.
- stouset 10y agoEven then, they actually used a tweaked version of ChaCha20 that uses a 96-bit nonce (just barely large enough to be suitable for randomly-generated nonces) and a 32-bit counter (limiting its use to 128GiB for a given nonce). Also, an extension XChaCha20 was recently published which performs an extra 20 rounds to initialize the cipher state, allowing for 192-bit nonces with no corresponding reduction in counter size. So now there's three variants of ChaCha20 * ChaCha20 (256-bit key, 64-bit nonce, 64-bit counter) * IETF ChaCha20 (256-bit key, 96-bit nonce, 32-bit counter) * XChaCha20 (256-bit key, 192-bit nonce, 64-bit counter)