[Slackbuilds-users] apg-2.2.3 automated password generator
peter at peter-dambier.de
Wed Nov 20 15:20:56 UTC 2019
the only case worse than that would be to restrict to lowercase letters
with even parity :)
I tried a few runs. Slackware kernel 4.19.79-smp runs out of random
numbers and then takes drastically longer.
I have built my own kernel with crypto and random in mind and this one
returns without delaying.
I have compared it to a "native" Gentoo apg. They look the same. I am
sure they are.
Dont make your live depend on it but dont trust your smart builtin
random generator either.
On 11/20/2019 03:43 PM, Erich Ritz via SlackBuilds-users wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, November 20, 2019 6:33 AM, Jude DaShiell <jdashiel at panix.com> wrote:
>> One improvement that could be done to all of these password generators
>> is to make sure every password starts with a letter and ends with a
>> letter. That makes passwords more difficult by a little to crack. The
>> reason for that is mathematics. Numbers and special symbols have a set
>> size of 42 32 special symbols and 10 digits. Letters have a set size of
>> 52 all lower-case and upper-case and the underscore. Why the underscore
>> is understood as a letter by some people I don't know I would have
>> thought that would have been a special symbol.
> Your response if completely off-topic, but I feel I have to respond:
> Please don't roll your own crypto.
> Your assertion is wrong.
> Assume a 3-character password and 3 different algorithms:
> 1) Each character is randomly chosen from your numbers/special/letters set (94 total characters)
> 2) 1st and last password character must be letters.
> 3) 1st and last password characters CANNOT be letters (only numbers and special symbols.
> Algorithm (1) has 94^3=830,584 possible passwords. Of those, some will begin and end with letters; some will start with a letter and end with a number/special, some will start with a number/special and end with a letter, and some will both start and end with a number/special.
> Algorithm (2) has 52*94*52=254,176 possible passwords.
> Algorithm (3) has 42*94*42=165,816 possible passwords.
> Your rationale compares algorithms (2) and (3) and concludes algorithm (2) is the best. But, you have completely discounted algorithm (1), which is by far the best algorithm.
> In general, adding any restrictions to the password generation decreases entropy. KeePass (or KeePassXC, can't remember which one) even warns of this when using their built-in password generator.
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
Peter and Karin Dambier
+49(6209)280-3030 (VoIP: GGEW)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
More information about the SlackBuilds-users