On 01/09/17 22:33, Zenaan Harkness wrote: > On Fri, Sep 01, 2017 at 09:38:14PM -0500, Mario Castelán Castro wrote: >> No. Entropy is the appropriate word. Please recall that “entropy” is >> just a different scale > > Use of the word "scale" is one example of things that lead people to > use loose terms like "stretching of entropy", which, though useful in > certain contexts, not only readily give rise to imprecise > comprehension in the mind of someone who has no robust definition of > the term, but is mathematically bogus on the face of it, unless one > gets really really precise in each and every definition of every term > in ones "turtles on turtles" stack of term. When I mean entropy, I say “entropy”. I mean what I say. It is not my guilt that other people misuse this word. The entropy of the random distributions in the relevant cases here are perfectly defined. From the fact that *YOU* do not understand the definition does not follow that it is “mathematically bogus”. > Now let's go to that first links second sentence: > "The measure of information entropy [...]" > > I am not mathematically literate enough to even properly parse that > sentence! Here (and through the rest of your message) you are admitting that you do not understand the meaning of entropy in probability theory. Yet you are making statements about entropy. This is intellectually dishonest, to say the least. >> 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. > > Interesting - I thought ChaCha was being used because it was such a > good (non-skewing, suitably crypto-random mixing, reasonably > performant) algorithm. Indeed, when properly used, ChaCha20 is good as far as I can tell. Roughly speaking, we are computing hash(X) to derive the 128 bits read by my one-liner. Even though we assume that “X” is uniformly distributed among a 384 bit space, we assume that “hash” will give a random result for each input, independent of the value it gives for the rest of the inputs. Thus with near certainty, some values will be more probable than other values, but (by “the law of the large numbers”) only by a tiny difference from what an uniform/unbiased distribution would require. This is a phenomenon applicable to hash-like functions in general. It is not a flaw of ChaCha20. > Even theoretical attacks will undoubtedly focus on this skewing, if > indeed ChaCha20, or the implementation of it in the kernel, is > actually skewing. This is an unjustified statement. >> 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. > > I assume the opposite - almost always, such constants will and do > effect security of the algorithm, AIUI. This is yet another unjustified assumption. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan
Attachment:
signature.asc
Description: OpenPGP digital signature