> 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.
Yes, that is one aspect, and when the drafts was published you could see orgs started running (I've got a nice timeline in my slides). But I still find the haste interesting. There is very little time for the transitions compared to the adoption rate of other crypto standards. The NIST algos are imho still quite immature, which is one big motivation for hybrid schemes.
A bit off topic, as a European, what is happening with DOGE, slashing funding for CISA, TAA etc, I'm seriously worried about NIST. As you say, NIST is very important in many areas. For USA, with things like the coordintated universal time normal. But also for federal cybersec standards that have led to interop with the rest of the world cryptographically. Will NIST be slashed, and if so will the crypto department be spared? If not, what would remain? New standards, the validation program? Will Falcon become a standard, or for that matter the new lightweight symmetric algo based on Ascon? (For which I'm eagerly waiting for NIST to publish test vectors so that I'm able verify that my implementation is compliant.)
I think the haste is probably down to a risk calculation. If practical quantum breaks of classical crypto don't materialise in the next 5-10 years, "all" that's happened is we've cycled onto a new cypher suite sooner than we otherwise would have.
The reverse picture, where they do and we haven't, is so colossally damaging that it doesn't matter if the probability of quantum breaks landing is actually quite small. In expected value terms we still come out ahead.
You don't need to assume that someone in an NSA lab has already demonstrated it for this to work out, and you don't need to assume that there is ever a practical quantum computer deployed for this stuff. All you need is for the probability to be above some small threshold (1%? 5%? I could believe something in that range) to make running for the exits the right move today.
> Because the current plans aren't to migrate to just hybrid classical+PQC schemes, the plans are to migrate to PQC fully. Discarding both RSA and ECC.
This isn't true. NIST has been saying that, but everyone else just laughs and implements hybrid since throwing out RSA/ECC is so obviously stupid.
If you have references to nations, governments that state that transition to hybrid I would love to get references. The EU transition will not be hybrid. The NSA plan is not hybrid. ETSI is not hybrid.
My view is that IETF and commercial entities such as Apple, Google and open source world are the ones going hybrid. In this case I would love to be wrong.
That is a very relevant point. Add a bit of scare mongering, herd mentality and downplaying of the technical effects, risks, you get the ones setting policies taking a decision to transition - just like everybody else.
When I have seen time estimates, everyone is referring to Mosca's Theorem. This is the idea that "store now, decrypt later", combined with the estimated time until a working quantum cryptanalysis is feasible, and a finite transition time for existing crypto standards and technologies (think update times for long-living tokens like ID cards with certificates) makes the available delay until a change must start quite short.
> 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.
One reasonable way to do this could involve running the reference TPM2 simulator [0] on the Arduino. It's just a C library that already implements all the cryptographic routines and TPM2 commands. In fact, this is basically how TPM vendors implement their chips. They just generally have:
- A lot more hardening against physical attacks
- Cryptographic libraries optimized for their low-resource hardware
- (sometimes) a vendor certificate for a primary TPM key, aka an "EK cert"
Certainly a TPM running on an Arduino wouldn't have the physical hardware properties of a "real" TPM. But you could probably get it into a state with similar software properties.
It really depends on what your threat model is and whether you intend to use the TPM to begin with. If not, you really don't care about the security of any cryptography as long as the output is valid enough to satisfy whatever application is using the TPM.
Creating an adversarial relationship between the user and vendor is a
debasement of security principles. Now, Windows is the threat model
and that's why "mandating" this was the wrong choice altogether.
Microsoft could even have sold this as a feature. The fact that they
chose instead to push it on users tells you everything you need to
know about the future of users' relationship with their products. The
perimeter of my security ends where Microsoft begins.
It could be interesting in terms of debugging and reverse engineering. Seeing what secrets apps are storing. Normally you don't have full view on what's in your TPM as an end user.
Of course it'll be hard to make it really secure but production use isn't the only place this could come in handy.
How do you know it's _a lot_ of work? Correct me if I'm wrong, since you are implying you are familiar with this, but doesn't Windows 11 just want to verify that the device is available, likely with an echo facsimile along the lines of a version or self-test response? I don't believe any version of Windows requires full TPM functionality.
There are lots of good reasons to make cryptographic operations instructions instead of a memory mapped peripheral, but I prefer something like VIA padlock which implemented cipher modes instead of just implementing the round function as instruction. Any implementation could even trap those and implement them in a peripheral. The problem with memory mapped peripherals is that access to them has to be multiplexed and their state preserved by context switches. Specialized instruction on existing registers avoid this problem. VIA padlock solved it by piggybacking on the existing x86 REP prefix for interruptible string instructions and only cached the cipher round keys in the crypto unit reloading them from memory (or repeating the key schedule) after a context switch.
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.
That, and other operations requiring three input registers -- therefore a LOT of encoding space -- has been postponed to a possible future extension.
Full GREV and my lovely GORC have also gotten lost, though the encodings for the specific REV and ORC instructions that are included are upwardly compatible with the proposed general versions.
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.
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.
> 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.
That sounds like a pretty poor reason.
China could create the RISC-V SCE-China spec that extends RISC-V SCE with these, and call it a day, instead of requiring the rest of the world to waste transistors for something that's useless.
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.
> I'm sure Chinese manufacturers might feel the same about NIST standards.
Don't count on it. For example have you ever wondered why there isn't a Russian Certificate Authority trusted in the Web PKI? There's no market for one. If you're a Russian, you can see that a Russian CA is obviously subject to control by Putin, which even if you like Putin today doesn't seem like a perpetually great idea, so you would choose some European CA instead. And if you're not a Russian you clearly don't want to trust this CA.
Now, there are some Chinese CAs, but it's again interesting that they're not popular in China. China has a huge population, plenty of potential customers, but somehow even though there is more than one CA in China, very few certificates between them. Similar to the number issued to the Government of Spain (not all companies in Spain, just their government). Same reasoning. Even if I think Xi Jinping is great and I'm a proud Chinese national, a certificate from the US or Switzerland seems like a better choice.
The Americans fall far below the lofty moral standards they set for others [in the other room is my redacted copy of the Committee Study of the Central Intelligence Agency's Detention and Interrogation Program, grim reading about American torture even though much of what the senate were shown is redacted], but only at your considerable peril should you would mistake that for meaning their cryptography is no better than whatever home grown offering has been chosen in your country despite their billions spent and their expertise in this domain.
Nobody uses those, either, except possibly as required to interact with the cursed government PKI (about as cursed as early 00s EU government PKIs... are those still around?). Also maybe the government people with clearances, but the less said about them the better. But that’s mostly network effects, frankly, not trust. (Nobody uses Camellia, either.) Trust issues as described by the GP do exist but mostly factor into choosing domain names, registrars, hosting, and such.
But China, unlike Russia, does have an internal technological environment meaningfully separate from the world at large. It may also be trying to cultivate an ecosystem of private government contractors, which the intense criminality of Russian government procurement doesn’t permit. (China also has a general-purpose IC fabrication industry worth a damn, whereas for Russia the equivalent question is in any case largely moot.)
My quick summary of sm3/sm4 is:
- sm3 is pretty trivial to implement
- sm4 is about 1/16 the complexity of the spec's aes implementation (one box lookup per clock rather than 8 and no inverted version)
So if you want to court the (giant) Chinese market it's kind of a no brainer
> 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.
Certainly! As you can probably tell from my comment I'm not expert and I found it easy to follow.
I just wanted to post a summary for anyone who is interested but doesn't find time to go into details. I know that I myself often read this site on phone and I appreciate similar comments giving a tl;dr on more complex stories.
> 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.
Maybe I phrased it poorly but section "4.2. Entropy Source Requirements" states: "An implementation of the entropy source should meet at least one of the following requirements sets in order to be considered a secure and safe design". It then gives three options, one of which ("4.2.3 Virtual Sources: Security Requirement") states "A virtual source is not a physical entropy source" and "A virtual source traps access to the seed CSR, emulates it, or otherwise implements it without direct access to a physical entropy source.".
My interpretation is that there is indeed a single interface (CSR) however the hardware implementation could be both real physical entropy source or a CSPRNG. And presumably the latter is more likely on low-end devices.
> My interpretation is that there is indeed a single interface (CSR) however the hardware implementation could be both real physical entropy source or a CSPRNG. And presumably the latter is more likely on low-end devices.
A CSPRNG doesn't do anything without a seed. If you're actually a VM, your host provides the seed (the "virtual source"), which it chose randomly, and since it is actually your host anyway it has no particular reason to give you a bad seed versus just doing whatever else to sabotage you, so you have to assume the seed is good.
In contrast on physical hardware, there is no seed. If you've got a way to provision genuinely random data to the physical CPU, you don't have a "virtual source" at all. So option 4.2.3 isn't relevant to physical CPUs only to a RISC-V VM.
Because RISC-V wasn't ready yet, and still isn't ready. Ecosystems matter. But the ecosystem sure seems primed for massive growth, and there's no architectural reason why RISC-V can't perform as high as ARM and beyond.
> 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.
Did a quick search on this, and I believe the Linux portion of this is the responsibility of the "UNIX-Class Platform Specification Task Group" [1]. They seem to be quite active, which I'm reading as a sign things are progressing.
I think probably "moral" in the sense that it's not considered your fault to have type 1 diabetes. Type 2 is brought on by poor diet and exercise so it is the "immoral" version.
Though I think the science on what drives hunger cravings and "willpower" and fat storage this leading to obesity is still in its infancy.
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...