I thought this was for Chacha the site, and I'm equally bewildered that service is still running after twelve years!
The design of Chacha20
11–20 of 76 posts
Re: The design of Chacha20
#12How 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?
It'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.
Re: The design of Chacha20
#13How 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?
AES 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
2 - https://software.intel.com/en-us/articles/improving-openssl-...
Re: The design of Chacha20
#14How 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?
If 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.
Re: The design of Chacha20
#15How 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?
AES is a block cipher, Salsa/ChaCha are streams.
This makes them very useful for, say, file encryption with random access.
Re: The design of Chacha20
#16Earlier quoted context omitted.
Well, NaCl (DJB's encryption library) uses XChaCha20, doesn't it? Edit: Nope, it's XSalsa20.
NaCl provides Salsa20 and XSalsa20 ( https://nacl.cr.yp.to/stream.html ). libsodium adds ChaCha20 ( https://download.libsodium.org/doc/advanced/chacha20.html ) but not XChaCha20.
That's coming soon: https://github.com/jedisct1/libsodium/blob/master/src/libsod...
Re: The design of Chacha20
#17> [re magic "expand 32-byte k" string] And it's readable ASCII text, so you can be pretty sure there's no back door in there. I am not sure this matters? I mean, facebook managed to get a reasonably nice .onion routing id (facebookcorewwwi.onion) by bruteforcing stuff right? I can imagine bruteforcing the "backdoor key space" to find something that looks good, am I insane?
I was wondering about this, too. To put even more paranoia at the table: Readable ASCII means that every byte is in a certain range. For example, bit 7 is 0 for every byte. Maybe this allone enables a backdoor. That is, the mere fact that this is readable ASCII could enable a backdoor. Who knows?
This theory probably contradicts the usage of block cipher in counter mode. With them, the input block is usually full of zeros. This constraint has strengthened ciphers in the past. DJB wrote somewhere that some block cipher were broken in CBC mode (all the bock can be controlled by the attacker), while CTR mode was still safe (many bits forced to zero).
Re: The design of Chacha20
#18> [re magic "expand 32-byte k" string] And it's readable ASCII text, so you can be pretty sure there's no back door in there. I am not sure this matters? I mean, facebook managed to get a reasonably nice .onion routing id (facebookcorewwwi.onion) by bruteforcing stuff right? I can imagine bruteforcing the "backdoor key space" to find something that looks good, am I insane?
It adds significantly to the cost of putting a backdoor in. Perfect security is impossible, it's all about increasing the costs to attackers.
Re: The design of Chacha20
#19How 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?
AES is a block cipher, Salsa/ChaCha are streams. This makes them very useful for, say, file encryption with random access.
These days people use AES-CTR (or authenticated encryption modes based on AES-CTR, like AES-GCM), which can be treated as stream ciphers.
Re: The design of Chacha20
#20The author seems to favor XChaCha20 over ChaCha20, even though XChaCha20 is not part of any formal standard or any widely know paper. [1] It would be interesting to know what DJB (the author of ChaCha20) thinks about XChaCha20 and related variants. [1] http://crypto.stackexchange.com/a/34605
I took some liberty here, but this is a straightforward derivation of XSalsa20. I trust XChacha20 just as strongly as I trust Chacha20.
The same cannot be said about my implementation however. I haven't found test vectors for XChacha20, so for now I have to rely on code review (only my own eyes so far) to ascertain its correctness. Not ideal.
Also I don't favour XChacha20 over Chacha20, because it is slightly slower to initialise. If a 64-bit nonce is enough, I'll use Chacha20. Maybe I should make this clear in my article.