
NeuG USB True Random Number Generator - brudgers
https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator
======
starsinspace
Weird how they specifically point out "free as in freedom", but then the real
brain of this entire thing is a proprietary STM32F103 MCU.

~~~
bb88
To be fair, yes, the proprietary nature of a particular chip is bad for open
source, but on the other hand, the marginal cost of a chip is not zero, like
it is for software. There's the chip fabrication costs which only goes down in
quantity. That means there's an inherent risk in developing a new chip.

However, if you're that concerned about it, there are open source designs
which create free truly random bits, so you are free to choose a design that
meets your need.

~~~
tonyarkles
Additionally, and I'm not positive that they've actually done this, but the
chip _also_ has fully open toolchain. While the guts of the chip aren't open
source, it's possible for the firmware to be 100% open source without any
binary blobs.

------
hannob
Controversial opinion: Hardware Random Number Generators don't solve any real
problem.

The problems they're supposed to solve are entirely fictional and usually stem
from a poor understanding of the real problems there are with random numbers
(which can mostly be traced back to a few issues: boot time entropy, userspace
RNGs and use of insecure RNGs by mistake).

~~~
raverbashing
How are you supposed to get entropy into a system with no (good for RNG)
inputs and no sources of noise? (think: embedded)

~~~
tptacek
Not with a USB HWRNG.

~~~
schoen
I don't understand this part of your criticism. Your core criticism has been
that we don't really need hardware TRNGs because the math of CSPRNGs doesn't
lead to "entropy depletion" in the way that people's mistaken mental models
might suggest.

