Hardware random number generator

ogogon said:
I believe that your salaries there have either increased significantly, or Boeings have become much cheaper...
Click to expand...
I think the latter. You can get plane parts for free these days (or so I was told).
 
Assuming you have enough of a driver to read from your hardware random number device, could it be as simple as starting a task early on that uses dd to copy from the device to /dev/random? I'm a little shaky on the details of FreeBSD I/O yet, so this may be crazy, but it would seem like the write would block with FreeBSD didn't want any more entropy, and the read would block when the hardware device didn't have any more to give at the moment.
 
External hardware generators are snake oil imo. The only real need for a hardware generator is in some, mostly old, embedded, systems. None of these cases justify an external generator.
 
Decades ago, Byte magazine had an article on building a noise generator that fed into a computer for giving a random number. Someone can search for that. Probably before 2000 but not sure.
Another article I read where the time it took between keypresses for someone on the keyboard
 
This project is available https://www.crowdsupply.com/leetronics/infinite-noise-trng
and supposedly has open source software which works on FreeBSD https://www.crowdsupply.com/13-37/i.../free-entropy-service-libinfnoise-and-openssl
github.com

FreeBSD and macOS support · Issue #8 · leetronics/infnoise

Is there any plan to support FreeBSD or macOS? FYI, I've removed the Linux-dependent part and fix the Makefile for the FreeBSD libraries and the code seems to be working fine for FreeBSD 11.2-STABL...
github.com github.com
but it looks like work has stopped
github.com

GitHub - jj1bdx/infnoise-freebsd: Infinity Noise TRNG Program for FreeBSD

Infinity Noise TRNG Program for FreeBSD. Contribute to jj1bdx/infnoise-freebsd development by creating an account on GitHub.
github.com github.com
github.com

GitHub - jj1bdx/freebsd-dev-trng: An entropy injection device driver for FreeBSD

An entropy injection device driver for FreeBSD. Contribute to jj1bdx/freebsd-dev-trng development by creating an account on GitHub.
github.com github.com
 
I think that for all but the most esoteric applications, an entropy gathering system that can be used to seed a high-end PRNG is adequate. ie collect operating system "noise" and use it to seed mersenne-twister with long period...and use that entropy to reseed the PRNG frequently. That would foil attempts to determine the sequence starting point. I mean the twister has an astronomically long recycle period that makes it relatively secure.

I hate referring to Linux, but their /dev/random entropy system does quite nicely...and if that isn't good enough then the diode avalanche breakdown is good for generating entropy, and some Intel motherboards even embedded such devices for that purpose.
 
drhowarddrfine said:
Decades ago, Byte magazine had an article on building a noise generator that fed into a computer for giving a random number. Someone can search for that. Probably before 2000 but not sure.
Another article I read where the time it took between keypresses for someone on the keyboard
Click to expand...
Keyboard and mouse interrupt data is part of the Linux /dev/random entropy generation.
 
Radioactive decay is inherently truely random at the quantum process level, in the sense that is is impossible (within our current knowledge) to predict when a decay event will occur, and hence can be used to generate random numbers by means of some decay event detection and counting/timing hardware. For some low cost examples and description of the principles involved, see here:- https://www.fourmilab.ch/hotbits/ and here https://karstenschuhl.com/random-generator. I expect if you have money you can buy commercial versions. Sadly it appears John Walker has retired the decay version of 'hotbits' though, which is a shame.

There is another interesting site here https://www.random.org/ , and this accompanying project which derives random numbers from atmospheric noise https://github.com/therealOri/atmos-rng?tab=readme-ov-file
 
If it must be as random as possible, what about radio noise as input? Never tried anything related. but a wifi-controller that's able to show binary receiver noise that's entirely unpredictable would be useable.
And a soundcard? Can we get highly amplified noise from the mic channel without anything connected to it? It may not like it but it might work. Maybe someone knows a trick...
 
atax1a said:
the freebsd entropy generation uses Schneier's Fortuna.
Click to expand...

random(4)

man.freebsd.org man.freebsd.org

Fortuna - Schneier on Security

A secure pseudorandom number generator Designed by Niels Ferguson and Bruce Schneier About Fortuna What’s a PRNG? It’s a mechanism for generating random numbers on a computer. They’re called pseudorandom, because you can’t get truly random numbers from a completely non-random thing like a...
www.schneier.com www.schneier.com
 
