# [whatwg] Cryptographically strong random numbers

Roger Hågensen rescator at emsai.net
Sat Feb 5 18:08:32 PST 2011

```On 2011-02-05 17:37, Boris Zbarsky wrote:
> 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.
>

(see further down)

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

(see even further down)

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

(here we go)

If you really wanted a float, and really wanted minimal issue with float
behavior then creating a random um... mantissa.?... "should" allow a
better 0.0 to 1.0 than the divide shown further up.
I have never tested that though.

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

I suspect that they may not want secure random numbers as much as they
might want secure random data for key generation.
So a uint8 array of say 128bytes would be the same as a 1024bit key.

I can see for example a key being generated like this in a app to
generate a key for a server to use.
I seem to recall that StartSSL.com (I think I've mentioned them before
here?) uses a server side key generation for the private key to be used
with certificates.
With something like Uint8Array getRandomUint8Array(in long length); the
key could be generated client side,
which would mean less server load and faster generation of the key as well.

That's one possible use case I can think of off the top of my head.
The other would be binary passwords or passphrases, but I can't recall
anyone using them (or wanting to use them, besides me)... so... *shrug*...
A key for file/data encryption on the other hand would probably be the
most popular use initially, but I'm just guessing here.

Couldn't the Uint8Array mostly piggyback on whatever certificate code
the browser has? Which is either done by the browser or by a OS API.
In fact leaving the sourcing of the data not specified (besides that it
need to be cryptographically secure/random) because it would be
implementation agnostic and hence future proof.

So a few possible use cases here, but does anyone have any other use
cases than the following?:

*Clientside keygeneration for certificate creation instead of server side.
Can't think of anything negative here, rather I'm surprised this hasn't
been possible previously.
Maybe this could get rid of those damn Java apps that all Banks insist

Would be hell to remember, so this would be password manager controlled.
The other issue is how many sites would accept full binary bytes as

* Key for file/data encryption.
Client side is kinda silly here, but server side or "export" of data
might benefit from this.
But wouldn't exposing more of the SSL stuff also make sense?

--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

```