Re: [patches] strfry() doesn't use a level random distribution

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Sat, 9 May 2009, Kirk Strauser wrote:

> The solution is to set a threshold value that is the largest multiple of
> len-1 that is smaller than the highest value that __random_r can return:
> 2^31-1.  Then, call __random_r until it returns a value less than that
> threshold.
> 
> Side note 1: I don't know how to properly handle the case where strlen(string)
> >= 2^31 - 1, or even if that's possible.

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).

> Side note 2: I don't have an FSF assignment on file.  If you want to use this
> patch, let me know what I need to do and I'll take care of it.

This one is small enough not to need it, but with fixes for large strings 
it might need it.

http://gcc.gnu.org/wiki/CopyrightAssignment

(naming GLIBC as the package, not EGLIBC)

> 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.

> +        int32_t randmax = 2^31 - 1;

2^31 - 1 in C evaluates to 28.  You mean RAND_MAX.

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.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx