Post-Quantum Deployment: Insights from Google, Cloudflare, and Formal Methods | RWPQC 2026, S6

Hinzugefügt: 2026-06-03

[00:00:05][music] >> Our next speaker is Sophie Schmeig from Google. She where she leads the information security engineering team and she's going to be giving us an update on the Google Cloud or Google's post-quantum crypto migration.

[00:00:19]Please welcome Sophie.

[00:00:22]Okay. [applause] Um yeah, welcome to the uh pre-lunch session, I guess.

[00:00:31]Um I'm going to give a few updates on Google's PQC migration. Um I'm going to keep this fairly high-level.

[00:00:39]Um I think I've used this slide, I don't know how many times now, uh but it's a good slide, so it's uh one well worth recycling.

[00:00:47]Um basically, uh my point is that uh um we can roughly divide cryptography in in sort of four areas of asymmetric encryption, digital signatures, symmetric cryptography, and what I like to call fancy cryptography, which since has caught on, which is one of my proudest achievements in uh the field.

[00:01:10]>> [snorts] >> Um if we take a closer look at these four fields, then the the actual um situation looks more like this.

[00:01:20]Um basically, we have asymmetric encryption uh used with fairly few stacks.

[00:01:28]Um where fairly few still can be a lot, but at least it's not uh a lot of very different uh protocols or something like that. Like, you can still sort of count them. Um uh but uh on the flip side, it's vulnerable to stoneware decoupler, so it has this nice property that you kind of want to go fairly fast on this.

[00:01:52]Um then we have digital signatures, and digital signatures are uh kind of the opposite of asymmetric encryption here.

[00:02:00]Um they are used in uh a lot of very, very different use cases. These use cases can be very complicated to to migrate. We will talk a little bit about that later in the slides. Um and at the same time, you don't have the stolen identity calculator threat. So, my point has been since pretty much forever that while asymmetric encryption is urgent, it doesn't mean that we can completely ignore digital signatures because of this complexity [snorts] just meaning that uh the migration takes a lot longer than it does for um uh for asymmetric encryption, and so it pays to start early for those as well just because uh you don't necessarily know where uh your journey takes you. Um for how often I use this slide, I uh should learn at some point that uh when I print them to PDF, uh it loses these emojis that I put on the symmetric cryptography thing. They're supposed to be little shields on there to like showcase that symmetric cryptography is not really a concern. If it was a concern, um we would be in really, really deep trouble. Um even if we just had to migrate everything to 256-bit, uh it would be way, way, way more difficult than anything we have to do with asymmetric cryptography given that symmetric cryptography is like even more widely used than uh digital signatures in uh pretty much every single instance, and migrating symmetric cryptography is not something that I would look forward to. So, I am very happy that symmetric cryptography, at least for now, is not considered vulnerable to quantum computers even if it's only 128-bits.

[00:03:47]Um lastly, fancy cryptography is um uh rather complicated story, um, as you might imagine from basically the, uh, everything else category, uh, some protocols have, uh, post-quantum equivalents. There are some post-quantum, uh, Pakes. There are, you can relatively easy create a post-quantum short authentication string message, um, if you look at like, um, fully homomorphic encryption, then you will find that that is like post-quantum by default because you need, uh, an, uh, lattice scheme for that to begin with. So, um, fancy cryptography is a fairly, like, different space where there are some things that basically exist and some things where we don't even know what the alternative would be. We heard yesterday from Signal's talk that, like, even for, like, uh, some of the, uh, less fancy fancy parts of the, uh, handshake and and group metadata protections, they have some trouble actually finding the corresponding primitives in in PQC land.

[00:04:57]And if they exist, then, uh, there's like often times a lot of deep literature analysis that you need to do to like figure out if it's secure, whether, like, enough people have looked at it, and so on.

[00:05:09]>> [snorts] >> Okay, um, with that, uh, now to the updates from, uh, like, uh, compared to what I talked about last time.

[00:05:18]Um, I've talked, uh, a long time ago about, uh, our efforts to, uh, roll out PQC on our internal production, uh, traffic, uh, traffic.

[00:05:29]Um, that has happened a long time ago. I have written here 2023. Um, if you, uh, are on top of the NIST process, you might realize that this is before, uh, NIST standardized ML-KEM. And so, this wasn't using ML-KEM, that was using, uh, NTRU HRSS.

[00:05:47]Uh, we have since moved it to ML-KEM because we like using standards more than other things, but that was something that was fairly straightforward for us to to do fairly early on.

[00:06:00]Mostly because it's internal, so we own all sides of the of the transaction or the transmissions, so we could move fairly easily with the the infrastructure that we have.

[00:06:14]Um, next, the the TLS consumer-facing encryption in transit. Um, we started there with the Kyber draft and then once the actual ML-KEM standard came out, we updated Chrome to um to ask for ML-KEM and on our server side, our load balances for consumer-facing load balances have been talking ML-KEM ever since.

[00:06:43]Um, and I think Bas in the next talk will talk more about how deployment looks like.

[00:06:49]Because Cloudflare sees a lot more varied traffic than we do in this case.

[00:06:54]So, yeah, stay tuned for that one.

[00:06:58]Um Next, SSH, mostly in the form of OpenSSH, did migrate relatively fast to the point as like was remarked yesterday that they were at this point now warning if your server doesn't support a post-quantum algorithm. I think that is something where with browsers we're still very very far away, like actually starting to have like warnings and interstitial interstitials for non-PQC websites. I don't know when we get to that. We will see a lot more adoption before that is feasible, but with SSH, apparently it was a lot more feasible to move to do a lot faster and so OpenSSH did, and I'm very happy about the fact that like it's actually warning you if you're not PQ, which is kind of cool.

[00:07:49]Um Uh uh last um is our customer-facing encryption in transit, so cloud uh cloud APIs in particular.

[00:07:59]Um those were lagging behind the consumer-facing parts because uh we didn't want customers to adopt like pre-standard algorithms, and we wanted to be a lot more careful with rolling things out to customers because if you break them, they tend to get fairly mad at you. So, uh we tried to be very careful with that, and uh we have now rolled them out uh also for our load balancing pro uh product. Um it's always nice to to see that like we have like our internal infrastructure has upsides and downsides. One big upside is like we have a mono repo, we have like one single code base that defines how code balancers how load balancers look like.

[00:08:44]So, we had to update one single part of our repository, um and then wait for the roll out to to have this done.

[00:08:52]Uh this is very nice because I can make green check marks behind uh customer-facing encryption, uh but it also has the downside that it uh doesn't really allow me to uh differentiate for individual APIs. I can either have all of them or none of them.

[00:09:07]So, um there are upsides and downsides in this. Uh in this case, I'm very happy that we are now uh finally at the point where uh customer-facing encryption in transit uh with TLS is also um at uh a good place.

[00:09:21]>> [snorts and clears throat] >> Um lastly, uh there's a long tail, and the long tail is quite long.

[00:09:27]Um To understand the next few slides, uh you need to know about the concept of react shaving, and as I discovered yesterday with a representative sample of cryptographers, uh was a bit mixed on who knew what it was and what is or who didn't. Uh the concept of yak shaving is uh when you have a task and then you have another task that you need to complete before you complete that task, and then you have to another task that you need to complete before you can complete this task, and then you complete this task, and so on and so forth until, as the legend goes, you find yourself in South America shaving a yak because that was needed for some furthering of one of these projects.

