What is OneRNG?

It is a small USB-connected device

that speeds up & increases your computer's ability to provide you with high-quality random numbers

It has a Tin-Foil Hat

It has a Tin-Foil Hat

Entropy Generator

The cake is a lie …

By default, OneRNG measures unpredictable physical events from an avalanche diode circuit and returns the results — but this is a bit too raw to be used directly

Whitened data

This raw data is then whitened through a CRC16 function which makes it good enough to be fed into your system

There is an AES hardware module available, but it is not used

Keep topping up the pool

There's a 7.5KB pool of data that is kept full

New data is mixed in over the old data all the time

A LED on the board tells you when the pool is full and warns you when it is getting empty

/dev/random

The results are fed into /dev/random as an additional entropy source for the system, and you should read them from there

If you RTFM, you'll read from /dev/urandom most of the time on Linux, but not necessarily on other OSs

And there's more …

You can also enable the RF monitor to get another source of entropy data with a higher quality — but at the cost of a little paranoia

The flow of data

Why random numbers?

Cryptography has a huge appetite for random data

And your online Privacy and Security depends on Crypto

The more you encrypt, the more entropy you need to consume

PRNG

Most of the time you can get away with pseudo-random data

Don't use the default <INSERT_LANGUAGE_HERE> random() function!

Don't use PID, or μsecs since epoch, or wall time

By default, use /dev/urandom

True RNG vs PRNG

Even if your PRNG is a CSPRNG, you'll feel the need for seed

Get your seed values from a True RNG

Generate your long-lived private keys from a True RNG

How much random can a /dev/random random?

Never mind the quantity, feel the quality

… unless you needed quantity, that is …

If your True RNG returned sufficient data, why use PRNGs at all?

Just because you're paranoid …

Even if they aren't out to get you, they'll get you.

Known Badness

• RSA SecurID token breach
• The entire Certification Authority system
• Dual EC_DRBG, $10 million NSA/RSA deal
• RdRand and the Sigint Enabling Project …

Known Badness II

• Supply-chain interception
• BIOS Chronomancy; will persist across reflashing
• Supercookies, Evercookies
• NSA vs Vodafone (aka "We are the 43%")

How far is too far?

When risks are “addressed” they are usually pushed either up or down the stack

They end up requiring trust in End-User Behaviour (unpatchable) or in the Hardware

How does OneRNG help?

Being an Open Hardware and Open Source solution is a start

But the OneRNG is also designed to be verifiable

No Trust Needed

You should not trust this device — you do not need to trust this device

You should VERIFY that what you physically hold is what you need to have

How to verify the hardware

How to verify the software

Scripts on your server should do steps 2,3 & 4 on startup

What does verification tell you?

• The hardware you received conforms with the description
• The firmware that is used matches the source
• Tampering would be detectable

What next?

Kickstarter

http://onerng.info/

Image Credits

Icons used are from The Noun Project, http://creativecommons.org/licenses/by/3.0/us/ licensed

Arrow and Bent Arrow by Thomas Le Bas, Dice by Weston Terrill, Toothbrush, Radio by Joe Harrison, Avalanche by Louis Dawson, Swimming Pool by Sitara Shah, Clock by Nick Green, Guy Fawkes by Christopher T. Howlett, Pac-Man by Luigi Di Capua, Surveillance by Luis Prado, Audit by Miroslav Koša, Skydiving by Jual Pablo Bravo, CPU by iconsmind.com, Certificate by Alex Auda Samora, Incognito by Alen Krummenacher, Layers by Cornelius Danger, Search by Melvin Salas, Seed Packet by Anton Gajdosik (Public Domain)