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 ...
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 ...
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 ...
11
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 ...
10
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 ...
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
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: ...
10
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 ...
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-...
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
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 ...
9
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)
8
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 ...
8
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 ...
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
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
39.8k3 gold badges76 silver badges164 bronze badges
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
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
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
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 ...
6
Maybe. But your scheme hasn't been vetted by the community for its impact.
Better to use XSalsa20 or the related XChaCha20 as recommended by Bernstein himself: http://cr.yp.to/snuffle/xsalsa-20110204.pdf
In my opinion it was a fairly major faux pas that DJB originally chose short 64-bit nonces for Salsa20 and ChaCha20, especially given all the nonce-misuse ...
6
Can we exhibit collisions, or second-preimages (with implies the former), for the ChaCha core?
No, likely not.
The Salsa20 and ChaCha cores both consist of a large number of "quarter-rounds" each of which is invertible and bijective. The only reason neither core is a bijection (and thus can have collisions) is the final addition of the input elements into ...
6
Without looking at the code I would say your construction is pretty much the same as XChaCha20:
From https://download.libsodium.org/doc/advanced/xchacha20.html
Internally, XChaCha20 works like a block cipher used in counter mode.
It uses the HChaCha20 hash function to derive a subkey and a subnonce
from the original key and extended nonce, and a ...
6
From the RFC you can see that a ChaCha20 block is constructed as follows:
state = constants | key | counter | nonce
Which is then processed in a number of rounds. So lets keep that in mind for the following Q/As.
1. Is it being implied that that using the same block counter repeatedly is a risk?
Yes. If you use a 32 bit counter then it is presumed to be ...
6
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.
6
The only difference between these is the nonce size (and, consequently, the internal counter size). The core function is exactly the same. They all offer the exact same security level if they are used as expected.
The trade-offs are described in the AEAD section of the documentation.
XChaCha20-Poly1305-IETF is the one that has the largest nonce size. This ...
5
Note that, in Salsa20, the loads and additions of the key words ($x_1$, $x_2$, $x_3$,
$x_4$, $x_{11}$, $x_{12}$, $x_{13}$, $x_{14}$) are critical for security, since the double-round function is
trivially invertible. One might think that the remaining loads and additions could
be skipped without sacrificing security, achieving almost half of the ...
5
The reason for the padding (and re-positioning of the AAD length) in the later draft is to make implementations easier and faster - i.e. not for a security reason.
The rationale for this change was actually documented on the CFRG mailing list by Alyssa Rowan:
Instead of the lengths directly following their ciphertexts:
draft-agl-tls-chacha20poly1305-...
Only top voted, non community-wiki answers of a minimum length are eligible
