17
$\begingroup$

Random.org provides true random numbers through an unsecured web service. Since these numbers would be transmitted in plaintext could they still be considered useful as true random numbers while maintaining security in a cryptographic solution?

At first I was thinking if a large pool of them was obtained then a small subset of them could be used randomly to make the fact they are known of less use. Then I realized that no matter how many random numbers were obtained this way, it would still be a smaller number set to explore in attempting to crack the cryptography.

Update: Random.org supports SSL over HTTPS, but are not encouraged for use in cryptography.

$\endgroup$
7
  • 2
    $\begingroup$ You can make a secure connection to random.org. Plus, looking at the source code, their "Generate" button is actually in an iframe that is loaded over a secure connection. $\endgroup$
    – mikeazo
    Jan 10, 2012 at 21:26
  • 2
    $\begingroup$ @mikeazo: So as long as Random.org is not the attacker it would work. $\endgroup$ Jan 10, 2012 at 21:27
  • $\begingroup$ I'd say that as long as you trusted Random.org and made a secure connection to them, then it should be fine. $\endgroup$
    – mikeazo
    Jan 10, 2012 at 21:29
  • $\begingroup$ You could always build your own generator. Pretty cool. $\endgroup$ Mar 20, 2012 at 5:28
  • 4
    $\begingroup$ @mikeazo Uh, don't you need an entropy source to create a secure connection in the first place? That would make it only useful for those runtimes that would have no access to the local source of randomness. $\endgroup$ Mar 21, 2012 at 0:12

8 Answers 8

17
$\begingroup$

The more I think about it, the less I would be willing to use Random.org for any sort of cryptographic application. My reasons are listed below.

  1. See Q2.2, the groups listed are not cryptographic groups and potentially (or probably) don't have cryptographers on their evaluation teams
  2. They specifically say not to use it for cryptography
  3. It is closed source. So, I would have no way of knowing if they properly mutex their RNG so that only one person is drawing from it at a time. There are other implementation issues that I (or someone/some group much smarter than I could check for).
  4. Using this would require an internet connection for all randomness.
  5. Current CS-PRNGs are much faster and options are available which suffer from none of the weaknesses listed above.
  6. The RNG could change at any time without me knowing.

That said, these reasons don't necessarily answer the question. They only give insight as to why I personally wouldn't use Random.org for cryptography. Would it be secure to use Random.org in cryptographic solution? Possibly. There really isn't enough information to really know.

$\endgroup$
2
  • $\begingroup$ I think random.org should be okay to gather additional entropy for a CSPRNG. Getting 8 to 16 bytes (64 to 128 bit entropy) from them additionally with other entropy to use in a CSPRNG like Fortuna should be no problem. It is designed to be as secure as possible even if some of the entropy sources are corrupted, as long as enough of them with enough entropy are still valid and unknown to the attacker. (80 bit should be enough, 128 are fully sufficient in my opinion in 2015.) $\endgroup$
    – Nova
    Feb 16, 2015 at 9:55
  • $\begingroup$ @Nova How would it possibly benefit you though? If your CSPRNG seed has too few bits of entropy to be secure on its own and it needs something from Random.org, then the TLS connection used to fetch the numbers would be possible to break. $\endgroup$
    – forest
    Feb 6, 2019 at 5:44
13
$\begingroup$

It is so easy to create cryptographically-strong random numbers in ways that are known to be strong that adding new methods that add new risks is not advisable. However, if you have an existing method that is known to be secure and has the ability to take in additional sources of randomness in way that cannot do harm even if they are known to an attacker, than go ahead and add them. You have nothing to lose.

$\endgroup$
12
$\begingroup$

In cryptography, randomness is mostly about being unknown to any attacker. Any attacker could observe your download of these random numbers, and now they are not really random since the attacker knows them too.

There is an article from Crypto'97 which describes something which looks like that: it is a secure key exchange system which defeats memory-bounded adversaries. This assume a shared source of randomness which broadcasts random numbers; anybody can listen to it, including any attacker. Two parties who wish to get a shared key record just a few chunks out of the random bits, noting the position of each chunk in the stream (say, the exact emission time). At the end of the day, they send to each other the list of positions; if they recorded enough, there is high probability that there are a few chunks they they both recorded, and they can use these as a shared key. On the other hand, an attacker willing to learn that key would have to record quite a lot of the stream in order to have a fair chance of having all the chunks that the two parties have in common.

This key exchange mechanism is safe as long as the random source broadcasts data at a very high rate, so that recording all of a day's broadcast is not doable. So it should be in gigabytes per second or so.

