It's also known that user's input is probably not uniformly distributed, meaning the user picking "AAAAAAAA" (as eight letters) it more likely than a uniform random generator picking that (where it would be worth almost 46 bits). In contrast when the user enters "123" the estimate would be 3^3 (not quite 5 bits), because we cannot know whether the user just picked from the set (1,2,3), or from the set of digits. So obviously the guessed entropy is always less than the true entropy maybe my guessed entropy is even very pessimistic.Įxample: When the password generator generates a three-digit sequence like "123", the entropy would be estimated as 10^3 states (almost 10 bits), silently claiming that "000" is just as likely as "738" (for example). The algorithm to estimate the entropy in my program calculated the different characters found (estimating m) and used the length for n. It seems KeePassXC uses the second algorithm even when it's not user input and the entropy is actually known. Having written my own password generator a long time ago, I was using two different algorithms: One to calculate known entropy (like for the case mentioned before), and another to calculate guessed entropy (which would be used when estimating user input).I think that is not correct, because randomly picking n characters from a set of m should always be entropy m^n.When setting up the password generator to pick n characters from m fixed sets the entropy varies between the different passwords suggested.Well, I wanted to file an issue for the password generator's entropy estimate, but I think I can piggyback here: ![]() I was also able to reproduce this with the latest official AppImage (same revision) on a new Fedora 36 virtual machine. Operating system: Fedora Linux 36 (Workstation Edition) ![]() I'm using the package from the Fedora 36 repositories. The displayed entropy value is often much greater than the maximum possible entropy. I know that the displayed entropy is supposed to be an estimate of guessibility rather than the Shannon entropy, but currently it's giving users the impression that a six character password could be secure. The displayed entropy value should never be greater than eight times the number of characters, since each character has at most eight bits of entropy. Generate some passwords and compare the displayed entropy value to eight times the number of characters.This is an extreme example, but if I repeatedly generate passwords like this, I get entropy values greater than 48 most of the time. For example, it displays an entropy value of 79.73 bits for ÍéÐ¥õÂ, even though a six-character extended ASCII password has a maximum possible entropy of an entropy of at most 6 * 8 = 48 bits. The password generator often displays entropy values much bigger than the theoretical maximum when the extended ASCII option is enabled.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |