Nostr notes by hotatenobatayaki

instead of thinking that CPU are not trustworthy, you should ...

2025-04-03T08:13:28Z

In reply to nevent1q…xu8c
_________________________

instead of thinking that CPU are not trustworthy, you should think that the untrustworthy side of CPU can be verified against other CPU. If you don't trust CPU A doing 1+1=2, try it on CPU B. Granted there's different architecture and stuff but you can cross compile.

oh and you don't trust cpu manufacturers. What makes you ...

2025-04-03T08:11:36Z

In reply to nevent1q…qvlt
_________________________

oh and you don't trust cpu manufacturers. What makes you trust fpga manufacturers? Their compiler are way more complicated and less open source than normal cpus.

Not to mention FPGAs are the home of IP (intelectual properties) blocks. Some fpga contain hdmi module that you can turn on easily but is otherwise a proprietary blob of silicon.

for timing analysis such as comparing password (hashes) ...

2025-04-03T05:36:12Z

In reply to nevent1q…0t9v
_________________________

for timing analysis such as comparing password (hashes) there's constant time comparison, such is used by bcrypt for checking password hash without revealing password hash through timing sidechannel.

But depends on usecase. What are you thinking about?

answered that. The unsatisfying answer is just, anything logical ...

2025-04-03T05:12:15Z

In reply to nevent1q…neh4
_________________________

answered that.

The unsatisfying answer is just, anything logical is possible with an idealized FPGA. Real FPGA has logic element constraints (not so many of those gates to do stuffs), you can't implement current CPU with a single FPGA. Maybe if you have a few of them it'd work..
There's also the bandwidth and time limitation. And there's cost.

FPGA does not scale well for large application.

possible yes. Practical not. We're talking about fpga that ...

2025-04-03T05:09:36Z

In reply to nevent1q…kmaa
_________________________

possible yes. Practical not.

We're talking about fpga that either reprograms itself or fpga that contains multiple implementation of the same thing in order to mask its operation from side channels. FPGAs have a limited (quite limited) number of logic blocks to use for whatever you're making.

I guess the economy is this: I'm claiming that it's ...

2025-04-02T23:09:42Z

In reply to nevent1q…e88d
_________________________

I guess the economy is this: I'm claiming that it's cheaper for a group of individuals to decap a single (multiple) off the shelf processors and confirm that they are trustworthy, than it is for giant fabs to make 'safe' and 'backdoored' version of the same IC, because making the lithography mask is a very expensive thing whose cost is amortized by chip sales

The arms race you mentioned already begun. First they stop ...

2025-04-02T08:04:30Z

In reply to nevent1q…875e
_________________________

The arms race you mentioned already begun. First they stop putting opcodes in the manual but then people found out by bruteforcing opcodes and seeing the change in register.

Clear plastic covering is out of the question. 1. Silicon chips are sensitive to light. There's an issue with early raspberry pi model where the board would reboot if someone took a flash photograph. 2. You can't resolve nanometer detail behind plastic casing.

It's expensive, but worth it imo.

the reason why cpus are not FPGAs are simply because FPGAs are ...

2025-04-01T13:07:19Z

In reply to nevent1q…cag8
_________________________

the reason why cpus are not FPGAs are simply because FPGAs are larger, less effective, and pricier. It's like having a development board arduino instead of just the atmega chip.

If you don't believe in CPU manufacturers (not saying anyone should) and bootstrapping is difficult, maybe consider another route and have independent researchers decap a few ICs and see the microcode implementation, and see if there's any hidden rings or opcodes.