Uniformly distributed secure floating point numbers in [0,1) Is there any way to generate 


cryptographically secure 
uniformly distributed


floating point numbers in the interval [0,1)?

For example, in Javascript, there is Math.random(), which yields these (pseudo-random) numbers, yet not cryptographically secure. 


There are several algorithms at https://stackoverflow.com/questions/686353/c-random-float-number-generation, yet at https://stackoverflow.com/questions/34575635/cryptographically-secure-float, the problem of denormal numbers was pointed out. 
Inversion sampling as of Wikipedia requires a uniformly distributed [0,1) number to start, so this is seemingly not trivial to apply.


What is a good approach?
For most purposes, the following trivial method should be adequate:


Generate a random  $n$-bit integer (i.e. a uniformly distributed random integer between $0$ and $2^n-1$ inclusive).
Cast the random integer into a float and multiply it by $2^{-n}$ to scale it to the interval $[0,1)$.


There's some leeway in choosing the number of bits $n$, but a generally reasonable choice is the significand precision $n_p$ of your floating-point format (e.g. 53 bits for IEEE 754 double-precision floats).  In particular, this is the highest number of bits for which the distribution of the resulting floats will actually have the full $n$ bits of entropy &mdash; or, in other words, the highest number of bits for which step 2 above is fully reversible.  If $n &gt; n_p$, the conversion to float will map some pairs of integers to the same floats, resulting in an output distribution with less than $n$ (but still more than $n_p$) bits of entropy.

Regardless of the value of $n$ chosen, the distribution of the floats generated using this method will be "approximately uniform", in the sense that, for any $0 \le a &lt; b &lt; 1$, the probability of the output falling in the subinterval $[a,b)$ will differ from $b - a$ by at most $\max(2^{-n}, 2^{-n_p})$.  For $n \le n_p$, it will also be uniform in the sense that each float value that can be generated by this method is generated with the same probability ($2^{-n}$).

However, the floats generated using this method will not be uniform in the sense that each possible float within $[0,1)$ would be equally likely to be generated.  In fact, this holds for any random float generation method that is approximately uniform in the sense described above, simply because the density of representable floating point values is itself not uniform &mdash; there are far more floats in the interval $[0,\frac12)$ than in $[\frac12, 1)$.  Thus, it's fundamentally impossible to generate random floats that would be uniformly distributed in both of these senses.

In any case, it's important to realize that a random float in $[0,1)$ is not the same thing as a uniformly distributed random real number in $[0,1)$: the latter distribution has infinite entropy, whereas the entropy of any actual distribution of floats representable on a computer is inevitably finite.  While it's sometimes (I would even say most of the time, at least outside crypto) fine to substitute one for the other, it's important to keep the difference in mind when analyzing the security of algorithms that, conceptually, assume access to uniformly distributed real numbers.