WaywardGeek

As you all know, the UK tried to force Apple to give them a secret mass surveillance capability, not just for UK citizens, but Apple users globally. As a result, Apple disabled "Advanced Data Protection" in the UK.

OpenADP is Open source Advanced Data Protection for everyone. It defends vs secret mass surveillance via software transparency and distributed trust. That distributed trust is built through OpenADP servers run by volunteers around the world.

OpenADP has servers in the US, but for resistance to any one government, volunteers in several countries are needed. There is a quick-start guide for running OpenADP on a Raspberry PI. If you've got a Raspberry PI to spare, and some free time, consider volunteering for OpenADP.

Another sealed computing use case that is public: https://developer.android.com/about/versions/pie/security/ck...

And this one: https://security.googleblog.com/2022/10/SecurityofPasskeysin...

I've been fortunate to be paid by Google to hide user data from Google since 2016. Not many companies would shell out anything for this sort of privacy feature.

As for the Oak stack, they win the race. It is the only stack that currently provides full hardware attestation covering 100% of the code running in the enclave, and 100% of it is open-source. There are other good efforts, such as CoCo containers with their Key Broker, but so far they only cover the initial boot firmware, not the full set of software running inside the enclave.

Kudos to the Oak team!

Just throwing it out there... if the radio is a problem, I'd love for Paul and friends to replace both the radio and avalanche source with an "infinite noise multiplier", which I feel is more secure than either alone, but probably not as secure as these two very different sources together. However, that would delay things quite a bit. I'm hoping maybe version 2. Also, the wider community has zero experience with INMs, so it will take a while before such a source is generally accepted.

Also, this concern about the radio requires someone to 1) hack the TRNG, and 2) have a nearby receiver. At that point, they probably could more easily just PWN your system, and forget about the TRNG. Paul is doing some clever things to make it very hard to hack his firmware, but a keyboard logger is still easy for an attacker with physical access, as is any number of attacks.

Still, a USB phy is required. How would you solve this problem? Would a FTDI USB chip be more palatable?

The channel hoping is just a bit of software. It costs $0.00 in additional hardware. Software complexity is a big deal in a TRNG. The KISS rule applies big-time here. The more complex the software, the more likely it is a significant flaw will be found and exploited. It remains unclear to me whether there should even be a microcontroller on a USB TRNG. Without one, we can eliminate the complexity from the USB key itself, but we have to move the whitening and health monitoring to the driver. It is unclear to me if making the driver more complex opens it up to enough additional attacks that the system is less secure overall.

There are plenty of decent sources of entropy, like webcams and sound cards. However, they all add parts we don't need, and they don't take any care to design with security in mind. Eventually, a good open hardware TRNG should be cheaper, more reliable, easier to use, and more secure than any of those solutions, IMO.

Every TRNG I've seen so far that uses "zener noise" is actually using the reverse breakdown voltage across the emitter-base junction of a cheap NPN transistor. This is a zener diode! The reason this form of zener is used is simply because the fab does not bother to put in any effort to reduce the avalanche noise. Noise like that makes zeners sold as zeners unpopular.

Zener avalanche noise is unpredictable. How is an attacker supposed to guess when the next electron/hole pair is going to be created in the depletion region? Physically, what happens is the emitter-base junction is reverse biased, turning it into a diode that is blocking current from flowing from the emitter to the base. Every once in a while, due to thermal noise and likely quantum effects, an electron jumps up a valence level, creating an electron/hole pair in the middle of the reversed-biased N/P junction, where there is a strong electric field. This launches the electron in one direction and the hole in the other, where they gain speed rapidly. The electron has higher mobility and will gain enough speed to bang into other electron/hole pairs, creating an avalanche of electrons.

There is no known way for anyone to guess when the next avalanche will occur, or how large it will be, so long as there is no outside signal controlling this effect. Implemented poorly, it can just put out power supply noise, and not true unpredictable entropy. Implemented well, it is a solid, reliable, cheap, and fast entropy source. It is absolutely critical that a zener noise TRNG has an open auditable design!

As for "quantum" effects, I consider that marketing fluff. What we need is provable, reliable unpredictability, not some radioactive decay or photon emission. We don't need 100% unbiased unpredictability either, just a signal that cannot be predicted with much accuracy.

Is it possible for this device to transmit over radio, or only receive? I certainly prefer only being able to receive, as transmitting seems like an attack vector.

With the assumption that it only receives, I would strongly prefer that it be left on by default. Adding a second source to the CRC mixing can only improve entropy, even if the source is controlled by an attacker. Since the noise from the zener has no simple proof of it's entropy output rate, and it can vary over time, and because zener noise TRNGs have been known to be power-supply noise sensitive (not that your's is), having that second source gives me much more confidence in the device.

Note: I've only glanced at NeuG, so this is an over-simplified repy. Neug relies on a few different A/D inputs as a noise source. The resolution of the A/Ds is only 12 bits, meaning it is not capable of reliably measuring thermal noise in the system. In any case, it does not seem to be trying to measure voltage on a high impedance node. Therefore the data passed will be power supply noise and other sources of external influence. These potentially can be influenced by an attacker, maybe even remotely. I do like this architecture for a TRNG, and I like that it is open, but I do not believe the creator of NeuG has put nearly the TRNG know-how into this design as OneRNG. Personally, I'm looking forward to signing up on the Kickstarter for OneRNG when it happens.