4

I was searching for a random seed to use with a pseudo-random number generator (not trying to encrypt anything). I went to the following web sites:

https://www.fourmilab.ch/hotbits/secure_generate.html

https://www.random.org/

It appears that Random.org has a solid history and is not experiencing problems with DDoS attacks because they do not require an API key. I obviously would not want to use anything from either of these sites as an encryption key, but does anyone know whether the results from using Random.org are any more or less truly random than what I could get from HotBits with my own API key?

I am mostly trying to make sure that my API key itself is not being used in the generation process. Other than that, I have no major ideas why I would avoid HotBits, outside of the inconvenience of ordering my own API key.

brethvoice
  • 185
  • 7
  • 2
    what happened to /dev/urandom ? – kelalaka Jun 01 '22 at 20:06
  • 2
    Computers have had built in RNGs for years now. /dev/urandom on Linux, getrandom() on Linux or BSDs, CryptGenRandom on Windows, etc. – SAI Peregrinus Jun 01 '22 at 23:25
  • 1
    A problem with online generators is that it is hard to prove that they are functioning correctly at the time they are accessed. That's much easier with a locally accessible generator. Furthermore, you generally need random numbers in e.g. the TLS protocol just to retrieve the values securely. – Maarten Bodewes Jun 07 '22 at 17:59

3 Answers3

3

So, while the services you have mentioned are both providing relatively "discreet" randomness, while being publicly accessible, i.e. they don't display on a list all the random values that they have previously generated, I want to also point your attention to the existence of a so-called "public, verifiable randomness".

I am not sure what is your use-case, so please consider this with a grain of salt since it might not fit your needs at all.

What is public randomness?

What we call "public" randomness, is simply randomness that is meant to be public once "released". This kind of randomness is typically useful to say "look, I got nothing up my sleeves, I didn't cheat when choosing the random value".

The range of usecases for such randomness are broader than one might think initially, but it is important to keep in mind that public randomness is meant to be accessible by anybody, so please do not use such randomness to seed any PRNG that is producing secret keys, nonces, TLS stuff, or anything sensitive like that.

What is verifiable randomness?

Verifiable randomness generated in a way that can be somehow "proven" to be safe. This typically includes:

  • proof that it wasn't biased
  • proof that it wasn't tampered with
  • proof that it is properly "pseudo-random"

In general, verifiable randomness must carry some kind of proof that it was properly generated, for a certain definition of "properly".

What for?

So public, verifiable randomness is typically useful when you need to:

  • run a lottery, without having the risk of being accused of cheating
  • do an election or a sortition at random (think of Jury election, leader election for a consensus algorithm, etc)
  • any case where you plan on revealing the randomness after having drawn it, and need to prove you didn't cheat.

Furthermore such randomness is typically found in smart contracts and public ledgers, since it allows to increase the trust in the random value that it was properly generated in a pseudo-random way. However care must always be taken for such system not to use the public randomness in any way that could enable "front-running" by the miners or by bots: as soon as the random data is public, anybody can see "the winning lottery ticket", so to say, and so could submit a winning transaction if this is still possible at the time of production of the randomness. This is something to keep in mind, you typically want to "block" participation a few blocks before the actual public randomness is generated.

Services providing such verifiable public randomness

There are, as far as I know, mostly 2 public services available. (I'm not counting the many VFDs schemes that are flourishing lately)

So in case you need "public", "verifiable" randomness, these are two options :)

But if you need to generate any kind of secret data using your PRNG, be careful:
DO NOT USE PUBLIC RANDOMNESS TO SEED IT.

For most usecases, as Gilles explained in his answer, relying on your operating system PRNG is sufficient and more secure than seeding your own PRNG with random data. Also, be aware that the PRNG you are using, even if seeded with properly random data might still not be good enough for cryptographic use! E.g. it's fairly easy to reverse Java Random PRNG because it's a plain LCG: https://crypto.stackexchange.com/a/51690/29574

Lery
  • 7,679
  • 1
  • 26
  • 46
  • Err, sorry. How do you know (your life might depend on it as a journalist) that they're truly random? – Paul Uszak Jun 10 '22 at 07:43
  • @PaulUszak In the drand case: if the beacon signature is valid, then by relying on the security of BLS, we know that the signature is indistinguishable from a random element. The final randomness is the hash of the signature in order to eliminate any algebraic structure, since it's a random element in the group of possible signatures, it's not yet mapped to a random bit string until being hashed. In the NIST case, they are also hashing the signature (and way more stuff) to produce their randOut value. Check their section 8, it's covering security and possible attack scenarios pretty nicely – Lery Jun 10 '22 at 09:54
  • Do you know that I have a TARDIS? It really does work, and I travel throughout time and space fighting the Daleks. And no, you can't see it. But, the proof is that the design blueprints have been signed by a key owned by the NSA. So it's beyond dispute that it exists, works and is entirely non deterministic. Stupid allegory of course, but do you see where I'm going with this? Non sibi obstetur. The lesson is: you either make your own or don't bother. – Paul Uszak Jun 10 '22 at 13:29
  • 2
    @PaulUszak Yeah, I don't like the NIST beacons too much neither, but the League of Entropy design seems good, especially their use of threshold BLS that is diluting trust into a threshold of parties instead of any single party. – Lery Jun 10 '22 at 13:38
2

For most uses, a random number needs to be secret. It needs to be something that nobody else knows. It is, by construction, impossible to obtain a random number from some website: the website also knows it.

