XOR it with /dev/urandom, the result will be as strong as the best source of entropy.

I don't think this is true without some assumptions. The two bitstreams could cancel out if cleverly chosen.

That would mean that the attacker can already predict /dev/urandom, rendering it effectively useless. So the parent is right, "the result will be as strong as the best source of entropy", if both sources are bad then the result will be as well.

It is true under the assumption that the two sources are independent of each other. If one of the sources is entirely known or predictable, this will not affect the entropy of the other source.

If you know "the other" bitstream, sure. The only sensible premise is that you don't.

If both bitstreams are cleverly chosen, then neither is a source of entropy.

But isn't the point of a hardware entropy source that you don't quite trust /dev/urandom?

You have two adversaries. Adversary A have control over your hardware source, and adversary B have control over /dev/urandom. If you XOR them A and B must cooperate to compromise your random generator. You can combine as many sources of randomness as you want, and each increase the difficulty for an adversary to defeat your generator.

That just gets you the entropy of /dev/urandom, if you can't trust your original source.

Do you have any recommendations for other, high quality, sources of entropy?

FSF sells a true random number generator:

[1] https://shop.fsf.org/storage-devices/neug-usb-true-random-nu...

[2] https://lwn.net/Articles/647502/

[3] https://lwn.net/Articles/648550/

Cloudflare uses a wall full of lava lamps, theres a tom scott video on it

https://youtu.be/1cUUfMeOijg

In most cases you can use the Intel CPU included RNG by installed rng-tools to feed it into the kernel entropy pool

Otherwise I’d be happier using a similarly priced USB tool that is at least designed for the job such as the ChaosKey which is also open hardware and firmware and has a Linux driver in tree

With all the issues with Intel, I would be weary of trusting their implementation.

It's "wary". The word "weary" means tired.

Edit: Just curious: are people downvoting because they disagree with my proposed spelling, or because they don't like the correction? Please let me know so I can integrate this knowledge into future comments.

Analysis of Intel’s Ivy Bridge Digital Random Number Generator

http://www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_...

A geiger counter next to an ionization smoke detector should have some entropy, though I don't know how high the quality would be.

https://www.sparkfun.com/products/14209 https://www.newegg.com/Product/Product.aspx?Item=0EF-005S-00...

Avalanche noise...

https://emergent.unpythonic.net/01257868826

No. The main problem is not the type of physical process, but the lack of any detection of failures.

Hardware fails. Can you reliably detect that? The board you linked to cannot at all. Most HWRNGs can, but only partially.

Infnoise: https://github.com/waywardgeek/infnoise

https://www.tindie.com/products/WaywardGeek/infinite-noise-t...

Thermal and other noise by analog electronic parts (resistors, transistors pushed to high gain etc.) comes to mind. They are much safer compared to an online service, app or a piece of hardware one doesn't have the source for, but I have no idea if that noise is good once sampled to be used in cryptography or other non-analog fields.

You have to sample the noise, and deskew it, and check the components are still operating. This is where the errors normally lie.

It's probably a fun project to try, but I'd be wary of using it for cryptography if only because we have other better methods.

I collected a bunch of links a while ago. Here they are, I don't know if these are still working or interesting, but they might be useful: https://news.ycombinator.com/item?id=6060636

Thanks for this! I was looking for something like this to play with.

In general, use a pool and worry less for most purposes as long as some of them are good enough.

An old project of mine:

http://random.hd.org/

It was good enough to use for a financial application when whitened / XORed with system sources.

If on an embedded system the low order bit of an infrequently sampled ADC input might be acceptable.