In a way, using the numbers from random.org is like using this model: you record insecure random numbers, and at the end of the day you assume that you could get some that the attacker failed to record himself. To get a key out of your pool, you could for instance hash the whole of it with a secure hash function such as SHA-256 (don't pick numbers out of the pool; instead, use a hash function, which will not "forget" any entropy). Still, in practice, this fails on several accounts:

  • The Web in general, and your Internet access in particular, is nowhere near fast enough for this. An attacker can easily record terabytes of data, so you should download much more than that. Your ISP will not be pleased (unless your contract includes a quota, and gigabytes beyond the quota are billed, in which case the ISP will be thrilled).

  • random.org itself could be an attacker, and feed you what are claimed to be "true random numbers", but are actually the output of a pseudo-random number generator. You would not be able to see the difference. But this would allow the attacker to rebuild the random numbers you got (all of them) at will.

  • An active attacker could alter the numbers you get, in effect reducing the problem to the previous point.

So, to make the story short: no, random.org is not useful to security or cryptography.

$\endgroup$
9
$\begingroup$

Since you cannot be assured that random.org is not retaining a copy of the number, nor is its transport to you necessarily confidential, you should think of numbers from random.org as public randomness. That is perhaps pessimistic but it will lead you to use such numbers in the correct manner.

Obviously, public randomness is not useful for generating secrets in cryptography.

However there are a number of scenarios where public randomness is perfectly ok. Here are a few:

  1. Generating challenges for random audits
  2. Generating challenges for interactive proofs
  3. Fair exchange
  4. Generating an auxiliary random string for reference
  5. Choosing non-secret "keys" for things like extractors or instances of a hash function from a family of hashes
  6. Choosing initialization vectors or salts

A source of public randomness is sometimes called a "beacon." It is an important enough service that NIST is in the progress of creating one. Their whitepaper explains some of its uses and mentions random.org. Another option is to use financial data, which we showed to have sufficient entropy.

$\endgroup$
1
  • $\begingroup$ OK, but we cannot be assured either that random.org does not repeat its random stream on a reboot etc. That would preclude a lot of the above use cases. Basically, we can only hope that random.org is valid from what is pronounced at the front page. That's simply not enough. $\endgroup$ Mar 2, 2014 at 11:23
6
$\begingroup$

No, it would not be secure… especially not without specific precautions and protocol implementations – which random.org doesn't offer in the first place. Also, random.org is – as far as I know – not certified, which downgrades it from a “trust” point of view.

But when talking about such randomness providers, I always like to mention a more professional project too, because many people aren't aware of its existance: the NIST Randomness Beacon…

NIST Randomness Beacon

If you check the project homepage at https://beacon.nist.gov/home you'll notice that even that project clearly states:

WARNING: DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS.

And there's a good reason for that: they are still researching potential implementation options as well as potential security strengths and weaknesses of such a solution.

I wouldn't count on random.org having solved all the problems the NIST Randomness Beacon is still researching.

As you noticed yourself, random.org states something similar:

We should probably note that while fetching the numbers via secure HTTP would protect them from being observed while in transit, anyone genuinely concerned with security should not trust anyone else (including RANDOM.ORG) to generate their cryptographic keys.

(emphasis mine)

In terms of security, I therefore would personally recommend to distrust data from services like random.org even more than the beacon data generated by the NIST Randomness Beacon project in its current research phase… and until further notice, you aren't supposed to trust the Beacon data either.

Wrapping it up: it would not be secure to use random numbers from services like random.org in a cryptographic solution. This is underlined by the individual services' statements.

There are ample well-vetted and cryptographically secure alternatives to the need of falling back on using such services. It would be smarter to use those than to trust a 3rd party that puts emphasis on the fact that you should not trust its data for crypto purposes…

Sites like random.org may have their place, but not in the realms of cryptography.

$\endgroup$
5
$\begingroup$

It would be secure only

  • If you trust the connection to random.org (and as you said, it is unsecured)
  • If you trust random.org itself (it could e.g. log the generated data along with your IP)

So I'd say it is not secure, in general.

$\endgroup$
2
  • $\begingroup$ So there is no use for them in cryptography? $\endgroup$ Jan 10, 2012 at 21:07
  • 1
    $\begingroup$ One application I can come up with is for validating randomness tests. But for the usual applications (e.g. generating keys), I don't see how random.org could be useful. $\endgroup$
    – Conrado
    Jan 10, 2012 at 21:45
4
$\begingroup$

The short answer is: the online random number generators (or better, online radioactive/quantum sources) have high entropy and are unpredictable, but they lack the element of guaranteed privacy needed to be used verbatim as a secret key.

Notice that privacy of thought is assumed in the usual Alice and Bob crypto theory stories; mind reading each other or the narrator is not allowed.

$\endgroup$
4
$\begingroup$

Any serious person should not trust random.org to be up all the time. It's maintained by a non-commercial entity that has no economic value in staying up all the time. So your server would only get random numbers as long as it is available. That should be enough to stop any serious usage (beyond the security reasons mentioned by all the others).

I could see a scenario where you have a weak entropy pool, and you use random.org to add additional entropy to your own pseudo random number generator. If it is down, you may fall back to your own weak entropy sources. Note that you need to seriously test if your fall back scenarios work though, you should not get stuck once random.org is suddenly not sending any data anymore.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.