Cryptography
hash random-number-generator
Updated Fri, 20 May 2022 20:19:19 GMT

Could there be a floating point CSPRNG?


I recently answered no to Is there a floating point CSPRNG? Unpredictable rounding errors, especially across dissimilar hardware were my reasoning.

In it's most basic form, a CSPRNG can be constructed by securely hashing a randomly initiated counter. This is what happens inside the secure random function for Java. So if we can find a hash that operates with floating point numbers, we'd have a floating point CSPRNG as originally asked for.

The following abbreviated abstract is from this paper:-

This paper shows how one of these systems can hash messages at extremely high speedmuch more quickly than previous systems at the same security levelusing IEEE floating-point arithmetic.

My problem is that I can't understand the working. It's all Greek to me, but I can spot multipliers of 0.98 , 2.2 and 1.01 which are clearly floating point numbers.

Was I wrong, and floating point CSPRNGs are actually possible if not common?

Clarification: Some comments are appearing that are only relevant to a non deterministic RNG or generating floating point output. The original question asked for a native floating point deterministic generator. So internally it should only work with floating point numbers, as does (I think) my linked paper. It's clarification of this last fact regarding the linked paper that I'm looking for as that would pave the way for a native floating point CSPRNG.

Addendum

I've now come across Uni64() which is a random number generator that uses double precision variables. It's by George Marsaglia. This is an extract of the initialisation:-

const double r=9007199254740881.0/9007199254740992.;
const double d=362436069876.0/9007199254740992.0;
static double c=0.; static int i=97,j=33; double x;

Without doubt, r,d and c are double precision variables. So for example, r = 999.999999999987676524e-3 and d = 40.2384869730987304592e-6. To be honest, I don't know what this means. Is r meant to be 1 an I've rounded, or it this correct? Not sure what d could be rounded to.

"the uni64() doubles have been multiplied by 2^53"

Is this the secret? Rounding /accumulation errors do occur as expected. But by shifting left 53 times, they effectively become part of the randomness in the lower significance bits. What seems like random errors in precision become part of the randomness. And if so, this would appear to be a floating point random number generator...

Solution

I think this is a question where the ambiguity of common terms like "CSPRNG" gets in the way. The problem is that when talking about "CSPRNGs" in different contexts, people variously refer to either:

  1. Deterministic algorithms that must produce the same results when given the same inputs. Example: stream ciphers, where Alice and Bob must produce the same keystream if they are to communicate successfully.
  2. Nondeterministic algorithms where there is no such requirement, and ideally could be replaced by a true random generator. Example: operating system random generators, where the practical solution has been to compose a deterministic pseudorandom generator with a physical noise source, to yield output that is both nondeterministic and pseudorandom.

Unpredictable rounding errors are a problem for #1, but perhaps not so for #2. And if the latter is so, then floating point numbers are just bit-strings and floating point operations are just bit-string operations; the question about building a counter-mode "CSPRNG" is then whether there are there ways of composing these operations into a scrambling function that yields something resistant to cryptanalysts' best efforts.





Comments (1)

  • +0 – Yes sorry. I didn't mean a non deterministic type. I'm talking about the classic case of a totally deterministic RNG. I infer from the paper that their hashes must also be deterministic, otherwise they're useless for purposes of message authentication systems which is the theme of the paper. — Jun 29, 2017 at 22:36  

External Links

External links referenced by this document:

References