bem94

I have only read a few passages (and some of the excellent quotes others have shared here), but I find the underlying message here so much more compelling than those found in the various "manifestos" which come out of Silicon Valley.

I think reading this helps me imagine a version of the future I'd actually like to live in. A version where technology is used well (rather than preaching for abstinence from technology) and where values other than "intelligence" (in whatever guise) are on an equal footing.

Even writing that makes me feel naive (and to an extent I know it is) but I think it would be inconsistent for someone who cheers for humanity's efforts to solve/chip away at "impossible" problems (like LLMs were thought to be not so long ago) to shirk from the challenge of making the world better for _everyone_.

> To me what is most surprising is that the attack seemingly came out of nowhere,

This wasn't my understanding at all. The specific issue in isogeny based cryptography which the attack exploits has been a source of worry in the cryptographic community for a while, and is exactly why NIST put SIKE in the "for further consideration & crypt-analysis" category when making their standardization decisions.

It's possible, but it is _a lot_ of work!

You'd basically be building a cryptographic module (industry standard term, with a lot of specs and requirements to go a long with it), which is no small undertaking in terms of correctness, never mind security. The "basic" cryptographic routines aren't easy either. You're talking ECC and some other symmetric primitives. Secure & efficient ECC implementation is an entire discipline on it's own.

I have reservations about the phrase "don't roll your own cryptography" for lots of reasons, but this would be taking rolling your own to the extreme. With all the associated risks.

Absolutely possible and a very cool project, but yeah, it's hard to understate the complexity / requirements of a full cryptographic module on top of the cryptographic primitives it needs to support. I actually really like that this person took an existing commercial TPM and could integrate it into their own PCB this way, I think that's a good compromise between building your own TPM with an Arduino, and having to pay lots of money for an out-of-the-box TPM.

In lots of places this makes sense. E.g. lots of embedded ARM platforms have a separate AES / ECC accelerator peripheral.

The trouble comes when you need to share access to a memory mapped peripheral among multiple threads/processes/users etc. It can be done, but it's usually easier to manage CPU registers than peripheral devices for things like crypto operations in larger systems. Plus, you have to do access control to the peripheral (so other processes don't try and steal your key), if its all within the security boundary of a "normal" process, you get that (mostly) for free.

All of the above has caveats and exceptions, but generally (ARM, SPARC, x86, now RISC-V) take this approach.

There is some overlap. There's the "Zbkb" (horrible name, I know) extension which contains a subset of instructions from the larger bitmanip extensions which are very useful for cryptography.

The more general bitmanip extensions contain other things useful for e.g. address arithmetic. These are somewhat orthogonal to scalar crypto.

The algorithm specific instructions are all optional. You can have AES without SM4 or vice versa. RISC-V is great like that, it's designed to be modular.

> instead of requiring the rest of the world to waste transistors for something that's useless.

I'm sure Chinese manufacturers might feel the same about NIST standards.