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_.

All national agencies I'm aware of do not support QKD except in "very specific cases" and instead recommend Post-Quantum Cryptography (PQC).

From the UK NCSC [1]:

> QKD does not provide authentication, nor do any other quantum techniques. Therefore, in practice, QKD must be combined with other cryptographic services to provide security against the threat from quantum computing, and therefore should not be relied on as a mechanism that provides substantial security value. [...] The NCSC will not support the use of QKD for government or military applications. PQC is the best mitigation to the threat to cryptography from quantum computers.

And the German BSI (and partners)[2]:

> Together with European partner agencies from France, the Netherlands and Sweden, the BSI has published a Position Paper on QKD. The paper concludes that QKD can only be used in niche use cases due to its technological limitations and that QKD is not yet sufficiently mature from a security perspective. Therefore, in light of the necessary migration to quantum-safe schemes, the clear priority should be the migration to post-quantum cryptography.

This is despite different choices for which PQC algorithms to use. E.g. NIST (and many others including the UK) have gone initially with ML-KEM for key exchange, while Germany/BSI have selected FrodoKEM and Classic McEliece.

[1] https://www.ncsc.gov.uk/paper/quantum-networking-technologie... [2] https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisati...

I'd expect a finding / paper like this to be submitted to the IACR ePrint server [1] to bring it to the attention of the cryptographic community. I can't see that it's been submitted yet.

Venue should not imply credibility but in this case it would certainly help bring the proper scrutiny.

[1] https://eprint.iacr.org/

> I find the suddenness, almost haste to be quite interesting. > But there is a clear change around 2022, 2023.

I think that's probably because the NIST competition [1] to choose their standard algorithms really started to heat up then.

NIST has a very large gravity well in the academic and industrial cryptographic community, so as soon as it became clear which algorithms NIST would pick (they chose Kyber / ML-KEM and Dilithium / ML-DSA), the (cryptographic) world felt it could start transitioning with much more certainty and haste.

1. https://csrc.nist.gov/projects/post-quantum-cryptography/pos...

> 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.

Direct links to some of the latest specs:

- Scalar crypto: https://github.com/riscv/riscv-crypto/releases

- Vectors: https://github.com/riscv/riscv-v-spec/releases

- Bitmanip: https://github.com/riscv/riscv-bitmanip/releases

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.

It means that each instruction reads no more than two general purpose registers (i.e. inputs), and writes at most one. When you build CPUs, register files are expensive components, and the more parallel accesses to them you need, the more expensive they become. RISC architectures generally rely on only reading two operands and writing only one result. Sometimes this rule is broken, but RISC-V tries to stick to it unless there's an extremely good reason.

> for those who don't feel like reading the spec:

I'm biased, but the spec is supposed to be very accessible to people without a cryptography background. There's a section on who the intended audience is and what assumptions are made about their background. I'd really recommend it.

> The SM3/4 were unfamiliar to me - apparently it is a hash function & block cipher used in Chinese WiFi variant.

SM3/4 are required for use in certain places in China. RISC-V is popular in China, hence their inclusion in the RISC-V spec. My expectation is that SM3/4 will not likely ever be adopted outside China.

> Physical entropy source (with some variants to accommodate low profile variants)

There are no "variants" of the entropy source. There is one entropy source interface definition which is designed to scale across the many RISC-V implementation profiles. It's very different to x86/RDRAND which lots of people are used to.

The point is that RISC-V allows people to build their own tweaked / extended processors without having to pay an ARM and a leg for it.

Right you are, that's the group responsible. It's something of a priority for RISC-V international right now, because of exactly this worry.

RISC-V International is sometimes really bad at communicating that it's working on these problems. But odds on, they usually are.

> I can't imagine RISC-V beyond niche applications unless someone publishes a more strictly specified version of it that provides a unified platform.

They're working on this right now. Niche applications can still do their thing, but there will be standard profiles for e.g. a "Linux class" application processor, or an "ARM Cortex-M*" equivalent micro-controller.

