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 <https://github.com/torvalds/linux/blob/master/drivers/char/random.c>, /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. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan
signature.asc
Description: OpenPGP digital signature
