[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: One-line password generator

On 01/09/17 18:43, Zenaan Harkness wrote:
> (Probably obvious, but as long as you're reading from urandom,
> "entropy" is the wrong word, in this context, better to say "128 bits
> of crytographically secure numbers" as that which has been said e.g.
> by the Linux kernel urandom developers as being "crypographically
> secure" has changed a few times, and may change again in the future -
> it it truly were entropy (as /dev/random suggests it provides), the
> ongoing changes for "security" would not be necessary.)

No. Entropy is the appropriate word. Please recall that “entropy” is
just a different scale for probability and quantities comparable to
probability (like expected probability). Nothing more, nothing less.

Also note that all the theoretical (and very unrealistic) attacks on
/dev/urandom apply only when the attacker knows part of the *past*
output of /dev/urandom, and he uses this to predict the *current* and
*future* output of /dev/urandom. This is not applicable in our scenario.

In short: Given that the state of the CSPRNG is larger than the amount
of bits read[1], the bits can be assumed to be distributed at random.

Longer answer:

According to my reading of
/dev/urandom uses a variation of ChaCha20 which is periodically
re-seeded from the “entropy pool”.

In a reasonable scenario for password generation, the attacker does not
know the state of the 512-bit CRNG state, and so the best he can do in
practice is to model it with uniform probability distribution.

According to my understanding, the output of /dev/urandom when reading
with my command will be truncate(ChaCha20(X)) where (X) is the aforesaid
512-bit state and “truncate” is the function that returns the first 128
bits of its input. The processing with ChaCha20 and truncation skew the
distribution a bit, but this is negligible.

As a side note, I noticed that Linux uses weird constants in the
ChaCha20 input for the aforesaid CSPRNG: the ASCII text “expand 32-byte
k”. This looks like a bad choice, but I doubt that it has any security
impact in practice. Anyway, they should have used the constants
recommended by D, J. Bernstein (the designer of ChaCha20).

[1]: 384 bits according to my understanding, since 128 of the 512 bits
feed to ChaCha seem to be fixed to the ASCII “expand 32-byte k”.

Do not eat animals; respect them as you respect people.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: