[whatwg] Cryptographically strong random numbers

[Roger Hågensen]

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 
on using to log in securely?

* Binary password/passphrase.
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 
passwords/phrases?

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