That's fine, but boot-time seeding problems are also a real source of RNG-
related security problems, as described in the "Mining Your Ps and Qs" paper.
(E.g. "The removal of IRQs as an entropy source has likely exacerbated RNG
problems in headless and embedded devices, which often lack human input
devices, disks, and multiple cores. If they do, the only source of entropy—if
there are any at all—may be the time of boot.") Having a hardware TRNG for
seeding in this case would presumably prevent these problems.

~~~
loeg
Embedded systems may be physically small enough that plugging in a USB key
doesn't make any sense. An embedded HWTRNG chip onboard or in the SoC may make
sense.

~~~
schoen
Thanks, that makes sense.

------
sowbug
This is also available at Seeed Studio:
[https://www.seeedstudio.com/FST-01-without-
Enclosure-p-1276....](https://www.seeedstudio.com/FST-01-without-
Enclosure-p-1276.html) By the time you read this, it'll probably be sold out,
but I coincidentally signed up about a week ago to be notified when they were
in stock, and I got that notification yesterday.

It's also possible to have MacroFab
[https://macrofab.com/](https://macrofab.com/) manufacture these for you on
demand, using the KiCad files:
[http://git.gniibe.org/gitweb/?p=gnuk/gnuk.git](http://git.gniibe.org/gitweb/?p=gnuk/gnuk.git)
The cost for a single unit is about $45, and it drops quickly to around $30 if
you order a few.

~~~
busterarm
Blast. I read this, it was in stock, I added to my cart...then the office
lunch order showed up and I had to deal with the delivery for 5 minutes. Came
back, out of stock. So sad.

~~~
sowbug
If your goal was a small hardware RNG and you don't mind spending some time
hacking, then I can save you some money.

Buy an ST103F development board ($1.72 shipped to US from China):
[https://www.aliexpress.com/item/1pcs-STM32F103C8T6-ARM-
STM32...](https://www.aliexpress.com/item/1pcs-STM32F103C8T6-ARM-
STM32-Minimum-System-Development-Board-Module-raspberry-raspberri-pi-2-watch-
nmd-diy/32786765274.html)

Also buy an STLink programmer for it ($1.98 shipped):
[https://www.aliexpress.com/item/ST-Link-V2-Programming-
Unit-...](https://www.aliexpress.com/item/ST-Link-V2-Programming-Unit-mini-
STM8-STM32-Emulator-Downloader-M89-New/32636724482.html)

Build [https://github.com/texane/stlink/](https://github.com/texane/stlink/)
or install OpenOCD.

Clone the NeuG repo and build for the Maple Mini target:
[https://anonscm.debian.org/cgit/gnuk/gnuk/neug.git/](https://anonscm.debian.org/cgit/gnuk/gnuk/neug.git/)

Now flash neug.bin to the development board via the STLink, then unplug it and
plug the board into your nearest micro-USB cable.

You now have a hardware RNG running the same NeuG software on the same
processor family as the FST-01.

This board doesn't have enough program space to run GnuK, I think. Nor is it
in the tiny form factor of the FST-01 that makes it more suitable as a
hardware token.

------
Tomte
Hardware random number generators sound like a great idea (I've bought an
Entropy Key, long ago), until you realize all the problems they intrinsically
have (besides all that "you don't need them stuff"):

* software has /no/ random failures, hardware does

* hardware ages and breaks down, often in subtle ways

* a broken down randomness engine is very hard to detect, since all HWRNGs do some whitening: your randomness source can output 1's all the livelong day, when you only see the output of some stream cipher operation or some chained hashes, no statistic tests are going to save you

* probably many more things

Hm, I really should consolidate my notes into that long-planned HWRNG article
someday.

------
alex_young
Or just grab some hotbits:
[https://www.fourmilab.ch/hotbits/](https://www.fourmilab.ch/hotbits/)

------
AdmiralAsshat
Don't we already have "true" random number generators embedded on most modern
processors? I was under the impression most motherboards have some sensors
strictly for this purpose--to read data from static or thermal sensors in
order to add entropy to the pool.

~~~
brndnmtthws
Intel CPUs do indeed have a random number generator onboard:
[https://en.wikipedia.org/wiki/RdRand](https://en.wikipedia.org/wiki/RdRand)

Probably the safest thing to do is to use a combination of this and other
sources (multiple entropy sources), just in case there's an NSA backdoor or
it's otherwise broken. Things like microphones, cameras, input devices, and
other sensors are nearly ubiquitous now.

~~~
nfoz
Is there any trick to combining entropy sources? Do you just add the numbers
together, or is it something more involved, to make sure that you -- I don't
know -- collapse entropy away in the combination, or something.

~~~
dfox
For cryptographic applications you generally just hash every input you have
together with secure hash function.

Somewhat philosophical corollary to that is that when you have hash function
that is secure enough for your application you can just build CSPRNG from it
and use small (eg. 128 or 256 bit) seed and you have no need for hardware RNG.

~~~
tptacek
Yes, modulo the fact that you want to update the CSPRNG with new entropy
continuously to re-key it. Not to improve the cryptographic strength of the
output or (for God's sake) to avoid "depletion", but to create forward
secrecy. For instance: if the interval between reseedings is short enough,
because updates are super cheap, you can make your RNG state churn too fast to
be a useful target for something like Meltdown.

~~~
pvg
How does reseeding the CSPRNG create forward secrecy? I thought that if
someone lifts your CSPRNG internal state (after it's been seeded and the seed
tossed), they wouldn't be able to play it backwards to get previous output
you've used as session keys or whatever.

~~~
tptacek
I'm abusing the term, I know. But the idea is simple, right? Even a minuscule
update to the kernel entropy pool makes a previously compromised state
unusable. So you don't want your CSPRNG to just be a bit generator, like HMAC
or CTR.

(Zvi Gutterman refers to the property I'm talking about as "backwards
security", so my abuse of the term is particularly egregious).

~~~
pvg
Hah, I was really asking what you meant, not trying to chide you about about
terminology. Makes sense, thanks.

------
martin1975
I like how they call it a 'true' RNG... unless it's got a cesium core and a
Geiger counter mounted on the USB, I'd hardly call it 'true' :). At best, it's
good enough.

~~~
Tomte
Why do you think that radioactive decay is the only "true" noise source?

Shot noise, avalanche noise etc. are just as true. Even throwing a die would
be in the same category.

~~~
martin1975
Even the roll of a die could be called non-random, since the numbers that come
up are actually the result of a number of forces acting together on the die,
including the force of the rollers hand, gravity, air gusts, the surface they
fall on, etc.

Same principle would apply to all the other methods you mentioned since
there's always a definite seed value, regardless of how difficult it is for
you or another observer to capture it.

All the approaches you listed would result in quality pseudo-random numbers,
however, a genuine random number at the source has no apparent cause or series
of events leading up to it. Cesium is one such source of genuine, uninspired
and uninfluenced source of randomness. Cosmic radiation is probably another
although that's probably a lot harder to capture.

Here's a more detailed explanation of why radiation from radioactive decay is
bona fide random.

[https://www.symmetrymagazine.org/breaking/2009/03/30/real-
ra...](https://www.symmetrymagazine.org/breaking/2009/03/30/real-random)

[https://engineering.mit.edu/engage/ask-an-engineer/can-a-
com...](https://engineering.mit.edu/engage/ask-an-engineer/can-a-computer-
generate-a-truly-random-number/)

The NeuG is best described as a high quality PRNG as are most others unless
they truly capture some random, cosmic phenomena, like echoes from the big
bang detectable as cosmic background radiation.. Allegedly nothing tops the
big bang as a random number generator.

~~~
Tomte
From your article: "So how does this lead to random numbers? Statistically, a
cesium-137 atom has a fifty-fifty chance of decaying in 30.17 years. BUT,
there is absolutely, positively no way to predict exactly when any individual
atom will decay."

Still no difference to shot noise or avalanche noise. You have a statistic
that says how many electrons you exppect to see, but no foundational knowledge
which electron will be seen at what point in time.

I find your point of view very esoteric.

------
madengr
Why not just sample a noise diode, or thermal noise from a highly amplified
resistor? Is the process of amplification (i.e. periodic power supply noise)
enough to influence the randomness?

~~~
sigstoat
why do you think that's simpler than what they're doing?

you'd still have to feed that through something to get it into a PC. the STM32
is about the cheapest way of doing that. and it turns out it comes with some
ADCs that are so noisy they're good sources of randomness themselves.

~~~
IWeldMelons
The cheapest way is to use good old soundcard, an opamp and passives. You
could fit in $1 easily.

------
kozak
Shoot some photographs (or video frames), make sure there are no duplicates,
take hash functions of them, delete the images - and voila, you have the
finest true random bits of data.

~~~
cleeus
It's not that simple.

Some years ago I used an analog TV card tuned to an empty channel that was
giving seemingly white noise and captured frames to generate entropy. I only
used the least significant bit of each RGB value of each pixel.

When I supplied the bits to the diehard testsuite, it complained about a
number of patterns and failing tests.

The hash function will of course save you, but it's hard to tell the amount of
real randomness that's coming from the sensor.

update: Oh, I may have misunderstood. If the whole images changes in random
ways and is secret, then of course this is fine.

