> OK, this is a reasonable approach. Since /dev/urandom just generates > random bytes, there's a lot of flexibility and we're not subject to > any kind of backwards compatibility constraints, especially not the > 16-bit limit. What do you think would be the best way to present that > to a user? As a 32-bit random number? A character string you can use to > create filenames? Some other form?
Hi Chet, et al, I really like this suggestion. All recent variants of /dev/urandom are using something like ChaCha20, Yarrow or Fortuna, and older implementations will still be reasonably secure - using something like Yarrow, Yarrow-like or arc4. Ole's concerns should be well covered by this approach. Having said that, there appear to be some gotchas, as covered here: * https://stackoverflow.com/questions/2572366/how-to-use-dev-random-or-urandom-in-c * http://insanecoding.blogspot.com/2014/05/a-good-idea-with-bad-usage-devurandom.html So it might be a case of restricting the usability of this change to newer kernels that have dedicated calls like getrandom() or getentropy(), and having to handle detecting/selecting those? So if this is an exercise that you're happy to entertain, and without wanting to feature-creep too much, why not something like this? * $RANDOM = exactly as it is (or with an improved RNG... probably a separate discussion now) * $RANDINT = 32 bit integer from RANDOM's RNG i.e. this is seed-able * $OS_RANDINT = 32 bit random integer from /dev/urandom * $OS_RANDSTR = random character string from /dev/urandom I suggest OS_ because it's less typing than, say, SECURE_ or SYSTEM_, vaguely conveys the source of randomness and it might have some familiarity with other languages. Python's os.urandom comes to mind. SYS_ might be a good alternative, too. Certain characters such as '!' may need to be omitted from OS_RANDSTR's output, possibly that's a worthwhile thing to keep in mind? As an aside, I can confirm the findings of a performance difference between 4.4 and 5.0 when running the script provided earlier in the discussion. At first glance it seems to be due to the switch from the old LCG to the current MINSTD RNG, but I've compiled 5.0 with the old LCG code and on my hardware that performs roughly the same as the MINSTD RNG and Ole's ChaCha20 patch. So I thought it might be something to do with how loops are handled, but testing other tasks shows no great difference there between 4.4 and 5.0. That's as far as I got. Cheers Rawiri