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