Chaos of Randomness


Debian Random Number GeneratorThe previously reported bug in the Debian OpenSSL library had besides the directly associated negative impact also brought forward a lot of good things! Consciousness about random numbers (unpredictable numbers) and their importance in cryptography and security in general, has highly improved, as many discussions on mailing lists and forums can attest. New tools for testing weak keys were introduced and a web based community project was launched which lets anybody validate their key quality.

It’s also an opportunity for me to brag a little bit about the service level the StartCom Certification Authority provides in respect to key generation. Somehow it’s taken for granted that we use and deliver good keys, which for server certificates  is provided as an optional service. As a matter of fact, many subscribers rely on our private key generation utility instead of creating their own keys and submitting  certificate requests (CSR). But there aren’t many opportunities for us to talk about the dedication and the importance we give this particular function (amongst many others).

Usually we always love to define every bit and bite in computing, control and predict every outcome. Whenever failing to do so, it usually results in a failure of the program, a so-called bug. With random numbers however we introduce chaos, the more unpredictable the better. The unpredictable, unreproducible and unbiased distribution of random numbers makes up for really true random number generators, something software based or so-called pseudo random number generators can’t provide. StartCom uses a hardware based true random number generator (RNG) with the ability to spit out up to 10M raw bits per second.

There are also various standards and tools to test and verify RNGs. One of them is rngtest on Linux using FIPS 140-2 tests to check randomness of data. Below is a (good) test result of our RNG device:

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=18.928; avg=1053.174; max=4882812.500)Kibits/s
rngtest: FIPS tests speed: (min=19.198; avg=1196.749; max=29818.702)Kibits/s
rngtest: Program run time: 34929243 microseconds

Impressive, isn’t it? Now, should you want to test keys you created previously or as you receive them from the StartSSL Control Panel I suggest to check out the HashServer project. It’s a public service operated by CAcert to detect compromised, weak SSL/X.509 keys. Just make sure you submit the certificate request (CSR) or certificate and not the private key itself!

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
Announcing Better Trust™
Phishing or Legitimate?

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

You must be logged in to post a comment. Click here to login.

Reader Comments

Eddy, if you have a true RNG you have accomplished what some say is impossible. I’ve heard of RNGs that take input from things like super sensitive microphones capturing the white noise caused by molecules bumping into each other, but of course you have non-random events making non-random sounds in any environment. For my computer science minor thesis I considered doing a random number generator until I read about the brand new (this was 1970) chaos science that told me that true randomness is not to be found in the real world.