Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1421210

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH-v4 0/7] random: replace urandom pool with a CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-13 17:50 +0200
  [PATCH 7/7] random: add backtracking protection to the CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-13 17:50 +0200
  [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-13 18:00 +0200
    Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG Stephan Mueller <smueller@chronox.de> - 2016-06-13 20:10 +0200
      Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-13 21:10 +0200
    Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Herbert Xu <herbert@gondor.apana.org.au> - 2016-06-15 17:00 +0200
      Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-20 01:20 +0200
        Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Herbert Xu <herbert@gondor.apana.org.au> - 2016-06-20 03:30 +0200
          Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-20 07:10 +0200
            Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Herbert Xu <herbert@gondor.apana.org.au> - 2016-06-20 08:10 +0200
              Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-20 17:10 +0200
                Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG Stephan Mueller <smueller@chronox.de> - 2016-06-20 18:50 +0200
                Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG "H. Peter Anvin" <hpa@zytor.com> - 2016-06-20 22:40 +0200
                Re: [PATCH 5/7] random: replace non-blocking pool with a  Chacha20-based CRNG Theodore Ts'o <tytso@mit.edu> - 2016-06-21 01:50 +0200
  [PATCH 1/7] random: initialize the non-blocking pool via add_hwgenerator_randomness() Theodore Ts'o <tytso@mit.edu> - 2016-06-13 18:00 +0200
  [PATCH 2/7] random: print a warning for the first ten uninitialized random users Theodore Ts'o <tytso@mit.edu> - 2016-06-13 18:00 +0200
  [PATCH 6/7] random: make /dev/urandom scalable for silly userspace programs Theodore Ts'o <tytso@mit.edu> - 2016-06-13 18:00 +0200
  [PATCH 3/7] random: add interrupt callback to VMBus IRQ handler Theodore Ts'o <tytso@mit.edu> - 2016-06-13 18:00 +0200
  [PATCH 4/7] random: properly align get_random_int_hash Theodore Ts'o <tytso@mit.edu> - 2016-06-13 18:00 +0200

csiph-web