Sophie Schmieg
Has anyone done a macroeconomic analysis of the costs of the PQC migration?
It seems hard to estimate, but it feels like a number with way too many zeros after it.
Feb 10 at 6:22pmWeb
Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Feb 10
@sophieschmieg I suspect you probably can’t for another five or more years. The push to do TLS everywhere drove things like AES hardware in CPUs and TLS offload and termination in NICs. It’s still consuming more power than not doing it, but the power cost now is much lower than it was before all of this, so I wouldn’t be surprised if it ended up being a net saving. At the moment, only a handful of folks are looking at hardware offload for PQC and it’s not clear to me if there will be additional benefits from the hardware people are building for it (it may just be cost).
Show threadbalooFeb 10

@david_chisnall @sophieschmieg I don't believe there is any benefit of hardware offload for PQC.
PQC is only used for key agreement or signature, which is a very small part of a TLS flow. Encryption is still going to stay AES or Chacha.

I believe this was meant for the amount of (human) work required to prototype, collaborate, specify, certify and deploy.

To be honest, the most problematic portion at the moment is the lack of support for secure storage (HSMs, TPMs, yubikeys, ...) of PQC private keys. And this won't happen for a little while.

Show threadbalooFeb 10
@david_chisnall @sophieschmieg Add on top of that the problems created by the current US admin when they cut jobs at NIST (which costs every more _time_ for everyone)
Show threadSophie SchmiegFeb 10
@david_chisnall @baloo yeah, I think hardware offloads are not the most interesting aspect of the solution here. Roughly speaking, the cost falls into two buckets, the engineering cost and the operational cost. Both currently have huge error bars on them, especially since the operational cost is mainly in bandwidth, which is much harder to model cost for when compared to compute. Add to that that you can partially trade off operational costs with engineering costs and you get something you need to have an engineering degree and an economics degree to do cost modeling for.
Show threadbalooFeb 10

@sophieschmieg @david_chisnall I mainly work around code-signing use-cases. The larger signatures are definitely hard to retrofit in existing systems.

This is a major engineering cost for us.

Show threadbalooFeb 10

@sophieschmieg @david_chisnall That and CPU vendors doing their own thing because why not.

Out of every solutions out there, they made an effort in picking the worst one.

Show threadFarce MajeureFeb 10
@baloo @sophieschmieg @david_chisnall I mainly deal with code-signing use-cases, and PQC is a huge engineering effort for us as well. But also, system vendors are going to feel the pain of larger flash parts quite acutely.
Show threadSophie SchmiegFeb 10

@baloo @david_chisnall @vathpela but, but, but code signing is supposed to be the easy part 🫠. No seriously, compared to identity and pki, code signing has so much fewer constraints.

I guess other than firmware signing, that is also really hard.

Show threadbalooFeb 10

@sophieschmieg @david_chisnall @vathpela I don’t know. You still need key delegation and revocation to do it proper. Either fully custom or an x509 pki. There are less constraints than webpki for sure, but still doesn’t feel quite easy.

I can’t wait for the dnssec folks to chime in. This is going to be so much fun over there!

Show threadFarce MajeureFeb 10
@baloo @sophieschmieg @david_chisnall Well, for Secure Boot, revocations are handled through a completely separate mechanism, so that's not so bad. Except for the space constraint, which again is about system vendors springing for flash space - though these days we mitigate that significantly in the OS as well.
Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Feb 11

@sophieschmieg @baloo @vathpela

I’m mostly interacting with this stuff from an embedded perspective. We’re looking at using ML-DSA for code signing. The RAM requirements are quite high and the signing takes longer than the hashing, but it’s still only on the order of a few million cycles, so completely fine if you build a secure update flow rather than a secure boot one. We’re mostly wondering if we can get away with just the post-quantum schemes, because the code size of having to do both is annoying.

FIPS205 looks incredibly hard to run on embedded devices at all, let alone without side channels. We’ll see how that goes.

EDIT: To slightly return to my original point, if FIPS205 makes hardware floating point (especially constant power-and-time hardware floating point) a table stakes feature for microcontrollers, this may end up being a net positive overall.

Show threadRobert BanzFeb 10
@sophieschmieg Like, would it be cheaper to buy out all of the Quantum compute IP and bury it?
Show threadSophie SchmiegFeb 10
@target I'm almost certain it would be. Unfortunately it's hard to buy out all of them.
Show threadstefanFeb 19
@sophieschmieg you are afraid its so hard or so much money is wasted?