WEBVTT 00:00.000 --> 00:16.960 So, hello everyone, welcome to our next talk about post-pantum cryptography from Clemens and 00:16.960 --> 00:31.280 Andrew Twig. Welcome. Good morning everyone. Thanks for being here. My name is Drick Shellard. 00:31.280 --> 00:38.400 I work at Red Hat. The reason we have chosen this topic because we see post-contum cryptography 00:38.400 --> 00:44.240 also known as PQC. We are sitting at the intersection of quantum computing and today's 00:44.320 --> 00:53.280 internet security. Quantum computing is important because it is certainly affecting the crypto 00:53.280 --> 00:59.600 system that we rely on today and hence we want to define reliable path forward. 01:00.480 --> 01:05.040 I would start by giving a high level intuition of quantum computing why today's cryptography 01:05.040 --> 01:12.080 system are at risk and how we can safeguard our system's hybrid PQC approach. Then Clemens 01:12.080 --> 01:18.240 would emphasise more on the current trends with PQC and how we can integrate the same in our 01:18.240 --> 01:20.400 day-to-day software supply chain. 01:20.480 --> 01:26.480 Are you in the DAV louder if someone was to go on your own computer? 01:26.480 --> 01:32.480 Okay, let me just. Is it good now? 01:32.480 --> 01:38.320 I think this. How about this? 01:38.320 --> 01:53.280 I think it should come somewhere here. How about this? 01:53.280 --> 02:03.200 All that. So we know that quantum computers are super powerful especially solving 02:04.160 --> 02:11.120 problems that require massive power. At the same time we know that there is a constant threat 02:11.120 --> 02:18.240 for our classical PQC system as well. So our PQC system has been there for decades. 02:18.240 --> 02:24.400 It is acting as a silent guardian for us. All the DLS handshakes, digital certificates, 02:24.400 --> 02:29.920 keys, they remain invisible when they work. Because they are definitely built upon certain 02:30.000 --> 02:34.880 math problems which are super difficult to crack for the classical computers. 02:35.680 --> 02:41.120 Now when we talk about math problems these are like integer factors and some discrete 02:41.120 --> 02:47.680 log problems. So to give an example breaking real RSA it's like trying to figure out which two 02:47.680 --> 02:54.080 giant prime numbers were multiplied to form a 500 digit number. It's that difficult and that 02:54.160 --> 02:59.680 kind of difficulties keeping our entire email, web and blockchain secure today. 03:01.120 --> 03:06.080 So quantum computing is important because it challenges the math behind this building blocks of 03:06.080 --> 03:14.080 PQC. So a fully powerful, fault-around quantum computing system is known to affect 03:14.080 --> 03:20.640 today's classical system using sure algorithm. So what happens is with classical systems it is 03:20.720 --> 03:25.920 forced to get the pattern behind this math problems. But quantum computer using its 03:25.920 --> 03:33.920 Q bits and entanglement makes interference that easy it helps identifying the patterns so 03:33.920 --> 03:40.640 that the hidden patterns stand out instantly. So once you or quantum computing know the pattern 03:40.640 --> 03:45.120 it makes easy to crack all the integer factorization or discrete logarithmic problems. 03:46.080 --> 03:51.760 However, at this moment we don't have such quantum computing computer readily available with 03:51.760 --> 03:58.160 that level of capacity of Q bits or let's say fault-around tolerance that requires to crack 03:58.160 --> 04:04.000 these problems. So you might be wondering is this transition to PQC is really needed if you 04:04.000 --> 04:11.040 don't have such quantum computer available or why people are seen this as why to Q or Q day problem. 04:11.760 --> 04:17.920 Well, there is a constantly a looming threat behind this whole ecosystem. It's called 04:17.920 --> 04:24.640 Harvest Non Decree Platter. Any adversary or attacker could try to store your encrypted data 04:24.640 --> 04:30.560 to a and decode it later in the future when they have such powerful, fully fault-around quantum 04:30.560 --> 04:36.720 systems readily available with them. So this is not, sorry, this is not really about future 04:36.800 --> 04:42.800 proofing our system. So this transition is basically protecting your data today so that it cannot 04:42.800 --> 04:50.640 be exposed tomorrow from the quantum attacks. So let's talk about timeline. This slide is 04:50.640 --> 04:56.560 really about three clocks which are taking at the same time and the scary part is they are not aligned. 04:56.560 --> 05:03.520 So time to transition is definitely larger than the arrival of quantum computers because it 05:03.600 --> 05:08.800 includes a lot of standards, vendor upgrades, products supports and whatnot. So the list goes on. 05:09.600 --> 05:15.360 And then there is another clock which says time you need your data to remain secure. 05:15.360 --> 05:22.640 Now we briefly classify this into urgency model. So for example, you might have some keys that are 05:22.640 --> 05:29.920 having low important or required or pose a low impact. So not everything needs to be migrated. 05:29.920 --> 05:35.120 You need to classify what data you have. Then there could be a medium urgency where you have 05:35.120 --> 05:41.920 TLS search SSH keys that need to be treated at medium impact. Then higher agencies therefore 05:41.920 --> 05:47.120 especially for national security systems where decades of secrecy is required. You may have 05:47.120 --> 05:52.560 some transact financial transaction or defense records that should not be exposed at any cost. 05:52.880 --> 06:04.880 So you might be wondering what solution here how we can safely migrate to the PQC or how we 06:04.880 --> 06:11.680 cannot affect our existing system so that the existing encryption doesn't break and yet we can 06:11.680 --> 06:18.640 able to migrate to PQC. So the solution is obviously hybrid crypto which offers defensive 06:18.720 --> 06:27.200 depth. How many of you like Swiss cheese? I certainly do. Yeah. So it offers security 06:27.200 --> 06:32.000 at defensive depth just like Swiss cheese security. This approach has been used in various 06:32.000 --> 06:39.680 industries like aviation security emergency units. So what it does it overlap multiple security 06:39.680 --> 06:45.920 system so that if attacker has to attack it should be succeed attacking two system at once. 06:45.920 --> 06:50.800 Then only the attacker could succeed. So the same approach has been used when we talk about hybrid 06:50.800 --> 06:55.520 crypto. So thanks to some of the communities who are 06:55.520 --> 07:01.360 proactively working on making this transition possible. One of the examples here is open SSL which 07:01.360 --> 07:09.200 open SSL 3.5 with TLS 1.3. Nativity supports the PQC, KXN algorithms as well as digital signatures. 07:09.760 --> 07:14.480 So when we talk about KXN, we have MLKM which is based on model lattice problem. 07:15.440 --> 07:24.160 Then we have hybrid KXN where we combine this MLKM along with our classical ECDH key to form 07:24.160 --> 07:33.760 a hybrid KXN just like MLKM plus the ECDH. Then there are post quantum signatures primarily 07:33.760 --> 07:41.040 MLDSA and SSL GSA. The SSL GSA is based on digital hash setless hash and MLDSA is based on 07:41.200 --> 07:50.720 model lattice problem. So there are certainly some variants that defines how these key exchange 07:50.720 --> 07:56.880 and digital signature can be classified. So there are some performance rate of that we also need 07:56.880 --> 08:05.600 to consider. So MLKM comes with three variants 512, 768 and 1224. So lower variants often 08:05.680 --> 08:11.680 gendered smaller keys which is essential for faster handshakes. Then with higher variants 08:11.680 --> 08:19.360 it produces larger keys but it also gives higher security margin. Same goes for digital signature. 08:19.360 --> 08:27.440 Smaller the signature faster the verification of your trust with higher variants it produces larger 08:27.440 --> 08:33.120 signatures but it is also better for long-leaved connections. For example, firmware search, 08:33.280 --> 08:42.160 root search. So let's have a look at quick demo. I have just to give in context. I have 08:43.360 --> 08:51.200 built a Fedora 43 system on top of which deployed engine server that runs and support the 08:51.200 --> 08:59.440 open SSL 3.5 library as well. So I have kind of put both trust here. One is hybrid KXN 08:59.520 --> 09:05.600 and the classical one just to see how fallback works when there is a client that is not 09:05.600 --> 09:10.800 capable of interacting with the hybrid key actions. So we will take a look at both scenarios. 09:16.240 --> 09:23.680 So first let's conform the open SSL and system release. So this is Fedora 43. 09:23.680 --> 09:46.400 Then open SSL 3.5 onwards supports this KXN. Then are we listing all the KXNs that are 09:46.400 --> 09:52.240 natively available within this open SSL library. So you can see these are digital signatures 09:52.240 --> 10:03.840 with all the variants. Then I would be listing the KXNs. So primarily we are focusing on the 10:03.840 --> 10:19.520 hybrid KXNs, the CDH plus MLKM. Now I would be creating a digital search, self sign 10:19.520 --> 10:27.840 search based on this MLKM, based on the MLDSA as signature algorithm. 10:34.320 --> 10:37.440 Now I would be creating a RSA search. 10:37.680 --> 10:54.560 Now we would define this search key pair inside our engine X configuration so that when we try to connect 10:54.560 --> 11:03.200 client it would pick up these certificates. So this is the typical engine X configuration where I have put 11:03.440 --> 11:11.440 all MLDSA as well as RSA key pair. 11:11.760 --> 11:24.960 Now just reloading the engine X configuration to get in effect with this server. 11:25.200 --> 11:40.240 So if we just test the server it should be working fine, yeah it is working fine. 11:44.560 --> 11:51.360 Now I would be trying to connect the server as a client using MLDSA search and then we could 11:52.000 --> 12:00.080 see the key pair being used here. So when I try to connect it shows PR signature type MLDSA 12:00.080 --> 12:08.800 and negotiated PLS group is hybrid KXNs. Now there might be some clients who cannot 12:08.800 --> 12:16.960 interact using hybrid KXNs. So they can continue to use the RSA for example this. 12:17.040 --> 12:21.520 So PLS signature shows RSA and just the ECDH key exchange. 12:23.040 --> 12:28.160 So that's how a fallback basically works. In case you still have such clients. 12:29.760 --> 12:37.440 Now you must have noticed this is possible because of PLS 1.3. One of the smartest design 12:37.440 --> 12:45.760 is to like to redesign PLS 1.3 so that it can support key exchange independent love 12:45.760 --> 12:49.920 cypher. So your existing cypher suits and encryption doesn't break right away. 12:49.920 --> 12:54.960 And hence script agility is preserved. This also helps hybrid PQC which we just saw 12:55.520 --> 12:59.920 because it can operate entirely into key exchange layer and not in the cypher suit layer. 13:00.800 --> 13:07.280 So if you look at a typical PLS handshake for hybrid PQC, the key exchange 13:07.280 --> 13:13.200 determines how secrets are created. Then the signature defines who is trusted to create them. 13:13.760 --> 13:18.240 And then comes the cypher suits that are about how data is protected afterwards. 13:21.040 --> 13:24.400 Now I would hand over KLEMAN who continue with remaining. 13:25.440 --> 13:32.240 Yeah. Thank you. So where are we today? Here are some numbers. 13:32.240 --> 13:41.200 Cloudflare has been measuring the amount or the share of key exchanges that they see from 13:41.280 --> 13:46.480 human clients. So that means essentially browsers that use post quantum key exchange. And the 13:46.480 --> 13:55.600 good news that it's almost at 60% was like at 58% recently. So IIT of working groups are working 13:55.600 --> 14:01.680 on adding post quantum cryptography to a lot of protocols already. You've seen this work for TLS. 14:01.680 --> 14:06.960 It's not an RC yet, but everybody in the kitchen sink has already started implementing it. 14:06.960 --> 14:14.960 Like 60% of the connections use it, but it's not yet an RC. So Chrome 116 and later. So that's 14:14.960 --> 14:23.120 quite a while ago. I had already do PQC key exchange. Fedora 43 now has it. And then IIT by default. 14:23.120 --> 14:28.880 And then also the entire secure boot world that needs to do something because it's currently 14:28.880 --> 14:35.680 based on RSA. And IBM is the first ones are that the gate with a Z16 chips that actually have 14:35.680 --> 14:43.520 a lot of space signatures and a cam spaked into their firmware and boot chain. If you want 14:43.520 --> 14:48.960 more details, there's link here that gives you a nice overview of what the set of your protocol 14:48.960 --> 14:57.440 might be. So this is, sorry, wrong direction. This is the right direction. This is the graph 14:57.440 --> 15:03.760 I was talking about from Cloudflare. We can currently see 58.3% and there's been going up steadily 15:03.760 --> 15:11.520 over the last few months really. So one thing that we've now talked about, is encryption, 15:11.520 --> 15:18.720 but did you know that the EU by the end of 2030 requires all software updates to be post quantum 15:18.720 --> 15:23.920 safe and have a PQC signature? Like we guess open source community can say we don't really care what 15:23.920 --> 15:30.240 the EU wants, but there are like commercial entities with certainly care and I like have to work for 15:30.240 --> 15:36.960 one of them. So that remains relevant for me. One of the things that we clearly do sign a lot 15:36.960 --> 15:46.640 are RPMs. Now the RPM packages that we sign today for example in REL, they will still be used 15:46.640 --> 15:52.160 in 10 years and I don't today want to make about that in 10 years, nobody has built a quantum 15:52.160 --> 16:00.160 computer. So this is why we're doing this transition. So there is an open PQP draft available that's 16:00.240 --> 16:07.360 specifies the use of post quantum cryptography. Unfortunately GNUPG has forked the standard in 16:07.360 --> 16:13.840 is now following Libre PGP and both of those do not currently have post quantum signatures. 16:13.840 --> 16:19.600 They have post quantum key exchange, but not signatures. But there are implementations that are 16:19.600 --> 16:26.240 working on getting the open PGPPQC implemented, notably Sequoia and a few others. I'm going to 16:26.240 --> 16:34.880 focus in Sequoia now. I'm going to show you a quick demo of Sequoia PGP with a PQC 11 backend 16:34.880 --> 16:39.120 which is important because you want your signing key to be inside of a hardware security module 16:40.320 --> 16:45.440 because I don't have a hardware security module with me. I'm going to use a software token 16:45.440 --> 16:50.240 that supports post quantum cryptography and that is cryoptic which is based on open SSL. 16:51.120 --> 16:57.280 So let's see, it's a video, but I could run this locally. The demo you're seeing is essentially 16:59.120 --> 17:07.440 me recording this automated thing. So ASQ Crypto Key is the way to manage the token and here I'm 17:07.440 --> 17:15.440 telling it to create an MRDSA ED25519 key on the cryptographic token. That is done. 17:15.920 --> 17:22.960 I can show the contents of the token. We can see this is a cryoptic token. That's a software token 17:24.240 --> 17:30.800 and it's called PQC Test token. If you scroll further down we can see the PQC Test key. 17:31.440 --> 17:40.400 This is the MRDSA part, as seen by the key type, CKK MRDSA here. There's also an EDSA part that I'm not 17:40.400 --> 17:46.640 showing. We can inspect the public key. We can see that the public key says yes, it's an MRDSA 65 17:46.640 --> 17:51.680 and ED25519 key. I'm importing that into ASQ setting. He's a later for signing. 17:52.960 --> 17:59.280 And now I need to configure RPM sign so that it knows that to use Sequoia and to use that 17:59.280 --> 18:07.760 particular key. Look how fast I can type. I need to actually sign an RPM. I don't have 18:07.760 --> 18:13.120 one so I'm just downloading G-lip C and we'll see in a second that this copy of G-lip C currently 18:13.120 --> 18:20.560 has an RSA signature made by the fedorarchy and I'm going to add an MRDSA signature. So this is an 18:20.560 --> 18:27.840 OpenP2P version 4 RSA signature and now the RPM sign on that it's prompting me for the passphrase 18:27.840 --> 18:37.520 of the PQC's 11 token and now I have an OpenP2PV6 MRDSA signature on that particular RPM. 18:38.720 --> 18:47.920 Right. That's the demo. So in summary, like we've seen using hybrid crypto provides defense 18:47.920 --> 18:55.120 in depth and using X25519 with MLK for a key exchange is our defense against harvest now 18:55.120 --> 19:00.640 decreplated. This is clearly the priority. We should update all the protocols that do encryption 19:00.640 --> 19:09.760 and do a key agreement to do to this. TLS 1.3 is essentially ready even though it's not a 19:09.760 --> 19:16.880 finalist RFC yet but it's pretty close. So people are starting to implement it. SSH in open 19:16.880 --> 19:22.240 SSH also has it, lib SSH is working on it upstream so that will also ship soon. 19:23.680 --> 19:30.560 There's no PQC signing in SSH yet but somebody has also started an ITF draft for that already. 19:31.040 --> 19:35.600 There is some global momentum in this. Like we've seen that 60% of the human TLS traffic going 19:35.600 --> 19:43.680 to cloud for a already uses hybrid key exchange for PQC and for the supply chain signing we actually 19:43.680 --> 19:51.200 have an answer today even though it's a bit hard to deploy at the moment but we have an answer 19:51.200 --> 19:56.640 by the time that it will be required. With that, thank you for your attention. Are there any questions? 20:00.720 --> 20:08.400 Hi guys, thanks very much for that. It's very interesting. We manufacture 20:08.400 --> 20:12.960 committed systems, connected devices so this has been a worry of mine for a while. It was great 20:12.960 --> 20:16.560 to see that you commented on the fact that what we ship today which might be in the full 20:16.560 --> 20:22.320 of 10 to 15 years has to be CRA compliant. My concern is how do we make sure that we're quantum 20:22.320 --> 20:26.480 safe now and in the future. A quick shout out and a question if I may 20:26.800 --> 20:32.640 create a meta-quantum safe for youcto to try to play with LibOQS to look at the algorithms 20:32.640 --> 20:36.960 and what we could do on different platforms. I'd love people to come and join me and see what we 20:36.960 --> 20:42.320 could do with that. On more deeply embedded systems with our classes we're seeing the TPMs and 20:42.320 --> 20:47.920 secure elements are coming out which talk about quantum agility and are starting just now to have 20:47.920 --> 20:53.600 quantum safe algorithms. This seems to be problems without having trouble fitting those algorithms in. 20:53.600 --> 20:58.320 I'm really concerned about what happens if we lay down hardware today and in a year or five 20:58.320 --> 21:03.760 years or whenever find that we have to do something else. How do we be compliant with the 21:03.760 --> 21:07.040 security legislation if the hardware doesn't do what we need it to do? 21:10.560 --> 21:15.520 So this is a pretty long question. I'll try to summarize my answer to this. 21:16.560 --> 21:22.000 So there's a long road ahead of us. There are many standards to be updated. You mentioned TPM, 21:22.000 --> 21:28.640 right? There will have to be updated standards. Once the updated standards are roughly done 21:28.640 --> 21:33.200 there will have to be updated implementations. Those updated implementations will have bugs. 21:33.200 --> 21:38.240 We will have to test for those. We have to ship all of those because like all 21:38.240 --> 21:44.880 they're not everybody runs fedore on updates that operate in system twice a year. So that's 21:44.880 --> 21:51.120 essentially why we're starting now. We have some time but if we don't start with this now 21:51.280 --> 21:57.200 then we may find ourselves in a timecrunch eventually. Speaking to liberal QS, 21:57.200 --> 22:03.760 we've actually started out with that but we've seen that there's not a lot of momentum in getting 22:03.760 --> 22:08.880 it shipped everywhere and people are more moving towards native implementations in the 22:08.880 --> 22:15.680 cripple libraries. So feels like liberal QS is not the way to go for the future. It's great as a 22:15.680 --> 22:20.720 testing tool. Great for testing especially the hybrid algorithms that are not completely 22:20.880 --> 22:26.000 specified in done yet. For example for X5 and I in certificates but I don't think it's the 22:26.000 --> 22:35.440 right tool for production use at the moment. I work very closely with the TLS working group and 22:35.440 --> 22:41.120 you in the beginning of your talk you mentioned that it's obvious that the like the hybrid is the 22:41.120 --> 22:45.920 way to go but that's not really correct. So there are a lot of debates happening in the TLS working 22:46.000 --> 22:52.080 group that whether it should really be hybrid or whether it should be pure. You are creating 22:52.080 --> 22:57.600 extra complexity by just having that thing which will eventually really break. What's the benefit 22:57.600 --> 23:02.880 of doing that? So I don't think it's a solved problem so there are still some debates going on 23:02.880 --> 23:07.600 and there is in addition to the draft that you are mentioning there is another draft which is pure 23:07.600 --> 23:14.800 post quantum and that's already near to publication and I mean the statement that you made 23:14.880 --> 23:22.480 it's obvious is really incorrect. Yeah I could acknowledge that and I have also seen a lot of 23:22.480 --> 23:29.680 debating threats where people are just asking why not just pure ML pure PC algorithm instead of hybrid 23:29.680 --> 23:35.520 because it obviously introduces more workload on the TLS handshakes that was also one of the 23:35.520 --> 23:42.880 factors but the thing with ML came or precisely the pure PCL algorithm is that these are pretty new 23:43.840 --> 23:51.680 having said that there are so no known threats or adversaries identified yet on the new PCL 23:51.680 --> 23:57.440 algorithm that's why we thought let's combine both. We as in whole the community is working on 23:57.440 --> 24:05.600 combining both so that it doesn't break the one. So when PCC is maturefully for our systems then 24:05.600 --> 24:11.600 we can probably think of pure PCC in the near future. Like Laman said this is the right time I think 24:11.600 --> 24:18.000 we need to start testing our systems to know how it works with the PCL algorithm and then gradually 24:18.000 --> 24:28.880 we can move over the pure PCC. We have time to ask question. Can you see a word about the next 24:28.880 --> 24:37.680 Etsy pointing time meeting worldwide next June in Ottawa? Sorry can you repeat the question? 24:37.680 --> 24:47.520 Etsy? Yes. ETSI is a worldwide meeting about these subjects meeting on a regular basis and 24:47.520 --> 24:51.360 the next one is in Ottawa in June. Can you say a word on that? 24:51.360 --> 25:03.600 So I'm not personally involved in doing any of the standardization like I'm a product owner. 25:03.600 --> 25:14.160 I have people that actually do the technical work but so my concern here is like Etsy and 25:14.160 --> 25:21.280 ITF don't seem to fully agree on who should specify hybrid X5 and I certificates and in which 25:21.280 --> 25:28.480 particular form. So I'm not going to get involved in that and let the people that are experts 25:28.480 --> 25:33.680 in standardization figure it out and then we'll follow what makes sense. Thank you very much for 25:33.680 --> 25:36.720 your presentation.