VSh said:
I used once some very old web camera for this. It was very bad camera - a lot of noise. Just capture raw image, concatenate with timestamp (higher resolution as possible), hash it, and use it as the key to encrypt something (/dev/zero or /dev/urandom output for instance), but not more than 4MB - then repeat.
If CPU is relatively good, there is /dev/hwrng as well.
Click to expand...
That's what I'd do! Cloudflare's implementation is cool: https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/
 
Another nice project using radioactive decay.
github.com

GitHub - nategri/chernobyl_dice: A quantum random number generator with a Cold War aesthetic.

A quantum random number generator with a Cold War aesthetic. - nategri/chernobyl_dice
github.com github.com
And there are commercial pcie cards, eg vertex and quantis... but they probably do cost as much as a boeing wing :)
I seem to remember years ago there was a pci card with a built-in radiocactive source, but I cant remember the make, probably obsolete now anyway.
 
POSIX.1 said:
bob2112 I sincerely hope that all the foolish villains of this world accept your advice without verification and completely uncritically.

I congratulate you on this low-quality contribution.
Click to expand...

Surely the onus is on others to point to the flaw in FreeBSD's entropy management that would makes these useful.
 
bob2112 said:
point to the flaw in FreeBSD's entropy management
Click to expand...
You could now allow yourself to revise your claim that hardware RNGs are “snake oil.”

You could come to the realization that tapping entropy from a few hardware components is only a limited workaround. Some systems simply do not have a mouse, keyboard, or rotating hard drive, which means that the entropy is of such low quality that it does not meet the requirements for sufficiently secure encryption.

There are ways to degrade the quality of encryption to such an extent that it can be cracked with relatively little effort, namely by manipulating software-generated entropy.

The relevant question is, how to measure the quality of software collected entropy. This can be done by collecting probes and run statistical tests on them. And even such tests needs to be reviewed. See https://csrc.nist.gov/projects/crypto-publication-review-project

Be aware of the problem that even if you had tested your entropy as sufficient, this is a snapshot for this moment only. You simply cannot be sure that it stays all the time at an acceptable level.
 
POSIX.1 said:
You could now allow yourself to revise your claim that hardware RNGs are “snake oil.”

You could come to the realization that tapping entropy from a few hardware components is only a limited workaround. Some systems simply do not have a mouse, keyboard, or rotating hard drive, which means that the entropy is of such low quality that it does not meet the requirements for sufficiently secure encryption.

There are ways to degrade the quality of encryption to such an extent that it can be cracked with relatively little effort, namely by manipulating software-generated entropy.
Click to expand...
What if you add analog circuitry? I don't think it's possible to somehow map a device and predict a variating binary number from a digital voltmeter between 2 points. Quite sure that's 0 success rate.
 
Some notes from John Walker on the hardware design of his hotbits radioactive decay RNG. He used a pancake detector geiger counter, apparantly hooked up to the PC serial port. I also found a blog entry by the author, where he says the service was retired in 2022, so this thread it just a little too late to use his work. It would be an interesting project to replicate his work and create a new web-based RNG service similar to hotbits. Although as was pointed out by 'gpw928' the ANU site performs the same function. My physics is sadly too rusty to know much about quantum fluctuations of the vacuum, but I think we can have a high level of confidence in the ANU as a source.

Regardless, JW has written a nice description here of the design principles for building a RNG based on radioactive decay.

HotBits Hardware

HotBits Hardware
www.fourmilab.ch
He also has a detailed description of the statistical testing used to confirm the correct operation of this RNG.

HotBits Statistical Testing

HotBits Statistical Testing
www.fourmilab.ch
 
This all involves some high level math surrounding the main point of not generating duplicate numbers. If you're just an average joe making a game, then anything will probably work out but there are space adventures where it will not.
 
I wrote an animation program once that merged a time series of images together by uisng a random pixel-by-pixel update algorithm. I used one of the bog standard pseudo-random number generators from a text book, I can't remember which RNG it was now. Because the images were quite large, and the pseudo RNG would cycle every once in a while, you got visually recognisable repeating patterns occurring within the image updates. Which kind of spoiled the effect, which I was hoping would be a smooth imperceptible merge from each image into the next one in the time series. The fix would have been to use a pseudo RNG with a much longer cycle period, or indeed a true random RNG.
 
You must log in or register to reply here.
Back
Top