[mindslight]

I agree with your entire comment except for the first sentence. When working for a ideological goal, it is important to continually and earnestly evaluate what goals the imagined solution will actually fulfill, lest one end up misplacing faith in an implementation that can never achieve the desired ends.

First, this FPGA is still not implemented by things that are the lowest level - how do you know that 7404 doesn't actually contain secret logic looking for specific patterns on the 6 "independent" inputs (based on your widely-propagated design) that alter it's behavior?

Second, if one wanted to build an auditable CPU, they would not start by building auditable reconfigurable logic in order to develop a soft core CPU on top of it. This is a needless extra layer of interpretation, and the number one constraint you're trying to overcome is the constant factors that are left out of the Big-Oh notation.

We don't buy Intel processors because we're lazy and have money to burn, but because they contain a billion transistors switching a billion times a second. If you build something with 10k transistors switching at 10M Hz, something that would take 1 second on the modern CPU will take roughly 3 months.

So I think there's two properties to be achieved for actual Free Computing. The first is roughly getting something that can compute. These days, this can be done by buying a standard PC and installing your own software on it. This may not continue to be possible (so we would have to eg rely on integrating our own ARM chips, then FPGAs, then microcontrollers, etc), but trying to put a solution forward before it is necessary isn't going to get very far. There also is available computation that is unlikely to go away - Javascript in web browsers, available to all but sandboxed programming toy apps, etc.

Which brings us to the second quality of Free Computing, which is auditability - guaranteeing that the code running is doing what it says, rather than a subtle corruption which renders the whole sensitive algorithm broken. To get performance, we would like it if such a CPU could be made in a necessarily non-trusted fab, rather than independently assembled from discrete transistors. This seems like a harder, but yet better defined problem - meaning it might actually be possible to solve through some combination of clever proofs and bootstrapping trust up from an extremely simple auditable CPU.

[bitcracker]

> I agree with your entire comment except for the first sentence.

I meant the term "first step" historically. It is really the first step to true open hardware because it is the first project (as far as I know) that solely relies on basic electronics you can solder together on your own pcb.

There are many open hardware projects but all of them are based on complex hardware (FPGA kits etc.). There are several good open cores you can download into your fpga but what if someday your fpga stops working and you can't buy another one because these fpgas are not produced anymore?

I agree with you that selfmade processors will never be able to compete with modern processors. But even a 1 MHz 8 bit cpu can do a lot of things. Remember the huge success of Commodore 64. And if you are able to 3d-print one such a cpu you can also print many, and build a multicore system.

Who says that selfmade processors have to work with silicon and copper? If someone finds a way to produce cheap conductive plastic filaments that would be a huge leap forward for printed circuits. I believe that there are several smart hardware hackers who could achieve a solution we could live well with. 3D printing is just in the beginning. I expect amazing times to come.

[mindslight]

1. Plenty of CPUs have been built from discrete logic.

2. As soon as you start talking about complex printed items (including PCBs), you're necessitating either a trusted computational device to compile the design and drive the printer, or the ability to audit the output of the printer (eg read and understand the traces on a 2-layer PCB).

[ansible]

First, this FPGA is still not implemented by things that are the lowest level - how do you know that 7404 doesn't actually contain secret logic looking for specific patterns on the 6 "independent" inputs (based on your widely-propagated design) that alter it's behavior?

Don't let your paranoia get the better of you.

With only 6 inputs, if there is any anomalous behavior, it will quickly be noticed. And this subverted 7404 would need to have all its gates used on the same bus to have a hope of seeing that you're illegally copying a movie, and that is a rare application.

And I think someone would notice that these inverters are using 6 orders of magnitude more power than necessary.

Even for more complicated parts like CPUs, such tampering would be readily evident.

For a long time to come, it will be a lot easier to hide nefarious code in software in some corner of a general purpose system (PC, tablet, etc.) than to put it into the hardware layer. Even nefarious code needs network communication these days, otherwise there's not much point.

[mindslight]

I hadn't considered the added power draw due to the likely complexity involved in making a good backdoored hex inverter, good point there. It seems like there's a natural contour such that as the individual component gets smaller and less complex, the amount of circuitry required for a backdoor increases.

Software certainly is easier to backdoor, but hardware is much more insidious. At this point I'd be surprised if there weren't backdoors in the widely used processors for at least the NSA. (Remember that innocent time when the question whether the 'net was tapped and recorded was up for discussion? :P)

So I guess I view both of my aforementioned properties as mandatory due to the use case for my analysis (trustable function execution), while the OP was really just talking about the first one. I'd originally considered this question in the context of cryptographic key generation and management, where the second property is of utmost importance to be confident that there aren't low level backdoors giving bias to your crypto keys and nonces. Plus if you're spending the time to bootstrap trustable computation up from a hand-built circuit, you might as well go all the way instead of trusting something like an MCU.

[ansible]

... where the second property is of utmost importance to be confident that there aren't low level backdoors giving bias to your crypto keys and nonces.

If there are backdoors in modern processors, it is likely located in the on-chip firmware for the boot sequence and/or in the secure key store. Those are the two main areas I'd worry about, and I'd also keep a close eye on any binary blobs needed for the secondary processors cores on a modern SoC. And also the firmware for the WLAN chip.