On May 12, 2009, at 3:34 PM, Joseph S. Myers wrote:
The obvious thing would be to make two calls to __random_r to get a 62-bit
random number, or three to get a 64-bit random number if the size of the
string approaches 2^62, once the string size is large enough that this is
beneficial (whenever len - i is at least 2^30 might be an approximation,
with 2^61 as a cut-off for getting a 64-bit number).
Good point. My version and the original version both have the limitation of not swapping any chars past 2^31.
Submitted, and now waiting for the hardcopy form to arrive.
Side note 3: Most importantly, the idea behind this patch is generally true
for all code, especially crypto stuff. A cursory grep of eglibc's source tree
didn't show any similar code involving __random_r but I didn't spend a long
time looking. If random distributions are used elsewhere, they should be
audited to make sure they're not subject to the same bias.
__random_r is not intended to be a crytographically-strong random number
generator and should not be used in any cryptographic context.
What I meant was that the general idea of checking the range of random functions is important, not just ones using __random_r.
Of course, further greps through the source don't really turn up any random calls, so feel free to dismiss this as the nitpicking of a pedant.
+ int32_t randmax = 2^31 - 1;
2^31 - 1 in C evaluates to 28. You mean RAND_MAX.
D'oh. You're right, of course. May I suggest changing comment strings to use ** instead of ^ for clarity? I followed an example and got it wrong.
Maxim, we should have an EGLIBC option group to disable strfry and memfrob
- I can't imagine anyone wishing to cut down EGLIBC's size with option
groups has any use for these functions.