[00:10:09]So, uh let's look at an example of this long tail. Um and this is the uh the attempt or like our efforts to roll out uh X25519 and ML-KEM-768 for our corporate TLS environment. So, like not the production network, but the network that like uh uh employees use to talk to Google services.

[00:10:30]Um Uh uh something that seems at first completely unrelated is that Windows DirectAccess only supports RSA.

[00:10:40]Most of our machines are Linux and Macs and uh Chromebooks and so on, but there are some Windows machines because like someone has to build uh Chrome for Windows, and every time I boot up my gaming PC, I'm very grateful for their sacrifice.

[00:10:55]Uh but it turns out that Windows DirectAccess is something that only supports RSA, no ECDSA.

[00:11:01]Um the next thing that like kind of starts looking like a pattern here, but that like also still has literally nothing to do with uh PQC is that back when the TPM 2.0 spec first came out, there was a mistake in the specification of the RSA-PSS um uh a specific uh algorithm, and it turned out that like uh HSMs who followed the TPM spec created signatures that had a salt length that was not compatible with RSA PSS usages from other protocols. So, certain TPMs that were early on implementing the spec produced invalid RSA PSS signatures.

[00:11:46]Okay, slowly we're getting to the point where where all this yak makes sense. Um the next point to observe is that TLS 1.3 only supports RSA PSS for client certificates.

[00:12:00]Um and additionally TLS 1.3, as we learned yesterday, is the only protocol is the only version of TLS that PQC is being added to. Earlier versions don't have PQC support.

[00:12:16]>> [clears throat] >> And now we're starting to converge on something that makes sense in that we, like, sure, it's not the best security posture. We We used credentials between TLS and direct access. That being said, identity is hard.

[00:12:32]It happens. But to, like, the the against this, we did put these credentials in hardware security modules, as you're supposed to do. So, they were stored in TPMs. Um and now you can see how this whole line of yak beautifully lines up and gets shaved to to block um X25519 ML-KEM uh by because of RSA PSS support for client certificates that we don't even want to be PQC at this point in time. Like, just the the ephemeral encryption transit. But the RSA PSS support that was messed up in certain TPMs leads to not being able to roll this out smoothly.

[00:13:21]>> [clears throat] >> Okay.

[00:13:23]Um next we talk a little bit about signatures.

[00:13:27]Uh the updates there are a lot sparser as you can see.

[00:13:31]Uh, the biggest one that I can announce is that Cloud KMS rolled out support for digital signatures in 2025.

[00:13:40]Otherwise, we did some prototyping with MTC. There's blog post that Chrome put out in I think last week. There will be a talk at IWC on this as well.

[00:13:52]Um, MTC is currently in the early prototype stage. It's very promising technology to attempt to like reduce the overhead of um uh, uh, of post-quantum [snorts] signatures and while we're at it also fix certificate transparency because why not?

[00:14:12]Um Otherwise, there were some limited internal deployments but nothing that I really can even talk about because it's not very interesting.

[00:14:21]So, what is the difference here?

[00:14:24][clears throat] Um we can see that ML chem deployment is going fairly well and if you look at like what the larger internet does this kind of is mirrored that like encryption is actually getting somewhere. Signatures see like while there is a long tail, signatures seem to still be difficult. The main reason for this is the key management. It's not It's not a random that like the one large thing that I can talk about and point to that launched PQC signatures is Cloud KMS.

[00:14:56]Cloud KMS is very nice because the key management is someone else's problem.

[00:15:02]It's the customers who have to decide what they do with these keys. So, it's much easier to roll this feature out there because well, I don't do the hard part of this. I don't have to update any keys anywhere.

[00:15:15]That is someone else who wants to use this product who needs to do these things.

[00:15:22]It kind of shows that like going back to this very earlier point of how signatures can be much more complicated.

[00:15:30]The reason here is really because key management is difficult.

[00:15:35]Okay.

[00:15:37]Next to a topic that I wanted to talk about about of emergency planning for quantum computers.

[00:15:46]If you're being surprised by a quantum computer, you have a business continuity risk.

[00:15:52]If the quantum computer is there before you expected it, you have a problem.

[00:15:58]Especially when you compare that to these long signature deployment timelines where like even though we are years in the like as far as I know both Google and the rest of the industry results on where signatures are deployed is fairly mixed record with maybe the exception of firmware signatures. So these long deployment timelines need some special considerations in case of any emergency scenario.

[00:16:24]So let's look at two different emergency scenarios that could happen.

[00:16:29]The first and arguably way worst possibility would be a quantum zero-day where sort of out of nowhere a quantum computer appears and starts breaking stuff.

[00:16:42]The biggest problem about this is that this is almost impossible to detect.

[00:16:48]It's very difficult to distinguish a quantum computer from just keys being compromised via like someone abusing memory problems or something like that. The The only thing that kind of points to a quantum computer is that the um that the compromises are kind of unrelated.

[00:17:10]And that means that when you detect it this quantum computer has likely already actively exploited things for quite some time, so this is really the worst case scenario that I can imagine for any quantum migration, and I really hope that it not doesn't come to that.

[00:17:27]Um, the other more likely scenario is an unexpected timeline slip. Like we heard a lot about 2035, but what if like physicists start making statements that suggest a way earlier timeline than than what we've so far expected.

[00:17:50]The biggest issue here is that it is rather difficult to distinguish the the signal from the noise. Um, physicists will make statements, and some of them will be trustworthy, and some of them will be mostly hype to get more grant money, and distinguishing which one is which is one of the more difficult aspects of the scenario.

[00:18:13]Um, and here as well, similar to the zero-day, the only thing that we can talk about is the public timelines, and threat actors might actually be farther ahead than that.

[00:18:26]Um, there are some threat model implications in an emergency scenario.

[00:18:32]Interestingly, the these implications mostly depend on what kind of quantum computer gets developed first, whether it's something that is easy to replicate and make fast, or whether it's something that is rather slow or or hard to add new machines.

[00:18:52]If it's a fast or many CRQCs, then a threat actor is most likely to focus on decryption of stored traffic.

[00:19:02]Stored like decrypting stored traffic is like stored now or decrypted later attack.

[00:19:07]It's undetectable because it's a completely passive attack.

[00:19:11]Threat actor doesn't want to give away that they have this advantage, so they will do that. Um yeah, not directly detectable. It's similar to like the World War II situation with Enigma where like uh the threat actor is now in this position where they want to not leak the fact that they have access to uh a lot of um enemy intelligence.

[00:19:30]Um on the other hand, if you have fewer uh CRQCs or slower CRQCs or both, um the threat actor will be forced by the fact that TLS uses ephemeral keys to focus on single powerful keys.

[00:19:48]Um at some point, if you can only decrypt so many keys, uh it doesn't make any sense anymore to um like try to do store now decrypt later uh because you need to have you need to use your quantum computer to the fullest.

[00:20:02]Um that means that the likely targets uh include, at least from public infrastructure, includes CAs, uh certificate transparency logs, and identity providers uh and uh their corresponding keys.

[00:20:15]Um this is a scenario that is difficult to detect, but not impossible to detect directly. Difficult because like they have a CT log bypass. They can forge uh um certificate uh transparency inclusion uh messages. So, they can bypass the biggest thing that keeps web PKI secure, but by doing this, they do expose themselves to a slight risk of detection because uh like you could see that it never shows up in the CT logs.

[00:20:48]Um they likely would only uh use this against certain high-value targets uh to not uh make that super likely.

[00:20:56]Um conclusions of this section uh it can be a very good idea to do some business continuity planning and include PQC uh into your emergency planning cycle. Um the signature deployment in an accelerated timeline uh becomes uh like very different from the normal timeline in that suddenly it can be the highest value target to go after especially since um uh uh we already have a lot of deployment of ML-KEM as uh for uh encryption in transit.

[00:21:34]Um and as a last point uh it is very hard to detect that you are facing this threat, so um there will be a lot of confusion around uh this as well.

[00:21:46]Um and with that, I would like to thank you and open it for questions.

[00:21:51]>> [applause] >> Thank you. Uh any questions for Sophie?

[00:21:59]Ah.

[00:22:07]So, what are you all at Google doing uh differently with your migration being that you have like quantum computers?

[00:22:14]>> Um I don't think we do anything differently. Like I don't think our quantum computers are doing anything to migrate anything.

[00:22:22]>> Like like internal testing, you know, you don't have to go to a agency to test your >> no no, we don't really do that.

[00:22:29]>> Okay. Thank you.

[00:22:32]>> Um as upstream implementers, we're using 2035 as the uh the timeline that we were expecting.

[00:22:40]Your emergency planning timeline does not have years. Do you have reason to believe 2030 2035 is not what we should be targeting?

[00:22:49]>> Um I cannot comment on that.

[00:22:55]>> Yeah.

[00:23:00]>> I think a quick question on jot tokens and Jose.

[00:23:04]Is there any progress from anybody really trying to work I I know there's some draft IETF stuff, but like do you know if if you guys were like any further along on trying to get that stuff to be PQC?

[00:23:16]>> That is like the the identity part of things and that is fairly tricky. Like yeah, there's this draft in IETF. That is the that is the necessary condition to do anything with JWT. You need to first have them, but once you have them, you have a lot of problems with like these things are way larger than anything that JWTs are used for.

[00:23:36]Like you cannot put them in a URL, you cannot really put them in a cookie. You have a lot of problems deploying these things.

[00:23:44]I think in a lot of cases, you need to look at whether you actually wanted to have an asymmetric JWT to begin with or whether a symmetric one actually does the job just fine. Just given how the symmetric one, yeah, it has a more complicated key management story. Yeah, verification now requires um like access to secret information, but uh on the flip side, you basically have zero problems with size.

[00:24:09]Um there will be cases where this is possible, there will be cases where this is not possible. I hope to have more to say at next RW PQC because at the moment, I can't really say I have much experience with trying to get identity tokens to to PQC.

[00:24:27]>> Uh it was kind of a throwaway line, but uh you mentioned that uh Merkle tree certificates also fix one of the major problems of uh uh certificate transparency. So, just wondering if you could expand on that, maybe uh exactly what you're referring to.

[00:24:40]>> Yeah, uh so the biggest problem with certificate transparency logs, in my opinion, is uh these signed certificate transpa- transparency inclusion messages.

[00:24:50]Uh Merkle tree certificates, because it's already using Merkle trees, if you use the correct designs, uh will basically include the certificate transparency lock in your issuance of a certificate and have the CT lock proofs immediately as Merkle tree inclusion proofs instead of as signatures, which is the thing that you really want in a in a transparency lock. You want to have a transparency inclusion proof. You don't want someone promising that they will add it to a transparency lock.

[00:25:27]Yes.

[00:25:29]>> You mentioned for the key agreement migration for TLS SSH and some other places. I think all those are hybrid with maybe a couple of exceptions for non-hybrid PQ. What about your signatures? Are you looking hybrid or not hybrid?

[00:25:44]>> So, yes, for TLS and encryption transit is pretty much everything is hybrid. For signatures, it's a more difficult story because it's like you can make a lot stronger argument not as necessary for signatures.

[00:25:59]At the same time, it's still like a question of like how cheap is it to add this hybrid. If it's cheap, then you get to this question of like why don't you add it? So, you still have like some cases where you will add hybrids, but you will certainly have more incentive to maybe not do a full hybrid when it like is not something that you want to afford.

[00:26:28]>> Reportedly, you guys are also enabling ML-KEM-1024 non-hybridized in some situations. Is it really a concern about the security margin? You're worried more about the degradation of 768 to insecure, but 1024 remains secure, or is it just that you sort of are up against you know having to do it, so you may as well do the strongest one you can.

[00:26:49]>> Yeah, we're serving the federal government in some cases. Federal government wants this so yeah, that is the main reason that it's there. I have no reason to believe that 768 doesn't have enough security margin.

[00:27:01]>> Right. So, basically I'm guessing that if you're if ML chem fails, it will probably fail across the board, right?

[00:27:08]Catastrophically, not just degradation by small amount.

[00:27:11]>> a lot on how it fails. If it's like just degradation like if basically it's just because that better like we had in the talk before the break, then you would likely still have 1024 be secure, but there is a lot of security margin that we already get from having 768. Like 512 is much closer to the sun. I don't see really a reality where we just improve BKZ until 768 breaks, but 1024 is secure. But yeah, it could be a catastrophic break and then all bets are off.

[00:27:50]>> Any any last question?

[00:27:54]Okay, let's thank thank Sophie again.

[00:27:58]>> [applause] >> Our next talk is from Bas Westerban from Cloudflare where he leads their PQC initiatives. So, he's going to be giving us an update on their migration to PQC and their and their certificate strategy.

[00:28:11]Please welcome Bas.

[00:28:15]>> [applause] >> It's only March. Okay.

[00:28:21]Um So, Sophie already did quite a bit of preparation.

[00:28:27]So, thank you.

[00:28:30]Sophie already did quite a bit of preparation, so I don't have to explain the basics.

[00:28:35]Let's look at how far we are with key agreement on the web.

[00:28:40]Um 2025 was a great year.

[00:28:46]It landed in many platforms and libraries, uh, notably OpenSSL 3.5 enabled by default, iOS, macOS, and many many many more.

[00:28:59]But, of course, it takes some time for these updates to roll out.

[00:29:03]And let's let's see how far we are.

[00:29:06]Um, so Cloudflare has a quite a lot of traffic, so it's easy for us to see what clients support, which is browsers. And if you look at clients which we believe are not bots, then we are already at, uh, 65% of all traffic using, uh, uh, X25519 and ML-KEM-768.

[00:29:26]>> [clears throat] >> Uh, if you look at bots, which is more likely not to quickly update their software, then still it's not not 20%, it's 30%, not bad. Not bad.

[00:29:41]And they get they they don't probably don't care about this that much, but they get it for free when they do a software update.

[00:29:48]Uh, and if we look at the support overall, then it's already about 50%.

[00:29:52]So, that's I mean, that's great, but um, oh, sorry.

[00:29:59]Um, that's great.

[00:30:01]Um, but that's that's for clients.

[00:30:03]That's one end. Of course, we also need to know about servers.

[00:30:07]Uh, so, Jan Schaumann had a had a look, uh, just last month at the top 1 million websites, and he saw that about 41% supports uh, ML-KEM.

[00:30:21]And this is great. It is it's it's up from 28% in 2025.

[00:30:26]Um, but that's the public accessible web. A lot of servers are behind, uh, for instance, CDN.

