![]() If it's not a problem in pwgen I'm surprised to hear that there's a problem in aescrypt_keygen. Two reasons it is not yet posted are that 1) I'm not sure I like this solution, and 2) I'd like to just integrate the code right into aescrypt itself. For that, I just used an additional two characters: I then selected "%" and "$" to create 64 possible values. I have a fix for that in the source repository, but not posted to the web site. Paulej wrote:I also have the same issue with aescrypt_keygen. It generates a big integer (not just values 0.255) and, based on my tests, bias is not visible. The Perl code is not subject to bias due to the random number generator that is used. Basically, it just discards and value that is higher than acceptable to avoid bias. ![]() I had previously updated the pwgen C code to avoid modulo bias. I also have the same issue with aescrypt_keygen. So out of one 16-octet password, there is usually about 1 character that might see bias. In my experiments, this often only happens to a single character in a typical password. That results in wrapping back around to 0.7. It exists, but only if the octet is >= 248 in value. That would be extremely rare, but it's possible. The problem is that there is still the possibility of running out of octets. I considered an approach where I keep reading more random values in the hash that gets generated. I could not find a good solution for that, so I gave up. ![]() This is something I wrestled with for a bit for SinglePass.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |