On 2/5/11 1:55 AM, Roger Hågensen wrote:
On 2011-02-05 04:39, Boris Zbarsky wrote:
In general, I suspect creating a good definition for the float version
of this API may be hard.
Not really, usually it is a number from 0.0 to 1.0, which would map to
say the same as 0 to whatever max 64bit is.
Those aren't the same thing, though.
Depending on the implementation, the simplest is just to do (pseudocode)
float=Random(0,$FFFFFFFFFFFFFFFF)/$FFFFFFFFFFFFFFFF
That gives you non-uniform distribution, no? In particular, the
conversion to float will lead to rounding, and different rounding in
different parts of the range. So for example if the result of Random()
is 2^{50} you will get the same float as you would for everything up
through 2^{50} + 2^{25} or so (assuming single-precision floats),
whereas around 0 the range of values that actually ends up 0 is only
about 2^18 because you can end up with subnormals, right?
And yes, float issues of rounding and "almost correct but not quite"
will also be an issue here.
Indeed; I'm not sure how you can say creating a good definition is "not
really hard" while leaving this problem unsolved in the "not really
hard" case... ;)
Float random does not make much sense in crypto.
Indeed.
The question is, do people want cryptographically secure random numbers
for crypto, or something else? As you say, we need to understand the
use cases.
-Boris
