PaX [comrade/them]

Well Linux is using rdrand in place of the fTPM one so … from firmware to hardware.

That depends on your distribution’s setting of the CONFIG_RANDOM_TRUST_CPU compile-time configuration option and the random.trust_cpu sysctl setting. I’m not sure what the major distributions are doing with that at the moment.

Then again even if you generate random numbers using pure software, is your CPU or firmware FOSS and without bugs (cough … Debian OpenSSL maintainers, cough …)? If not, and you assume you can’t trust the firmware and hardware - all your random numbers are belong to us.

Like you said, it is impossible to be completely safe. But using proprietary cryptographic hardware/firmware, the inner workings of which are known only to Intel, introduces a lot of risk. Especially when we know the NSA spends hundreds of millions of dollars on bribing companies to introduce backdoors into their products. At least when it’s an open source cryptographic library they have to go to great lengths to create subtle bugs or broken algorithms that no one notices.

Our CPUs are certainly backdoored too, beyond RDRAND. But it’s way more complicated to compromise any arbitrary cryptographic algorithm running on the CPU with a backdoor than making a flawed hardware RNG. Any individual operation making up a cryptographic algorithm can be verified to have executed properly according to the specification of the instruction set. It would be very obvious, for example, if XORing two 0s produced a 1, that something is very wrong. So a backdoor like this would have to only activate in very specific circumstances and it would be very obvious, limiting its use to specific targets. But a black box that produces random numbers is very, very difficult to verify.

Ultimately, the real solution is the dissolution of the American security state and the computer monopolies.

If I’m fucked, they’re fucked.

Not if they’re the only ones who know about the backdoors.

Edit: I started writing that before your edit about the “Ken Thompson hack”. An element of any good backdoor would include obfuscation of its existence, of course. The issue is it is impossible to predict every possible permutation of operations that would result in discovery of the backdoor and account for them. Maybe if you had a sentient AI dynamically rewriting its own code… anyway, backdoors in tooling like compilers is very concerning. But I’m not too concerned about a Ken Thompson type attack there just because of how widely they’re used, how many different environments they run in, and how scrutinized the outputted code is.

👁 Imagine using any commercial firmware/hardware RNGs.

No, by running a relay or exit node you are opting in to routing traffic that could contain CSAM. This is a problem with all anonymous unmoderated distributed systems like Tor. With Freenet, for example, you’re even opting in to storing it (pieces of it in encrypted form that can’t be accessed without the content hash key).

Privacy is good but so is censorship (moderation). The censorship just needs to be implemented by an accountable group of people that share the same interests of the users. Tor is trying to solve a problem that can only be solved through social struggle with institutions of power.

I like Alpine Linux. You could also try OpenBSD if you want a Unix that just works without as much struggle. NetBSD and FreeBSD are also around and have Linux binary compatibility.