[00:30:34]Um, so so, this direct talks to a CDN, and then this CDN connects to the origin, the customer origin. And if we look at our customer origins, then supporting PQ is it's it's only about 8 10%.

[00:30:50]Which is not great, but it's up from less than than than a percent less than a tenth of of a percent actually just last year.

[00:30:59]So, this is it's nothing to scoff at that we're at 10%.

[00:31:04]And and the 65 of course is a better number, but it's not 95%, right?

[00:31:10]We can't celebrate until we're at 95 or or or higher.

[00:31:16]And that will take many many years.

[00:31:20]Um so, what can you do today?

[00:31:24]Well, a lot of software is supported, some doesn't, but if you just keep your software up-to-date, you'll get it.

[00:31:31]Um you should check your configuration.

[00:31:34]So, unfortunately, TLS libraries typically expect you to configure ciphers manually. Like for instance, here is an Apache configuration where you configure the the the key agreements. And this is actually um uh an example configuration from Trustable website for modern configuration. Like we're disabling everything except for TLS 1.3, very modern, very nice.

[00:32:02]Picking the right key agreements. But because they didn't include post-quantum because it didn't exist yet when they wrote this example configuration, people that tried to do their best and get the best configuration, a modern configuration, they accidentally disabled post-quantum now. So, the people that don't didn't care just didn't configure anything, they get PQ by default now with an update.

[00:32:25]But those that tried a bit more, they got there.

[00:32:29]Uh they didn't get PQ yet. So, well, what can we do?

[00:32:35]Config We need better automatic configurer better configurations. We should configure intent in in the instead of actual ciphers, but that's not something we can solve on the on the short timeline.

[00:32:51]Okay, so that was key agreement, making good progress.

[00:32:56]Uh let's look at deployments of post-quantum certificates but of the on the public web.

[00:33:09]Um There are plans though. There are plans.

[00:33:12]So, uh uh Sophie touched upon uh Merkle tree certificates already and there's an aggressive timeline there. Uh it's already uh we're running a a feasibility experiment. So, it's right now in Chrome. The code is already there. You can turn it on. Uh on in in beta it's turned on. Uh uh and Chrome plans to accept the first proper CA and starts plans accepting proper production Merkle tree certificates at the start of 2027.

[00:33:38]Um Alice is uh uh being standardized at the at the IETF at the plans working group. So, if you're interested, go go have a look there.

[00:33:49]Um So, uh Wednesday, uh my colleague Luke is giving a talk about it at RWC. So, I don't want to spoil spoil his presentation, but I do want to mention one thing about it.

[00:34:06]Um is that uh MTC has two main objectives. The the the first is getting uh uh small getting post-quantum certificates small, so there's no performance degradation. That's the first. And the second is to make post-quantum certificate transparency viable, which is very important.

[00:34:25]Uh there's actually two kinds of Merkle tree certificates.

[00:34:28]There is uh standalone Merkle tree certificates. They are big.

[00:34:32]Uh and they don't have the performance improvement.

[00:34:35]But, it's quite easy to add support for them in libraries. So, it's just a TLS library update to be able to to support them.

[00:34:43]Uh that's not a big lift.

[00:34:45]To get the performance benefit, you need a bit more. It requires a bit more work, a bigger change in how certificates work. You need to have some kind of uh out-of-band updates to get landmarks.

[00:34:56]Wednesday when they go to the talk to see that. I just wanted to mention that that to get started with it, uh to get some support with it, not necessarily performance support, is not a big lift.

[00:35:09]Okay.

[00:35:12]Um I I want to um mention that certificates are going to be harder. Uh so, this is not specific about about the public web. This is about at if organizations do it themselves. If you want to enable key agreement, then basically there's only one or two steps.

[00:35:29]You need to first have the software support on the client and the server, and then you need to turn it on on the client and the server. Doesn't have to happen at the same time.

[00:35:38]You can do it uh uh whenever it it is convenient.

[00:35:44]And you can do this all in two in one go in one push.

[00:35:47]Um and then the second part, which people usually forget about, is that um once you have upgraded it, all secrets you've sent over the connection that could have been um uh uh uh that can be decrypted in the future, they you need to roll them. Uh access tokens, passwords, maybe you've transferred private key over a connection. All of them have to be rotated.

[00:36:10]So, it's just two two phases only.

[00:36:15]Um certificates are more complicated.

[00:36:21]All right? Because you need to have software support on client and the server, but you also need software support on your certificate authority.

[00:36:30]And not written here, but software support on everything that where certificate passes through. So, each of these things have to be done. They can be done in parallel. That's That's good.

[00:36:41]Uh then you need to enable support. Uh uh sorry, yeah, enable support, yeah.

[00:36:47]And then you need to to first create a PQI. You need to create a a root certificate, which a PQ root certificate. And once you have done that, you can install these the you can start issuing these certificates on servers.

[00:37:02]And to clients. Another thing is in most cases you cannot upgrade everything at the same time. And if you can't upgrade everything at the same time, you need to have servers that support both PQ and non-PQ certificates. So, you need to update your server to support installing multiple certificates.

[00:37:18]And on clients, although for browsers it's the case that you they it can they are configured to trust multiple CAs.

[00:37:25]There's a lot of software out there that's can only be configured to trust one CA. So, you also need to update your clients to be able to trust at least two CAs, one PQ and one non-PQ.

[00:37:37]And that is not all, because we're all talking about adding PQ support, but it's not safe until we also turn off non-PQ. Otherwise, there's a downgrade.

[00:37:44]I will talk a bit more about that.

[00:37:47]And once that is all said and done, and this happens before the arrival of a quantum computer, you're done. But if we're finishing up things after the quantum computer arrived, after this is all said and done, we still need to rotate all the secret access tokens, passwords over the connections that could have been affected.

[00:38:05]This is annoying enough if you control all of this yourself.

[00:38:08]Uh if if part of this is at a different organization, uh and if coordination, then this is this is quite a lot of work. It's not just one push.

[00:38:16]It's multiple pushes that need to be coordinated.

[00:38:21]Okay.

[00:38:23]Um so that's another remark. So now I I would like to go into downgrades.

[00:38:29]Um So if you have a system where you can control both ends at roughly the same time, then you can just turn EQ off. But there's lots of federated systems like the web PKI where it's inconceivable that we we we upgrade everything in time for everyone.

[00:38:49]It's also inconceivable that we turn off that we break the devices that are not upgraded yet.

[00:38:57]So we will need to support both post-quantum non-legacy clients and we need to continue to support legacy servers.

[00:39:05]There's a difference there between the two, so it's important to stress.

[00:39:08]So a legacy um So a legacy client a so so a so a legacy server will only have a legacy certificate.

[00:39:19]A post-quantum server, so with an upgraded server, will have a legacy certificate to support legacy clients and a post-quantum certificate for post-quantum.

[00:39:28]The legacy certificate there doesn't matter for a for a post-quantum client because a post-quantum client will not ask for the legacy certificate, it will ask for the post-quantum certificate.

[00:39:38]>> [snorts] >> But there's also so that's one. That's what people typically talk about. But there's also the case where you have a legacy server. So a server that cannot sign with a post-quantum key.

[00:39:49]In that case, a upgraded client needs to be able to accept the the the the the legacy certificate of a legacy server.

[00:40:00]And there is a downgrade problem there.

