On Sat 26 Aug 2017 at 21:14:35 -0500, Mario Castelán Castro wrote: > On 26/08/17 13:25, Brian wrote: > > How does this > > > > echo 'secretpassword' | sha256sum - | base64 | cut -c -30 | head -1 > > > > compare with your recommendation? > > I do not see the point in this post-processing. > > It seems that you have a very wrong impression of what makes a password > generation scheme be a good password generation scheme.
I'd be prepared to accept lacking :). But that's inevitable when dealing with the innards of an unfamiliar topic. I'm getting better, though. > For any probability distribution fixed in advanced, the *expected* (in > the sense used in probability theory) entropy of a password generated > with my scheme is well defined and at least 132 bits (I wanted 128 bits, > but using Base64 the choice is between 132 bits and 126 bits because 132 > is not a multiple of 6). In other words, if you take a probability > distribution and keep if fixed while generating a big amount of > passwords with my scheme, the average entropy under that probability > distribution will be at least (within sampling error) 132 bits. > > This property is achieved *because* there is a source of randomness > (that we can assume, has uniform distribution and thus maximal entropy > per byte) in my generation scheme, not because of Base64. Base64 is > there just to turn the random bytes into a *short* human-readable > string. One could turn the random bytes instead into a list of words (as > long as the mapping is one-to-one) and the same property about expected > entropy would hold, but then the password would be *much* longer. > > Length is the *only* reason to use Base64 here instead of using the > random bytes to choose words at random. > > By contrast, your “scheme” has no systematic source of randomness. It > requires that one has already decided for a “randompassword”, and then > post-process it. If the attacker knows the post-processing, guessing > this password is at least as easy than guessing the input to the > post-processing step (plus computing the hash and encoding, but this is > negligible). Moreover, your post-processing stage loses information, as > another user has already noted. If the attacker knows your > post-processing method, he can speed the search by avoid trying the > passwords that could not be possibly generated with your method because > of this loss of information. > > For example, your method will never generate a string of '0000...' > because the input to Base64 are hex digits in ASCII, which never have > the byte value 0 (0 is unprintable). > > If the attacker does not know the post-processing stage, then maybe he > will eventually begin to guess that your password is an human-generated > password ran through a post-processing stage. Then very possibly your > post-processing adds security (because the attacker has to guess the > post-processing method too), but how much? *It is not well defined*. We > already talked about non-well-defined probabilities, so I will not > repeat that fragment. Thank you for the detailed explanation. I had already come to some of the conclusions in your account but it is good to have them firmly and succinctly laid out. -- Brian.
