Comment by gruez
6 years ago
which doesn't make sense.
I randomly generated an 8 character alphabetical (all lower case) password "jraxxhwr". According to keepass it has 32 bits of entropy, but the entropy should be 26^8 = 37.6 bits because the search space is all 8 character letter permutations. There's no way you can reduce the search space from 37.6 bits to 32 bits unless you have an oracle that says which characters I used.
It does make sense, because the keepass entropy estimate presumably (like the excellent zxcvbn) tries to approximate the empirical distribution, not the theoretical uniform one.
In theory, "68703649" and "12345678" are equally likely to be pulled from the hat, but in practice one is a much better password than the other. You can reduce the search space by trying the passwords with higher (empirical) probability first.
> the keepass entropy estimate presumably […] tries
KeePass sources are available [0], you can see the specific algorithms it uses in [1].
[0]: https://sourceforge.net/projects/keepass/files/KeePass%202.x...
[1]: https://fossies.org/windows/misc/KeePass-2.42.1-Source.zip/K...
Thanks. I've looked at the code, and it does not seem to try to estimate the empirical distribution (doesn't appear to be using dictionaries, for examples).
Then the discrepancy maybe comes from the number of glyphs within certain categories, or their repetition?