Every modern computer has a random generator. Even more and more embedded devices have one. Just use that. It's available through your operating system, you don't need to do anything special. Just call getrandom() on Linux, BCryptGenRandom on Windows, /dev/*random on Unix-like operating systems, …

For some uses, a random number can be public, but what's important is that it's demonstrably not chosen by you. For example, lotto winning numbers. You can use a random generation service as a trusted third party to obtain random numbers that are not chosen by you, but then the problem is that you can't demonstrate that the random numbers weren't chosen by you. Even if you could prove that the random numbers were obtained by the service, you might have tried multiple times until you obtain numbers that are favorable to you.

If you need a demonstrably random number, see A source of randomness that anyone can independently, conveniently and robustly access?. That number will be public. If you need a random number that's both demonstrably random, and only known to a restricted set of people, then use a public demonstrably random number and a secret random number generated by you and shared to the restricted set before the demonstrably random number is available as inputs to a key derivation function.

Gilles 'SO- stop being evil'
  • 19,134
  • 4
  • 50
  • 92
  • @PaulUszak They don't provide “pseudo seeds”. A pseudo seed would be deterministically generated from some other seed. They provide the conditioned output of an unpredictable physical phenomenon. An actual TRNG would be an unconditioned output of an unpredictable physical phenomenon and therefore too biased to be directly useful. – Gilles 'SO- stop being evil' Jun 02 '22 at 19:39
  • Err, are you confusing a TRNG with it's upstream entropy source? TRNGs are pretty much unbiased by definition. And aren't your 3 examples exactly pseudo seeds as they are generated by pseudo random number generators like (ChaCha + state)? – Paul Uszak Jun 03 '22 at 11:49
  • 2
    @PaulUszak That's the usual definition of TRNG: the physical source before conditioning. Of course the word is often used metonymically to mean a physical object that contains both a TRNG and a conditioning circuit. Whatever you wish to call it, there are two concepts here: the entropy source, which has outcomes that are unpredictable but does not produce uniformly random bits, and the whole package of entropy source plus conditioning, which produces uniformly random bits. The output of the whole package is not _pseudo_random: it is not derived deterministically. – Gilles 'SO- stop being evil' Jun 03 '22 at 12:38
-2

I'm assuming that you're interested in those truly random seeds generated physically as part of a classic TRNG ($H_{in} > H_{out}$), and my answer is tailored accordingly.

I would avoid random.org by virtue of them not publishing exactly how the numbers are generated. "Atmospheric noise" is not a randomness generation and extraction technique in itself. Secrecy $\ne$ randomness. For all we know, they might use some linear congruential generators and lie about it. "We" wouldn't know unless we knew the algorithm(s). Although I have to accept that their numbers do seem statistically indistinguishable from random.

I'd also pretty much rule out the inbuilt CSPRNGs in modern computer kernels, which is what the other answer is alluding to. Since the venerable /dev/random was sabotaged out of existence (not broken), all you have remaining are pseudo random generators and not classic Kolmogorov TRNGs. Do not be fooled by representations that current inbuilt CSPRNGs are the same as ye olde /dev/random. That could create a kosher one time pad. It's replacement and Windows' alternatives cannot. Cui bono? Not the people.

So that leaves two new comers. There's the Ozzie ANU QRNG using vacuum zero point energy, and of course mine at reallyreallyrandom.com using (currently) a web camera.

Since you question the randomness of these sources, you have realised that there are varying levels of randomness in TRNGs depending on their final output entropy bias, $\epsilon$. NIST recommends $\epsilon < 2^{-64}$. I don't have bias figures for the others' RNGs above, but reallyreallyrandom.com's output bias is estimated to be a ridiculous $\approx 2^{-10,000}$. That's simply due to the input output numbers across the randomness extractor in accordance with the left over hash lemma. I just waste a lot of the entropy.

We don’t know whether contemporary pseudo random functions like SHA-2 can output blocks with so little bias as it’s impossible to generate the requisite massive data sample for analysis. My question on this matter remains open unfortunately.

Paul Uszak
  • 15,390
  • 2
  • 28
  • 77
  • If they used an LCG then we'd know. – forest Jun 07 '22 at 02:07
  • 2
    Also, I have to -1 for "Since the venerable /dev/random was sabotaged out of existence". That is a baseless claim. I have a very good understanding of everything in drivers/char/random.c (at least the 4.x era), and absolutely nothing in there points to sabotage. – forest Jun 07 '22 at 02:08
  • 1
    @forest being a noob I am leaving this link for those unfamiliar with the acronym LCG: https://en.wikipedia.org/wiki/Linear_congruential_generator – brethvoice Jun 08 '22 at 14:41
  • So what is/was /dev/random and where can I learn more about what it is/was? – brethvoice Jun 08 '22 at 14:42
  • 1
    @brethvoice It's an interface on Linux and other Unix-type systems that generates random data. Paul has a history on this site of claiming that anything that doesn't generate randomness from quantum non-determinism or his homemade random generator is sabotaged. I'm guessing that Paul is unhappy that /dev/random now uses a stream cipher to generate randomness, which he considers to be backdoored or otherwise broken and thus "sabotaged out of existence". – forest Jun 08 '22 at 21:24
  • 2
    Both /dev/urandom and /dev/random are providing good quality randomness and this should be even more true soon, with the ongoing cleanup and improvement work by Jason Donenfeld on the kernel randomness. – Lery Jun 09 '22 at 19:19
  • @PaulUszak Don't spread misinformation please. – forest Jun 09 '22 at 23:45
  • 2
    Also, the latest change to the random driver is removing all the NIST algorithms (SHA-1 being replaced with BLAKE2, etc.). Isn't that something you'd be excited for? – forest Jun 13 '22 at 00:58