[00:40:03]Because an attacker, if you try to connect to a post-quantum server, an attacker in the middle can say, "No, no, no, that server is a legacy server. That doesn't support PQ." And it will serve you legacy certificate instead, which can be forged.

[00:40:17]Uh Uh I asked Klaus to make an image, which is probably easier to solve. So, this is the case of a legacy client. It will just go to the legacy certificate and it will get the classical certificate and the classical from the PQ server, and that's vulnerable, but it isn't harmed. This is I mean at least at least it keeps running. It's not secure, but I mean sometimes availability and often availability is more important than not than than security if if you can't upgrade them.

[00:40:44]Now, post-quantum uh if you have a post-quantum client that talks to a legacy server, well, nothing we can do that is insecure.

[00:40:52]If a post-quantum client talks to a PQ server, it will negotiate the PQ certificate, which is great, which is secure, except the case that an attacker can claim that the post-quantum server is in fact a legacy server and will thus be able to have the client the PQ client accept a legacy certificate.

[00:41:11]How to solve this?

[00:41:13]Uh there's roughly two approaches, I think, that are promising. Uh there's a variant of of HSTS uh where where a server says "I will always have a post-quantum certificate." And once uh a client learns about this, they will refuse to connect to that same server if they didn't see if they don't see a post-quantum certificate next.

[00:41:40]Um this is similar to uh how HSTS now also does it for encryption.

[00:41:46]The downside here is that this only works that it doesn't work for the first connection.

[00:41:51]Well, you have the preload list, but the preload list won't scale to all domains. So, I mean, it it helps. This this will be important. It it will give security, but it is not not completely scalable.

[00:42:03]A second approach, which we can do at the same time, is using certificate transparency.

[00:42:09]And the key idea here is it has a difference between the two legacy certificates, the traditional classical certificates. The The certificate you send to a legacy client doesn't have to be the same classical certificate that you send to a post-quantum client.

[00:42:26]And And if we ensure that certificate transparency is post-quantum, then you can look at in certificate transparency whether a downgrade certificate was issued for your domain. If it was issued for your domain, then something fishy is happening.

[00:42:41]And this looks like it's a new way of things going wrong, but it's not that different from a CA issuing a wrong certificate to begin with.

[00:42:51]Um Also, Chrome recently wrote a nice road map on authentication. So, again, in in in diagrams, here's the the case with the problem. The key point is that the classical certificate on a legacy server and the classical certificate on a PQ server, they are not the same. They should not be the same thing. They are different things.

[00:43:10]And if you see a a downgrade certificate, uh that's the one on the right. If you see a downgrade certificate, it's Sorry.

[00:43:17]That's the one on the left.

[00:43:18]So, the the classical certificate that's appropriate for a legacy server, you should not see this for your server in certificate transparency if your servers are PQ capable.

[00:43:29]So, but it does require that certificate transparency is made post-quantum.

[00:43:33]Also, this doesn't detect it during when you connect, it's not detected, but you have to monitor certificate transparency, but that's similar as it is today. You have to monitor certificate transparency to see if there was no certificates misissued.

[00:43:47]Okay, so that about downgrades.

[00:43:52]Uh today's software support for PQ for PQ certificates is quite limited, but it will come.

[00:43:57]Um What can we What can you do today?

[00:44:00]Just keep software up to date. A lot of times software is already old. It's a just a big pain to get software up to date. You can do that today already.

[00:44:09]Uh you can already check that you can install two certificates. You can just install an RSA and ECC certificate on a server. You can already check that that works.

[00:44:16]Uh automated issuance will help.

[00:44:18]Automated key rotation helps.

[00:44:21]Um there might be protocol ossification.

[00:44:24]You can try uh installing a lot of dummy certificates uh in the chain so you can simulate what if larger certificates are a problem.

[00:44:35]Um and maybe maybe you're lucky. Maybe the libraries you use already have post-quantum certificates and you can go get started.

[00:44:44]Well, my question is uh which algorithm?

[00:44:54]Um I I think this is it is embarrassing that there's so many choices and um so for years it was larger actually this list in in proposals. Uh uh for for years at the IETF uh uh a lot of people have proposed to reduce the number of algorithms.

[00:45:16]Uh and everyone agrees. Everyone agrees we want to have fewer algorithms.

[00:45:19]And then the question becomes which ones? And then we get a long list again.

[00:45:25]Okay, so what what what would be my choice?

[00:45:28]Um SLH-DSA, that's it I mean it is strictly more conservative than ML-DSA.

[00:45:36]But the only real key agreement in town which is practical is ML-KEM. So for secure connection we are already assuming module lattices.

[00:45:49]So we can just as well also assume so trusting ML-DSA doesn't add really another assumption. So we can ignore SLH for TLS.

[00:46:05]The The nice So, for key agreements, these cipher texts have to live forever, whereas signatures, they only have to uh uh survive as as long as it takes to rotate them.

[00:46:21]So, we can be more aggressive there with the choice of security level, and ML DSA 44 is already quite a bit above the lowest security level, so I no qualms with just going for ML DSA 44.

[00:46:39]And combining them with RSA doesn't make any sense to me.

[00:46:43]Uh the benefit of the The only benefit today of RSA, if you start from scratch, is that the verification time is fantastic.

[00:46:52]But the verif- But But the verification time of ML DSA is not slow, but it's similar to elliptic curve, so there's no benefit to combining with RSA.

[00:47:01]Um then, Ed25519.

[00:47:04]I like it. It has It has It has benefits over P256, but nobody uses it today in practice.

[00:47:11]Let's not do two migrations instead of one.

[00:47:14]Which leaves two options: ML DSA 44 combined with P256, and ML DSA 44 on its own.

[00:47:23]I like hybrids.

[00:47:24]I especially like hybrids because we can deploy them without having to to convince anyone that it's okay. No.

[00:47:33]But unfortunately, even though this is my preference, I know there's disagreement on this.

[00:47:40]That this is the right one. And the thing is is maybe I can install ML DSA I can install two certificates, but I can't install 10 different certificates because there's 10 different preferences on clients.

[00:47:53]So, it hurts to say, but for compatibility and the ML DSA on its own seems like the safest bet. But but you can always provision both ML DSA 44 and the and the and the and the hybrid.

[00:48:10]Okay, that's that's some thoughts I wanted to share and maybe maybe two more final thoughts is things only start moving close to the deadline. So does it matter if the deadline is closer?

[00:48:32]So I'm not too worried. Another thing is that this migration has worried me for a long time about the effort it takes but with the actually I I never saw I never imagined I would say this but with the advances and that we have seen just in the last months of of uh these these AI models uh I think they will help a lot with uh moving quickly.

[00:48:57]Uh okay, thank you.

[00:49:00]>> [applause] >> Any questions?

[00:49:14]>> Hello. Hello.

[00:49:16]>> Hi. Uh my name is Mike O'Rourke. Um first, sorry for all the hybrids.

[00:49:21]Um second, I have strong opinions about HSTS style ratchets being considered harmful. I'd love to get involved in that uh discussion.

[00:49:28]>> So So can you come PQ HSTS?

[00:49:31]>> Sorry?

[00:49:32]>> PQ HSTS?

[00:49:33]>> I have strong opinions about HSTS considered harmful.

[00:49:37]Uh I'd love to be involved in that discussion if we could.

[00:49:40]>> Yeah yeah, sure.

[00:49:41]>> Um your graph your data about um PQ adoption on the web, you you're showing the X-Wing, the X25519 hybrid. Are you seeing any P256 traffic?

