Re: One-line password generator
Hi,
Mario Castelán Castro wrote:
> My point is that there is no way to make a
> reasonable approximation to the Kolmogorov complexity of a password.
That's my point, too. Although i use the terms "information" and "entropy".
> To recap: Real-life file compressors can not be used to estimate the
> strength of passwords because they do not understand *meaning* as humans
> perceive it.
To be exacting: The words "Real-life" and "file" are your contribution,
not mine.
Each enumeration algorithm establishes a compression algorithm. Whether
it is effective is another question. Interesting are those which enumerate
the given passwords early. The bit count of the found enumeration number
is an upper limit of the password's entropy in the context of the algorithm.
> *What* article? Nobody has mentioned a scientific article in this thread.
It's not very scientific. More real life:
https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
Curt brought it up in
https://lists.debian.org/debian-user/2017/08/msg01437.html
Thanks for this.
Especially funny is the cartoon on page 3.
If you can memorize a password, then it's weak.
> I already explained why my method is not a 25% reduction in entropy,
If you run your hopefully random data through base64 and tell this to me,
then i can get rid of the base64 redundancy and thus reduce each group of
4 bytes to 3 bytes.
To be clear, your password generator looks very safe. Even with urandom.
But the passwords are not compatible to human memory, which is no wonder.
> Also, the theoretical vulnerability described in that man page is far
> fetched.
It is a mathematical fact. If you take a few theoretically unpredictable
bits and inflate them to 128 bits, then the added size is no entropy,
although it might be hard to distinguish this redundancy from the initial
information.
You bet that the cryptographic algorithm used pushes your bits into a region
in the 128 bit space which above enumerators visit late.
> Moreover, such a theoretical attack applies only when the attacker
> *already knows* some of the output of your /dev/urandom
This statement would have to be proven.
In general, what the attacker does not know is the exact value of the
theoretically unpredictable random number that was input to the urandom
inflation mapping. That's what i count as entropy of the inflated value.
Then we have the cryptographic algorithm. If it has a theoretically unknown
key, add its entropy to the input entropy.
The rest of the 128 bit is redundancy.
The only remaining defense is to make the cryptographic algorithm darn
complicated. But that's linear and thus has no chance against Moore's Law
if it does not fall victim to an agile mind.
> In Linux (the kernel) the same algorithm used for /dev/urandom is used
> to mix /dev/random.
But /dev/random hopefully uses 128 bits of collected entropy as input
for that algorithm.
> “/drivers/char/random.c”
* When random bytes are desired, they are obtained by taking the SHA
* hash of the contents of the "entropy pool". The SHA hash avoids
* exposing the internal state of the entropy pool.
So i assume that it is not used to inflate /dev/random
> if you are interested in possible
> vulnerabilities of the random virtual devices.
Others have more talent than me.
Have a nice day :)
Thomas
Reply to: