On Mon, Jun 13, 2016 at 08:00:33PM +0200, Stephan Mueller wrote: > > 1. The ChaCha20 is seeded with 256 bits (let us assume it is full entropy) > > 2. The ChaCha20 block operation shuffles the 256 bits of entropy over the 512 > bit state -- already here we see that after shuffling, the entropy to bit > ratio fell from (256 bits of entropy / 256 data bits) to (256 bits of entropy > / 512 data bits). > > 3. The code above directly returns the output of the ChaCha20 round to the > caller. Considering the discussion in step 2, I would assume that the entropy > content of the output size is cut in half. This is a CSRNG, not an entropy pool. One could make the same argument about an AES Counter based DRBG. So you could start with an 256 AES key, and then after you return ENCRYPT(AES_KEY, COUNTER++), you've "halved" the entropy in the AES CTR-DRBG state. Oh, noes!!! The reason why I don't view this as a problem is because we're assuming that the cipher algorithm is secure. With /dev/urandom we were always emitting more bytes than we had entropy available, because not blocking was considered more important. Previously we were relying on the security of SHA-1. With AES CTR-DRBG, you rely on the security with AES. With this patch, we're relying on the security of Chacha20. Given that this is being used in TLS for more and more mobile connections, I'm comfortable with that choice. For someone who doesn't trust the security of our underlying algorithms, and want to trust solely in the correctness of our entropy estimation algorithms, they can always use /dev/random. So to be clear about what we're doing, ChaCha20 uses as its internal state 16 bytes of constant, followed by 32 bytes of key, followed by 16 bytes of counter. It is a stream cipher where each successive block in the keystream is generated by bumping the counter, and encryption is done by XOR'ing the keystream with the plaintext. If you ignore the backtracking protection introduced in patch 7/7 in this series (which uses unreleased portions of the previous keystream to mutate the key for future CRNG outputs), what we're doing is using the keystream as the output for the CRNG/CSRNG, and morally, this is no different from a CTR-DRBG as defined in SP 800-90A. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html