On 12/7/20 10:52 PM, Rob Landley wrote: > Hmmm, this is producing a LOT more capital letters than the other version, > which > also falls under "human readable affordance". let's see... Top bit of entropy > per byte isn't really used, so I'll squelch capitals when it's set. (That > should > make 1/4 of letters capital.) ... > That's still a very different character distribution. He's squelching more > capitals than I am, and at least half the punctuation...
Forgot to mention I used the same high bit squelch trick to suppress half the punctuation. The result still has more punctuation on average yet isn't guaranteed to have punctuation in EACH generated password, but... > Which is... eh? Close enough? Checked in the cleanup, and promoted it to toys/other. I note that -s isn't hooked up to anything. Maybe I should make it disable the two squelches? Yeah, I'll do that... And yes, I should rename janice[]. When I'm tired all the names I choose for things tend to be pop culture references, I.E. my first answer to the question raised by its name, ala what should I call the ps -o fields? "struct strawberry". In this case the question was "which rand" since "int rand;" was already the index into the buffer of random numbers returned by xgetrandom() when I yanked toybuf out from under it to construct the password into, so I needed a new buffer to hold random data and the obvious answer was the star trek character. (Could have gone with the old NSA front corporation but... no.) The question I SHOULD be answering for these names is "what will be easiest for other people to understand", and I usually go back and replace them later. And yes sizeof(janice) was an issue because more system calls is bad (it's slow and I'm never 100% sure there isn't some ptrace exploit for some subtle side channel attack or data exfiltration or something), but draining the entropy buffer more than necessary is bad. So I compromised at twice the default password size, not _entirely_ arbitrarily because I vaguely remembered something about the internal kernel hash plumbing that implements /dev/urandom working in block sizes bigger than 64 bits (8 bytes), so the kernel's doing the work to prepare at least much buffer each time even when it mixes those bits back in because it didn't send them to userspace. (I'm using urandom which doesn't do the "we're out of REAL entropy, block until more comes in" accounting, but it's still not a good idea to waste it. I _could_ look up what the current hash granularity is for whatever they've redone the plumbing to this year, but it would only change again and being asked for one 8 character password is just enough of a common case (pwgen -1) that fetching twice that much seemed the most I could excuse anyway. Hand wave, hand wave, jazzhands.) Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net