What does "moral diabetes" mean?

In a plea for accuracy, can we be specific about which type of Diabetes we are talking about? They are _very_ different, both in how they are caused and how they are managed.

What is meant by "invisible security"?

> This article makes far reaching societal claims with essentially no evidence. The evidence presented is in the form of "feelings" of various writers concerned of their own decline in literaryfocus.

From quite far down in the article, under "Concrete Thinking":

> As it is, we now have greater levels of at least superficial participation in political discourse, if not in politics itself, thanks in part to social-media technologies. Vast numbers of people contribute scantily supported opinions about things they don't really understand, validating the old saw that a little bit of knowledge can be a dangerous thing.

> Thus, we have a writer privately squeezing into an artificial, decontextualized "space" in order to convey something, fictive or not, to unknown readers in unknown but theoretically very distant times who are similarly situated, so to speak, in an artificial, decontextualized space.

Good grief.

Edit: This whole article could use a furious edit.

This is really cool - I hope people will start offering companion courses: "Verifying a RISC-V processor". If you've done both, it's a real multiplier for your understanding of CPUs and hardware generally.

Brave of them to do support for the vector extension, given that it hasn't been ratified / officially standardised yet[1]. It's still a work-in-progress. The final version of the vector extension may have small (or enormous!) incompatibilities, so you might be tied to one of their toolchains to use it properly, rather than something upstream.

1. https://github.com/riscv/riscv-v-spec/

> The internet is just mean, to everyone. I feel like with the negative karma on all this ladies unpleasant comments she really didn't get it that bad.

I don't think gatekeeping bad experiences on the internet is really helpful here.

The RISC-V core in question is the VexRISCV core[0]. It comes in two flavours depending on the kind of FPGA[1]:

- 100 MHz VexRISC-V, RV32IMAC + MMU, 4k L1 I/D cache on the Xilinx FPGA

- 8 MHz VexRISC-V, RV32I, no cache on the Lattice iCE40UP5K FPGA

0. https://github.com/SpinalHDL/VexRiscv 1. https://www.crowdsupply.com/sutajio-kosagi/precursor

I've said it elsewhere, but...

If I were carrying out this attack against NIST, and it had failed up to now (i.e. they chose 'wrong' from my perspective), my next step would surely be to publish something which calls into question the conclusion they came to. This would cause everyone involved to start second guessing, loose confidence in the process, and make it easier to re-mount the attack either now, or in the future.

N.b. I assume this document has been written in good faith and with the best of intentions. It's just hard not to see some contradictions mixed up in there.

Anyone who want's an good read which features anarchism, I'd recommend "The Dispossessed" by Ursula Le Guin. It's an incredible story in it's own right, and has a very complete description of how a completely anarchist society might function.

> Just look at how we treat the planet and other living things in the presence of lawful order.

Law isn't a basis for morality, and there's a lot to be said for how present (capitalist, consumerist) systems promote un-sustainability, despite many on an individual level rejecting those systems.

> There are people who say that death is natural to which I think the response always has to be that there is nothing more natural for us than to fight death.

I think this is an excellent quote, but it doesn't convince me. Death is one of the only things we humans all have in common. It is the only great equalizer.

Unless every human is able to live forever, I will remain skeptical about a death cure being a good thing for humanity. Sure, you can argue about defeating death by degrees (e.g. extending a lifespan to 150, 200 years) but again, if it isn't available for everyone, I can't see that going well.

It's great that companies do this, but I wish that they would also open-source the verification infrastructure at the same time.

Otherwise, anyone who wants to use it in a commercial setting has to either re-do their own verification effort and due-diligence, or just trust the core works perfectly. Don't get me wrong, I trust IBM to build a working CPU, but that doesn't mean there aren't corner cases to be found when you put the core in a new SoC environment.

There is lots of open source HDL out there. We need re-usable verification infrastructure too!