[00:49:53]>> Um, it's I can give you the number in a bit, but it's well below a hundredth of a percent, I think.

[00:50:01]>> Okay.

[00:50:02]Um And then my last question, could you skip back to your um uh certs are a tad more involved massive flowchart thing?

[00:50:12]>> Yeah.

[00:50:15]>> Yeah.

[00:50:16]So, at the risk of adding more boxes here, um how does regulation cab forum web trust like the same question for MTC? You said MTC in 2027. Are the web trust auditors on board involved or we going to have this audits and regulations and blah blah on that same timeline?

[00:50:34]>> Yeah, I I I I wasn't very clear. This this is just I I was saying for your internal organization, what would it the boxes at least look like? Yes, if in there are more boxes for the web PKI.

[00:50:48]Um, with Merkle tree certificates, the nice thing is that uh the one way don't have the performance improvements over the standalone certificates.

[00:50:58]There's not a lot of extra work. That's just only checking a small authentication path extra. That's not a lot of work.

[00:51:04]Um, sorry, you had another question and the >> Well, I mean, right. So, the question is if you were to draw this diagram for MTC certs, um when you say Chrome is going to support it by 2027, does that mean publicly trusted trust stores or is that some sort of off regulation deployment of private roots, MTC roots?

[00:51:26]>> I can't speak for Chrome, but I think they will do it for their public trust for yes.

[00:51:32]>> Sure. So, I give it an open question to the room. If anyone knows if cab forum is involved in this MTC and what if it's planning to hit that 2027 date, too, that would be exceptionally good to know.

[00:51:45]>> That's so I'm a CA nor a browser, so I'm not at the forum.

[00:51:52]>> Any other questions?

[00:51:54]Oh, here you go.

[00:51:57]>> Uh thank you very much for mentioning configuration as a as a barrier to adoption. I've been fighting ill-advised user, you know, over configuration of the systems to quote-unquote make it more secure, which just ossifies everything. Uh so, it'll be very important to uh send that message out.

[00:52:15]Um at least OpenSSL now has a new facility when you're configuring groups, you can use the default keyword in there to slightly tweak it without having to specify its internals. So, I think that'll be helpful if the word gets out.

[00:52:29]Uh now uh secondly, uh you mentioned ML-DSA 44.

[00:52:35]Uh I think when we did OpenSSL 3.5, we sort of preferred 6.5. Maybe that was a mistake. I don't know if you are now encouraging us to put 44 as a more preferred signature algorithm. We should talk about that perhaps.

[00:52:50]>> Yeah, yeah.

[00:52:59]>> Okay.

[00:53:00]Uh any other questions for us?

[00:53:05]All right, let's thank our speaker again.

[00:53:09]>> [applause] >> Next speaker is uh François Dupras Sois uh from University of Bristol, uh and he's going to be speaking about formal methods to manage the risk of uh change. So, please welcome François.

[00:53:26]>> [applause] >> Thank you. Um thanks for the uh invitation to speak as well. Um so, yeah, I'll be talking about risk in a different setting entirely, um and I'll be assuming that all of the questions that uh uh, Sophie and Bas just talked about have been resolved.

[00:53:43]Uh, we know what we want to deploy and now we need to actually, uh, implement the change.

[00:53:48]Um, what risks will arise? And so, obviously, I'll talk about bridges first uh, for a bit.

[00:53:53]Uh, so, consider bridges.

[00:53:55]How do you build a bridge? You pick a bunch of good stones.

[00:53:58]You build a small bridge. Try to put weight on it.

[00:54:02]If the bridge collapses, you go back.

[00:54:04]You keep doing a bit of, uh, uh, of engineering. You keep measuring, um, and then at the end you get a bridge that's good enough. And then over time you build more bridges, you get good at building bridges, and you learn how to engineer good bridges, and you end up with something that is actually not a bridge, but, uh, something that looks like a bridge and, uh, and actually stands the test of time and is a nice feat of engineering as well.

[00:54:29]Um, if you do the same thing for crypto, you select good mathematics.

[00:54:34]You do small-scale trials. You hide a little bit of money behind it.

[00:54:38]Uh, you see um, when it fails, and then you make better choices. You improve your your photography. You measure again. You see how, um, the attacks evolve with the amount of money you hide behind it. Uh, and eventually, you get better at doing that, and you can actually engineer secure systems, secure network, secure internet, and along the way you learn how to build those systems in a secure way as well, uh, and in a robust way.

[00:55:03]And, uh, then we kind of got good at software at cryptographic software as well.

[00:55:08]Um, this is a claim, and I'm putting a question mark after it, and I'm very happy to discuss it. I think we got kind of good at it. Where I also think we got, um, slightly less good at it than we are at bridge engineering. We still have a lot of crypto failures. Um, we still have some bridge failures. They are more costly in lives and in, um, money as well. I'm not sure about the per user statistics, or bridges used more than cryptography, or the other way around. I'm actually not sure at all.

[00:55:38]Um and then on on bridges there's also the question of regulations. Do they actually help the bridge to stand up or or not? Uh and I'm not arguing that we should regulate cryptography at all.

[00:55:48]Um but this is a another thing that might make um the difference between bridges and crypto software.

[00:55:55]Um the point here is I believe we are slightly less good at building crypto software than we are at building bridges.

[00:56:02]And I wanted to ask um what happens when um some change happens like somebody says instead of making bridges out of stone we should make them out of fire.

[00:56:14]Um some of the engineering principles stay the same.

[00:56:19]You still need to like calculate the load of your bridge to figure [snorts] out what are the your safety margins.

[00:56:25]And some change, all of a sudden your bridge is lighter, you need to consider the wind um and the effect of the wind on your bridge.

[00:56:34]The oscillations that this induces, all of that stuff, which you didn't have to when it was made out of stone. And what you get is catastrophic failures like a bridge collapse.

[00:56:43]Um so that change itself, the change in your foundations, is not risk-free at all.

[00:56:49]Even when you have robust engineering of the kind that gives you those um massive bridges and aqueducts.

[00:56:55]Um so you've got new things to consider and you've got new risks as well.

[00:57:00]So here we come and say we need to build crypto out of fire.

[00:57:05]Um and some of the engineering principles stay the same and some of the engineering principles are going to change as well.

[00:57:12]Um it's not risk-free despite engineering.

[00:57:17]And our engineering again I claim is slightly less robust than the one that we put in bridges.

[00:57:23]And so where is it less robust and where do we need to look at things?

[00:57:27]>> [clears throat] >> So bridge engineering is robust because it gives us this ability to uh detect detect that. Detect defects early.

[00:57:37]So, we start by testing materials we put in the bridge. So, we get stones or we get iron, we stress test it. We're going to test those materials, figure out their their properties in shearing and tension and all of those things.

[00:57:55]Then we'll build small models of the bridge. We'll put them under test under load.

[00:58:00]Now, we know that we need to put them in a wind tunnel as well.

[00:58:03]Um >> [cough] [clears throat] >> So, we'll do those scale tests.

[00:58:09]We'll do modeling as well.

[00:58:11]We'll try to see if the models line up with the tests.

[00:58:15]And then we when we build the thing, when we actually build the object, we'll keep measuring all of those things as we build and after we've built it.

[00:58:26]We'll try to figure out is the behavior of the actual thing we're building different from the one we predicted.

