Hacker News Reader

Comment by anderskaseorg | Hacker News Reader

“ChaCha20 is a stream cipher which are easier to implement in software. They encrypt one bit at a time. Block ciphers like AES encrypt a block of 128 bits at a time. That would need many more transistors when implemented in hardware, so larger processors come with AES-NI - an instruction set extension that performs some tasks of the encryption process to speed it up.”

This entire paragraph is nonsense—that isn’t what a stream cipher means. ChaCha20 encrypts 512 bits at a time.

The rest of that section goes on to describe how AES-NI is available everywhere except where it isn’t, and ChaCha20 can’t take advantage of hardware acceleration except where it can—then makes a blanket conclusion that AES will “outperform ChaCha20 in every single scenario” with all those exceptions conveniently ignored.

(Are there correct, nuanced arguments to be made here one way or the other? Of course. But this article isn’t one of them.)

View on HN

The first paragraph makes no sense that's true, but what follows is a good point. AES-GCM is much much faster than ChaCha20-Poly1305.

If:

1) your market is fragmented

2) many clients are cheap phones that don't support AES-NI

3) you can differentiate them so that you don't penalize better clients

Then yeah it makes sense to use Chacha20-Poly1305 for some of these clients.

But choosing Chacha20-Poly1305 over AES-GCM all the time doesn't, and I'm not sure why Wireguard does that (besides trying to be trendy).

Sure, that's a fine argument to make. But the article says "I expect AES to outperform ChaCha20 in every single scenario", even when the very next sentence talks about a scenario where that's not true.

It's to make the design simpler. If you only use one crypto algorithm there's no cipher suite negotiation in the protocol (and thus no downgrade attacks). And while AES-GCM is faster with AES-NI, ChaCha20-Poly1305 is constructed to avoid timing side-channels (so software implementations are automatically much safer by default).

I would expect most clients to have hardware support for AES-GCM.

That's only true if most of your clients aren't mobile devices. That's why Google pushed for ChaCha20-Poly1305 standardisation and usage with TLS several years ago.

ChaCha20-Poly1305 outperforms AES on mobile devices where it matters most. The article espouses a desktop-centric view of the world that is completely obsolete.

It doesn't though, most mobile devices today have hardware support for AES.

> cheap phones that don't support AES-NI

Which are those mythical cheap phones? All the Qualcomm chips from the last N years have AES instructions, right?

Think India

4) you have customers with DSL or cable, with cheap routers, that run some 800 MHz MIPS or ARMv6 CPU. Dual core, if they are lucky. Think of the tp-links and netgears out there.

Compared to these routers, you average cheap cellphone is overpowered. 800 Mhz single or dual core is circa 2012 smartphone.

And this is on the gateway, not on the client, potentially serving several clients. Chacha20-Poly1305 absolutely murders AES there. AES won't even saturate 20MBit+ upload.

Didn't read the article but "They encrypt one bit at a time" is exactly what stream cipher is, that is, a PRNG. The resulting stream of bits from PRNG is XORed with cleartext bits to produce ciphertext bits.

Dan Bohen told me that in Stanford Cryptography courses.

That’s clearly not the way the author intends us to interpret “one bit at a time”. They intend it as some kind of explanation for why ChaCha20 is slow. (In reality, bitwise XOR is one of the fastest operations a computer can perform; it runs with as much of a parallel speedup as you have parallelism to give it, and it’s utilized extensively by practically every cipher including AES.)

Reply on news.ycombinator.com