62
I believe there are three main reasons why ChaCha20 is sometimes preferred to AES.
On a general-purpose 32-bit (or greater) CPU without dedicated instructions, ChaCha20 is generally faster than AES. The reason for this is the fact that ChaCha20 is based on ARX (Addition-Rotation-XOR), which are CPU friendly instructions. At the same time, AES uses binary ...
18
Unless we find information from Google - such as white papers & mailinglist posts - we can only speculate why ChaCha20 is chosen. I think that efficient software implementation is still the most likely reason. That AES-GCM is relatively brittle - for instance with regards to timing attacks - could be another.
Note that even though AES-NI is becoming ...
14
The library uses XChaCha20Poly1305 and that requires a nonce of 192-bit (24-byte). It is an extension of ChaCha20Poly1305 to increase the nonce size, ChaCha20 had 96-bit nonces. There is no standard for it, only a draft in ietf.org
The nonce is an acronym for 'number used once'. The crucial point is that one must never use the (Key, nonce) pair again. We ...
13
I am using here the description and terminology from RFC 7539.
ChaCha20 is meant to process messages, each message being a sequence of bytes; ChaCha20 produces pseudorandom blocks of 64 bytes each, which are XORed with the data to encrypted or decrypt. The crucial security property is that all invocations of the ChaCha20 block function for a given key use ...
13
I'm answering the following which was asked in the original question:
Why is stock chacha20 not good as a cryptographic hash? Why create BLAKE?
Why not simply apply the one-way compression function concept on raw chacha20, specifically its quarterround() function, unaltered.
TL;DR: Chacha was meant as a stream cipher, it needs a different kind of security ...
12
You really don't want to use ChaCha20 alone in (nearly) any situation.
What ChaCha20 does for you is to prevent attackers from (passively) reading your data, which is good. But ChaCha is a so-called stream cipher which works by XOR'ing a pseudorandom pad with the message (your file at rest). However it is for this very way of working that ChaCha doesn't ...
12
Quoting RFC 8439 (emphasis mine):
The Advanced Encryption Standard (AES — [FIPS-197]) has become the
gold standard in encryption. Its efficient design, widespread
implementation, and hardware support allow for high performance in
many areas. On most modern platforms, AES is anywhere from four to
ten times as fast as the previous most-...
11
Do all TLS cipher suites using "ChaCha20-Poly1305" use Poly1305-AES?
Nope, AES is indeed replaced with ChaCha20 in TLS. The Poly1305 one-time key is generated pseudorandomly using the ChaCha20 block function. The ChaCha20-Poly1305 TLS cipher suite spec draft uses the AEAD construction from RFC 7539, which defines exactly how this works:
The ChaCha20 and ...
11
There are in the RFC : http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-7
The following blocks contain test vectors for ChaCha20. The first line contains the 256-bit key, the second the 64-bit nonce and the
last line contains a prefix of the resulting ChaCha20 key-stream.
KEY: ...
11
If you reuse a nonce, you lose confidentiality for the messages with that nonce. Messages with other nonces retain their confidentiality.
However, the attacker can also attack the MAC part (Poly1305) and generate a third and more messages with the same nonce. See: Why is Poly1305 popular given its 'sudden death' properties?
So unless you have a way ...
11
As cypherfox had correctly pointed out during our chat, two rounds is not enough to reliably diffuse a single changed bit throughout the entire output.
My question appears to have been answered directly by Bernstein's page on diffusion for Salsa20 (note that ChaCha has better diffusion).
Quoting https://cr.yp.to/snuffle/diffusion.html
The following pictures ...
11
No, it doesn't need a random nonce. Yes, if you use an incrementing counter, that works.
As the RFC says, the only requirement is uniqueness; as long as you make sure that each nonce you use is different, you have met the requirements - an incrementing counter does that quite nicely (and, in fact, is commonly used in practice)
10
ChaCha builds on a 512 bit permutation and then applies a feed-forward by xoring the input into the output. Without truncation, that feed forward is essential for one-way-ness.
We're going to build a one-way function that maps a 32 byte value x to another 32 byte value y.
Using truncated ChaCha including the feed-forward
Put the x into the 32 key part of ...
10
I agree that conservatism is the likely reason for the choice in McBits.
ChaCha was published while eSTREAM was still running. Salsa20/12 is now in the final eSTREAM portfolio. Even in the XSalsa paper on constructing a larger nonce, Bernstein makes no mention of ChaCha.
So what are the reasons to prefer Salsa20 over ChaCha?
Wanting to use a ...
10
It basically depends on what you consider side-channel attacks.
If you consider time/cache side channel attacks than chacha20 has been design with resistance to such attacks in mind while AES didn't.
In fact, AES is vulnerable to these kind of attacks (as they were invented after AES was designed). But, hardware implementations, such as AES-NI are ...
10
The documentation on libsodium AEAD constructions provides more details.
Namely, it lists Hk(random ‖ m) as a way to compute a synthetic XChaCha20 nonce. Even if random is not unique, the nonce is unlikely to be the same for different messages.
Even more relevant are the sections on nonce-misuse resistance and short nonces.
Note that like all other nonce-...
10
Attacks on a cryptosystem with a 128-bit key are often much cheaper than $2^{128}$. If you have the strings $\operatorname{AES}_{k_1}(812738)$, $\operatorname{AES}_{k_2}(812738)$, $\dots$, $\operatorname{AES}_{k_{1000000}}(812738)$, it costs only about $2^{128}/1000000 \approx 2^{108}$ AES evaluations to find one of the $k_i$ keys if you can parallelize it $...
answered May 30 '19 at 18:26
Squeamish Ossifrage
43.6k3 gold badges88 silver badges185 bronze badges
10
There's simply no way to know. I find it very unlikely that AES will be vulnerable to a ciphertext-only attack in the next 20 years (remember, it has been around for over 20 years already and attacks haven't gotten very far). There's no reason to believe the same won't be true for ChaCha20. If you use a good cipher with 256-bit keys (to avoid potential ...
9
The obvious way of implementing ChaCha20 involves nothing but additions, fixed rotations, and XORs. All of these are constant time, so the obvious way of implementing ChaCha20 is secure against timing attacks. The main way that ChaCha20 is made faster -- SIMD -- does not change this.
On the other hand, the obvious way of implementing AES uses table ...
9
First, this is not safe with ChaCha because the ChaCha nonce is only 64 bits long, since ChaCha nonces are normally chosen sequentially, so there would be a nonnegligible danger of collision with a reasonable number of messages. Let's say XChaCha instead, with a 192-bit nonce, which is large enough to choose at random without danger of collision.
The ...
9
idle speculation, my personal favourite! i always thought it was after the dance...
Salsa dance - see the video (Video demonstrating salsa dancing fundamentals) and jump to ~1min05sec in, the section titled: "side-side-quarter-turns", if you'd prefer to remain seated...
and from (https://en.wikipedia.org/wiki/Salsa20), The Salsa quarter-round function. ...
8
Generally speaking, there are (at least) three reasons to put a KDF in between an DH shared secret and the bulk encryption.
Improved re-usability. If you don't post-process the shared secret with a KDF there's no way to give the sender and the recipient different keys for each direction or to split up authentication and encryption keys. An additional bonus ...
8
Yes, all modern symmetric ciphers strife to offer (approximately) x bits of key strength for an x-bit key size, just like AES. If they don't, we presume they are broken.
Although there have been attacks on Salsa / ChaCha using fewer rounds, it doesn't seem that any attack has reduced the bit strength of the full cipher. Furthermore, differential ...
8
OK, so the core ChaCha primitive (for any fixed number of rounds) is a function $\operatorname{ChaCha}: \{0,1\}^{256}\times \{0,1\}^{64}\times\{0,1\}^{64}\to \{0,1\}^{512}$ which is believed to be a secure PRF when the first input is the key.
So now that we know what ChaCha is, for the desired functionality of hashing:
At a fundamental level it's unclear ...
7
It would be extremily surprising if the ChaCha core was a permutation (as the last P in PRP), although we have no proof it is not (if it was a permutation, it would at least be one we do not known how to invert, see this question).
A better approximation is that the ChaCha core behaves as a Pseudo-Random Function with the additional property $\text{...
7
Unfortunately, there is no specification for XChaCha20. But several implementations provide a HChaCha20 function, built the same way as HSalsa20.
XChaCha20 can be built with HChaCha20 + ChaCha20, and the security proof is similar to the one for XSalsa20.
The Libsodium documentation has a section on HChaCha20, which includes a code snippet to build ...
7
TL;DR: Fortuna is a CSPRNG so you can replace components pretty arbitrarily, because you're not bound by compatibility requirements and the modifications should work, although there are some points that are note-worthy.
In Fortuna (PDF), AES-256 is used in exactly one place: To generate the keystream based on the current counter (the function is even called ...
7
Besides the IV, ChaCha20 takes a random number and a counter as input.
No it doesn't (sec. 2.4):
The inputs to ChaCha20 are:
A 256-bit key
A 32-bit initial counter. This can be set to any number, but will usually be zero or one. It makes sense to use one if we use the zero block for something else, such as generating a one-time authenticator ...
7
You do not require a new key. You use a different initialization vector (IV) for every message.
As long as you use a different pair of (key, nonce) for each message you retain the confidentiality and integrity of messages. The nonce is the initialization vector.
7
Aumasson et al. Showed that ChaCha6 can be attacked with time complexity $2^{139}$ and ChaCha7 with $2^{248}$.
Shi et al. gave an attack based on second-order differential with $2^{136}$ for ChaCha6 and $2^{246.5}$ for ChaCha7.
Maitra, chosen IV cryptoanalysis and the time complexity of the attack showed that it can be reduced to $2^{239}$ for ChaCha7.
...
Only top voted, non community-wiki answers of a minimum length are eligible