[00:58:33]>> [snorts] >> We are good at the modeling bit of cryptography.

[00:58:38]We are good at measuring after it's been constructed and deployed.

[00:58:43]And I claim we're horrible at measuring things as they're being built.

[00:58:50]And this is where I believe that from methods can make a difference and this is what they're they're designed for.

[00:58:57]So, [snorts] as a as a quick story, which is not exactly of um measuring as things are being built. Um this is a recent result on XMSS.

[00:59:08]Um So, XMSS is a an old signature scheme, older as in um it is older than my daughter.

[00:59:16]Uh So, it's from 2011.

[00:59:19]Um it was um published as an RFC in 2018 and then uh adopted as an NIST standard um shortly after that.

[00:59:30]And uh just recently, last month on ePrint, we put a paper that essentially says is the RFC and the paper disagree on the specification of XMSS and one of its components.

[00:59:41]Um and the proof of security for XMSS does not apply to the RFC.

[00:59:46]There is a small thing. So, it does Sorry, I should not say that. It does apply to the RFC with the uh specific parameters that are in the RFC. If you change those and if you use it with uh with different parameters, then you don't get security guarantees.

[01:00:02]Um and we found that um now um following that, 8 years after the after the RFC was published.

[01:00:13]The The small detail is that in the checksum for um for one of the components, the specification, sorry, the algorithm as specified initially um says you have a checksum, which is the sum of a bunch of things, and then you represent it in base W, and you stick it at the end of your message, and um the RFC says you take your checksum, which is your sum, and then you shift it, and then you take some fits bits and tag them at the end of your message, and that shift here and the length that you take end up dropping one of the bytes of your checksum if this condition holds. So, if your if that thing is divisible by eight.

[01:00:57]Um So, if you for example, instantiate XMSS with W is equal to 256, you fall apart. Or if you instantiate WOTS with W is equal to 256 as is done in SPHINCS, then if it was specified as an XMSS, then it would be different.

[01:01:15]Or it would fall apart. It doesn't. It has been fixed or was fixed uh during standardization, but this took a a while for us to find it. And the only reason we found it is because um we actually did connect the security proof that we formalized all the way down to the implementation.

[01:01:36]So, we had a security proof that we claimed at the time was for XMSS as in the RFC.

[01:01:43]Um we published that.

[01:01:46]It was accepted. Nobody spotted that what we actually specified was this and not what the RFC said.

[01:01:56]We didn't spot it. The reviewers didn't spot it.

[01:01:59]Uh oops.

[01:02:01]Um and only when we combined it with an implementation that we tested against existing implementation of XMSS could we actually spot that there was a difference um between the two behaviors.

[01:02:15]Um this is not something that you would have tested that you would have found by just testing because nobody instantiates um XMSS with different parameters, but it is still identifying a future risk.

[01:02:27]Somebody picks up the RFC in the future and says, "Ooh, why don't we instantiate it with W equals 256?"

[01:02:34]Um and claim that we inherit the security um the security properties that have been proved on XMSS.

[01:02:41]Um we now have a warning in there that says you shouldn't be doing that.

[01:02:46]>> [snorts] >> That is not exactly a success story.

[01:02:53]Right?

[01:02:54]The RFC still has a latent risk in it um that somebody will pick it up and use it wrong.

[01:03:01]And so, the the formal methods themselves are not going to remove the risk entirely. They're going to allow you to identify it.

[01:03:09]They're going to allow you to mitigate it if you apply them after the fact. If you apply them up front, so if you do them from the left to the right, so from design all the way to execution, then you actually get slightly stronger guarantees. So, the way we would have liked to be able to do this, if we had the tools in 2011, is that when the algorithm gets published and before it gets considered for formalization for establishment, I guess, as an RFC or as a standard, then you formalize the algorithm, you formalize its security properties, you formalize a proof that it has these security properties. So, you machine checked all of these so that there is no trust needed in the results or in the authors of the result.

[01:03:54]Then you refine that into a standard.

[01:03:56]So, you make decisions about how do we represent that information on the wire?

[01:04:00]How do we represent that information um in in memory? So, all of those shifts that are needed in the RFC or to try to save some computation in practice when you implement XMSS or avoid some weird bit calculations.

[01:04:15]And then when you make those refinements, you're going to prove formally again that those refinements don't weaken your security. And at the same time, you might even lower your security model, your adversary model.

[01:04:26]Your adversary now has more things that it can do to your to your code. It might try or to your standard. It might try to pass in invalid values and you should have checks that um the algorithm rejects those, whereas the cryptographic algorithms might have just expected a particular value to come in um without additional checks.

[01:04:47]Um And so you again do a proof that um that your standard refines your algorithm securely. And then you come up with your reference implementation and same thing, you will show that that refines your standard in a secure way.

[01:05:01]Um and at that point you can even start considering what about side channels.

[01:05:05]The adversary has access to even more information now. You refine your security model, get a proof, formal or not, uh in that model.

[01:05:13]Then you move down to an optimized implementation, and you can go down and and down and down and get those refined properties as you want them, and really establish trust as you go down. And every time you go down one step, you again go back and validate all of the modeling choices that you've done before, right? So, what you get out of this chain of proofs is really at each step, before you move down, you check that actually, yes, there is a possibility that the next step I take will give me something that's secure instead of knowing that I'm already insecure now. I shouldn't even be trying to move down.

[01:05:48]Um but when you go down, you look back and say, "Did I make the right choices up there?"

[01:05:54]This is the ideal scenario. That's a lot of work.

[01:05:57]And when you already have a system that's exist that exists, that you've got deployed, um and that you can't just change willy-nilly, you're not going to do all of this, right? Um again, just this proof here, um that took us about a year. And yeah, it wasn't an expert user of EasyCrypt or of the tool we're using, but it was still a year of work uh for them to do it.

[01:06:21]Um and it wasn't done when this the um the algorithm was presented because the tools didn't exist yet, right? So, this is still a research work that we're doing um with a high level of expertise needed.

[01:06:34]And moving down to the implementation was again another year of work uh for somebody to do.

[01:06:41]And so, this is absolutely not something that you will do at engineering pace.

[01:06:45]Um but it's something that we can do at research pace, right? So, moving from research into engineering, this is absolutely something that we can start uh thinking about. But on established systems, there is good news is that you don't need to do the whole thing to get value out of it. You can do just part of it, and you can use uh lightweight methods to do some of it. And a lot of the work is already done. So, all of the new standards, ML-KEM, ML-DSA, SLH-DSA, SHA-3, which isn't that new, but it's still new in the sense of its use in in large constructions. All of those we have machine check proofs of security for those.

[01:07:26]For some of them, we've also got connection to implementations that allow us to validate that they are actually the right specifications that we've implemented. Some of them we have specifications that we've proved security of, but we don't really have evidence that those are the right specs, apart from the fact that the reviewers didn't spot anything.

[01:07:47]Um but that might those might be a an interesting one to look at and and try to find something with.

[01:07:54]Um and so, we do have this advantage in that at the bottom of the of the change, I guess, we do have some components that are slightly more trustworthy.

[01:08:06]Um and we do also have lighter weight formal tools that could be applied above that. And when I say lighter weight, and I have this on the right, this is lightweight, but it's still a lot of work.

[01:08:17]So, so it's still quite a bit of work to get it done. So, I'll give you a vision of how those lighter weight tools can help.

