Hacker News new | ask | show | jobs
by aseipp 3610 days ago
What mobile platforms implement ChaCha20? Can you point to any? I'm not aware of any widely available handset that claims to do this.

In fact, the whole reason ChaCha20/Poly1305 was even added to the TLS profile in the first place is because Google originally added it to their own OpenSSL fork, BoringSSL, as well as Android, and it was later proposed for inclusion in the standard. Google wanted a cipher that performed better in software than AES did - because the vast majority of all mobile platforms and handsets do not support AES acceleration either (ARMv8 does introduce cryptographic extensions for the SHA family and AES family, but 99% of handsets aren't those. Also I'm not sure if ARMv8 has a PCLMUL-equivalent for fast GCM computation, which is also a critical component of that scheme.)

That costs energy and battery life, because AES is very difficult to implement efficiently and securely in software, and even the fastest, most secure implementations are relatively slow. In contrast, ChaCha20 is incredibly simple to implement securely in software, even an efficient version is very-well within grasp of mortals (I've managed to do it myself).

That's why your Android phone uses ChaCha20 - not because it has hardware acceleration, but because it's fast in spite of not having it.

I'd be interested to know if any actual hardware implements this in the wild. Generally, a combination of AES-256 with GCM for systems with hardware acceleration, coupled ChaCha20/Poly1305 as a fallback software method, seems to be the way people are going. And ChaCha20/Poly1305, with enough effort, can get very close to rivaling AES performance in hardware on a contemporary x86 machine (ignoring actual ASICs and endpoint devices with hardware offload). For non-hardware AES impls, ChaCha should absolutely crush it in terms of performance.

1 comments

It's actually the opposite AFAIK. One of the selection criteria for the Advanced Encryption Standard (AES) was cheap hardware implementations, and it's one reason why Rijndael was chosen over some of the stronger ciphers.

DJB has criticized the selection criteria for both AES and SHA3 as being too focused on hardware efficiency. In his opinion it was much more important for software implementations to be simple and efficient. His algorithms tend to be elegant in software but complex in hardware, pretty much guaranteeing his candidates would never be chosen.

I'm not an EE so feel free to correct me, but I closely followed the standards process both times and that's my recollection of things.

> It's actually the opposite AFAIK. One of the selection criteria for the Advanced Encryption Standard (AES) was cheap hardware implementations, and it's one reason why Rijndael was chosen over some of the stronger ciphers.

Oh, I was aware of that bit (vaguely; to be fair I was a child during the AES competition, so I only remember a small bit of the history), I just meant AES is a bit slow in software relative to ChaCha today, is all, which I could have clarified.

EDIT: I think I realized now what you meant. When I said ChaCha20/Poly1305 could, with effort, rival AES-256 in hardware in the last paragraph of my post, what I meant was: a software version of ChaCha20 can get very close to a hardware version of AES, providing you put in a lot of effort.

I can see how that sentence is a mis-parse, sorry about that.

> DJB has criticized the selection criteria for both AES and SHA3 as being too focused on hardware efficiency. In his opinion it was much more important for software implementations to be simple and efficient. His algorithms tend to be elegant in software but complex in hardware, pretty much guaranteeing his candidates would never be chosen.

Yes, this is the basic impression I've gotten as well from all his work - to be fair, software implementations are much more agile and easy to deploy, so I think putting some focus on this is a good thing.

I am also not an EE, but I've heard similar things of this nature before (e.g. that ChaCha/Poly would be much more expensive in hardware compared to AES, which is truly a con, not a pro). I'd be interested if any actual EEs would chime in here.

But yes, given all that, I think AES-GCM + ChaCha/Poly1305 is a good pair that should cover most of your bases for an AEAD, for fast hardware and software implementations.

Not sure about ChaCha but I implemented Salsa20 on a microcontroller. Looked to me that you could generate a mechanical proof that it's 'secure' IE, doesn't have a hole in the design. Also that the microprocessor isn't going to expose you to an oddball timing attack. The adds, xors and rotations aught to be single cycle and the code paths never change based on any of the results.