AES and ChaCha | Hacker News Reader

AES and ChaCha

phase.dev

40 pointsnimishk10 comments

I thought more emphasis should have been given to DJB.

The article does mention that he created the ChaCha20 algorithm, and that he first characterized the timing side channel attack, but his extremely small, simple and fast source libraries are publicly available.

They are fully self contained, no dependencies, and small enough to easily include in small-ish embedded systems:

https://nacl.cr.yp.to/

Elliptic curve vulnerability to quantum computing is discussed here:

https://pqcrypto.org/

DISCLAIMER: I'm not a crypto expert, just an occasional user

DJB has been at the forefront of advancing crypto for decades, and has a very strong emphasis on simplicity and security. Any article on the subject really should reference his original source pages:

http://cr.yp.to/

I've always been a fan of "the DJB way", which is a very simple method of initializing and managing unix type systems. The voidlinux distro roughly follows these principles today.

I became familiar with him first as the author of qmail, but he has a voice in many theaters.

https://en.wikipedia.org/wiki/Daniel_J._Bernstein

ChaCha is in many ways better, but so far AES tends to win on most chips due to the existence of AES acceleration hardware. Without acceleration ChaCha is a lot faster, but with acceleration AES beats it quite a bit in both raw performance and power consumption.

Security-wise they are roughly equivalent in practice if they are used properly.

I'm curious if there are any good benchmarks of ChaCha8 (as advocated for in the "Too Much Crypto" paper https://eprint.iacr.org/2019/1492.pdf ) vs hardware-accelerated AES.

The best I could find was a rough 2.5x speedup of ChaCha8 vs ChaCha20 in the "Too Much Crypto" paper and https://github.com/jedisct1/rust-aegis#benchmarks that benchmarks ChaCha20 and various AES implementations in addition to AEGIS, where it looks like ChaCha8 might be competitive with hardware-accelerated AES on some platforms (AMD) but not others (M1).

My benchmarks are not public, but on AMD EPYC processors ChaCha12 (5 GB / s) is faster than hardware-accelerated AES-256-GCM (3.5 GB / s).

Unfortunately, this is comparing apples to oranges because AES-256-GCM is authenticated, so you will need a MAC with ChaCha12 (usually Poly1305) which finally makes ChaCha12 in AEAD mode slower than AES-256-GCM.

But the real question is: What is fast enough?

I believe that between 1 and 2 GB / s per core for an AEAD is fast enough as I/O will be your bottleneck way before that.

This is why I will always favor a ChaCha20/ChaCha12-based AEAD over AES and its many footguns.

AES itself doesn't have many footguns. GCM has footguns if not used carefully.

IIRC AES GCM does about 40-70 MB/s per core on Pi4, and ChaPoly does 150-200MB/s.

On Pi5 AES GCM does 1.5-2GB/s per core, and ChaPoly is still something like 150-300MB/s.

You can do experiments yourself with `openssl speed`.

A little over my head, but I think it is a good article for people who understands encryption more then I do.

rot13 is my limit of understanding :) But I do like reading these articles.

Everytime ChaCha/Poly come up I recall the ADRs of OTR documenting their rationale to switch from AES to ChaCha20 (see https://github.com/otrv4/otrv4/blob/master/architecture-deci...) - the document nicely highlights why AES might not always be the best tool for the job:

> We use ChaCha20 as the encryption stream cipher because it is faster than AES in software-only implementations, it is not sensitive to timing attacks and has undergone rigorous analysis ([3], [4] and [5]). We chose this over AES as future advances in cryptanalysis might uncover security issues with it, its performance on platforms that lack dedicated hardware is slow, and many AES implementations are vulnerable to cache-collision timing attacks [[6]].

One underappreciated thing about ChaCha that I think a lot of people miss is that it's not just that the operations are simple, but DJB clearly spent almost as much time approaching the design as a computer engineer as he did as a cryptographer. He obviously thought about pipelining in modern processors, available registers, cache size, implementation details that made some operations faster with specific inputs, etc. It's unlikely a generic ARX construction could achieve the same security level with the same speed without similar careful consideration of non-cryptographic factors.

Reply on news.ycombinator.com