[01:08:24]Um but I'm again very happy to be challenged. This is my naive view from how the change can happen, and I'm already aware of a lot of changes that that would that would not be possible or for a lot of those things that would not be possible. So, here I'm already making an assumption, which which is big, that you've got your existing construction implementations. That could be a protocol.

[01:08:45]Protocol scale is not something that would recommend yet, but that could be an ML-KEM, for example, where those components are the entity. And the big assumption is that you have a boundary that you can actually carve out, which doesn't exist in practice, but that's something that um that could be worked towards as well. And you've got existing component implementations as well. So you've got your entity or you've got your ML chem or your um signature inside your bigger protocol.

[01:09:12]Um And then the first thing that you should do is annotate that that boundary here with safety and security annotations. So safety being I expect a buffer of this size at this input. Um and I'm expecting that I will write in that other buffer and I will write this many Um and security annotations could be I expect an NCC chem here or could be I expect an EUCMA um signature algorithm or it could actually just be I expect um I expect to be working on public on this uh input being public and that input being secret data. So really for um side channel information, for example.

[01:09:57]So you just put those annotations in.

[01:09:59]That forces you to do the work of thinking about your system, of carving out the that boundary, uh and getting that done.

[01:10:06]And then you can start working with lightweight tools on um verifying or on getting some guarantees about those components already.

[01:10:16]Right? So you can do lightweight verification where you get safety, so just checking that your memory accesses are within bounds, uh that you have panic freedom, that you're not um freeing memory. You shouldn't be freeing memory here, but um um But anyway, so you can already get some guarantees there that the code that you're uh that you have is good uh or is not doing wrong things.

[01:10:40]And eventually you can start replacing that with a new verified primitive. And this is where we start talking about the change. That verified primitive is going to be verified against those annotations that you've placed. So as long as you got those right and you got those right and I will tell you what that could mean in a minute. Um then you know that that change is not going to break your system.

[01:11:03]It is going to just slot in, and you won't have safety issues that come from that or security issues that come from it.

[01:11:10]At the same time, you could also annotate that upper interface, so whatever interface that is, whether it's a protocol interface or something else, for safety and leakage, um or more if you're ambitious, um annotation security properties of your Um and then you can start doing the work of with lightweight formal methods again, trying to verify that the your implementation here doesn't leak with the assumptions that are provided by these annotations at the interface down here.

[01:11:39]Or you could even start replacing the entire component the entire larger component here with a big thing.

[01:11:46]Um and with a new verified implementation as well.

[01:11:50]Um and so here the the um the advantage you would get is that when you slot in that component, you know that the assumptions that you've made here are going to be respected, are going to be fulfilled. And when you replace the outer component, you know, because you'll have verified it, that these guarantees that you've provided here are sufficient to get those guarantees that you wanted up here.

[01:12:15]All of those things are a lot of work.

[01:12:17]And I think all of those things are worth doing.

[01:12:21]Um and some are doing it now. So at a smaller scale, so I was talking about protocols and large components here, but at smaller scale, um ML Kem and ML DSA native, the AWS libraries, um do do this already, where those big boxes on the outside are going to be ML Kem and ML DSA implementations in C that have safety verification uh done in CBMC, and those little uh modular components on the inside are NTT implementations uh optimized entity implementations in assembly that have full functional verification on them.

[01:12:58]Um So, so those things are possible to do already.

[01:13:04]Uh and you can get some value out of them.

[01:13:07]Um those lightweight verification tools that I'm talking about, they exist. So, model checking do does exist. Simple type systems are al- already formal methods. So, if you're implementing things in Rust, you are doing formal methods and you're getting some guarantees out of that. Um but we also need to agree on a spec language to connect annotations and proofs. So, here when I'm talking about annotations that are safety, those are relatively standard.

[01:13:33]Um when I'm talking about annotations that annotate security, including um about leakage, this is less standard and we need to come up with a way of expressing those guarantees.

[01:13:43]Um and there's still this question about verifying components that are written in one language, composed with um with bigger systems that are written in another language, and at the moment that interface here requires a bit of manual review, which is again a point that will fail.

[01:14:00]Um some conclusions here. Um formal methods can help manage the risk related to change by allowing you to establish what you want to know about your components before you start swapping them in and out, and then be able to verify things um before you plug them in.

[01:14:16]Um this effort does require a little work up front, but that work itself does have value. So, you'll have to inventory where am I using this bit of cryptography? You'll have to review what properties you want at its interface, uh and you'll have to identify and perhaps even uh carve out those boundaries a bit more clearly than they are.

[01:14:37]Um I want to do also highlight that formally linking the security proof to a crypto component uh to a cryptographic implementation does have its adv- its advantages. It It helps you find issues in specifications like we did in XMSS, but also it also helps you mitigate the risk even further. If you get the specification wrong, but you have a proof that it's secure, the only failure that you can get is a loud failure. It's going to be a functional one. You won't get a loss of confidentiality that comes out of plugging in something that is implementing the wrong spec in an insecure way.

[01:15:14]Um and most importantly, if we do manage to do all of this and get all of those formal guarantees on the cryptography we're building, on the engineering and the software we're building, the one thing we'll have to worry about beyond all of the things that Bas talked about in terms of deployment and configuration and all the things is also the bottom layer, right? The only thing that we'll have to worry about is are the stones or the iron we're picking up to build a bridge actually as robust as we need them to be.

[01:15:42]Thank you.

[01:15:45]>> [applause] >> There are questions for François.

[01:15:53]Um while people gather their thoughts, I have a couple questions on the XMSS work. Um what formal methods, tools, and implementations did you look at?

[01:16:04]>> So we for the um security proof we used EasyCrypt.

[01:16:08]Um and for the implementation it is done in uh Jasmin, so the Jasmin language.

[01:16:13]>> Okay.

[01:16:14]>> And the verification The functional verification is then also done in EasyCrypt. So it's really uh a tool chain that interacts well with each other for that.

[01:16:22]>> Thanks.

[01:16:23]Um James.

[01:16:28]>> Hey François, thanks for the uh really good talk. Um we had a couple of presentations earlier today about FN DSA and Falcon.

[01:16:36]I wondered if you knew of any attempts at formally verifying this and whether Formays had any plans.

[01:16:44]Um Any plans? I don't think so. Attempts?

[01:16:50]Yes.

[01:16:52]Uh there have been attempts.

[01:16:55]Um so there's there's even just specifying floating point arithmetic is a is difficult.

[01:17:01]Um but SMT like the SMT solvers so automated reasoning techniques do know about those uh and have robust specification for those that are tested in other settings as well.

[01:17:11]Um in the context of the security proof, we try to not rely on those too much because we want on automation too much because we want our proof to be repeatable quickly. So we don't want the change in the solvers to just break the proof in a way that we can't predict. Um And so so we're not ready for looking at that yet.

[01:17:32]In terms of the implementation, uh I think they're facing similar issues in that extending Jasmine to have uh support for floating point is also a big engineer project on its own. Um but that that's again, there were attempts.

[01:17:49]Uh I can look look back again and answer that offline.

[01:17:52]Um but whether there's plans.

[01:17:58]>> Thank you.

[01:17:59]Uh any more questions?

[01:18:04]Okay. Uh let's thank our speaker again.

[01:18:06]Thank you.

[01:18:07]>> Thank you.

[01:18:07]>> [applause]