WEBVTT 00:00.000 --> 00:12.040 Thank you for coming. I want to talk to you today about Fedora's road to post quantum 00:12.040 --> 00:19.120 cryptography and I am the product owner for the real crypto team and the real crypto team 00:19.120 --> 00:23.320 also happens to maintain a couple of the packages that are relevant in what I'm about 00:23.320 --> 00:29.960 to talk to in Fedora. So that's the reason why I sort of know a few things about this 00:30.000 --> 00:36.720 this if you've never seen one is a quantum computer this particular model built 00:36.720 --> 00:41.280 by IBM the actual chip that does the computation sits at the very bottom that I 00:41.280 --> 00:46.840 cut off down here and it's super cool to a fraction above zero Kelvin meaning 00:46.840 --> 00:50.960 essentially this thing I think I heard a number costs about a million to run 00:50.960 --> 00:58.240 just due to the cooling and power requirements a year. So suffice it to say 00:58.240 --> 01:06.320 nobody will have one of these in their home anytime soon. The thing to know about 01:06.320 --> 01:11.440 quantum computers is that they are probabilistic which means they they give you a 01:11.440 --> 01:15.840 result with a certain probability if you run the exact same computation again it 01:15.840 --> 01:21.320 might give you a different result but again with a with a probability say you run 01:21.320 --> 01:27.640 things multiple times and hope that the probability distribution is such that the 01:27.640 --> 01:34.160 result you get most often is actually useful to you. At the moment the because 01:34.160 --> 01:38.360 they are probabilistic they also have error rates and the error rates and the 01:38.360 --> 01:43.600 sizes of the quantum computers that we have right now are not actually large enough 01:43.600 --> 01:50.800 to be dangerous to the cryptography that we are currently using. So that essentially 01:50.800 --> 01:57.440 means for now we're kind of safe right the question is how long did I get to that. 01:57.440 --> 02:04.920 So that was a quick intro to quantum computing and I want to get into how that 02:04.920 --> 02:08.920 relates to cryptography and what that means for us so that harvest now 02:08.920 --> 02:13.200 decreplated largely may have heard that already but I have more details on it in a 02:13.200 --> 02:18.600 second. Then we look at what are the timelines and actually moving to post 02:18.600 --> 02:22.800 quantum cryptography and then the end I'm I'll talk a bit about a few specific 02:22.800 --> 02:26.880 protocols and I have an outlook on all the other protocols that I will not 02:26.880 --> 02:33.640 have time to talk about. So in cryptography there are essentially three large 02:33.640 --> 02:38.000 types this is a bit of a simplification but bear with me for now we have 02:38.000 --> 02:44.160 symmetric cryptography that shares a key so you have multiple parties and they 02:44.160 --> 02:49.960 share the exact same key typically symmetric cryptography is super fast that's 02:49.960 --> 02:55.760 for example AES and we use it for bike data transfer and is if your key sizes 02:55.760 --> 03:02.160 large enough safe against quantum quantum computers so there we don't have a big 03:02.160 --> 03:06.960 action item and AES will be fine to be used in the future and then there's 03:06.960 --> 03:11.280 asymmetric cryptography and that is actually the part that quantum computers 03:11.280 --> 03:17.120 can efficiently attack. Those fall into two categories key establishment and 03:17.120 --> 03:22.520 signatures key establishment is used whenever you have two parties that try to 03:22.520 --> 03:27.440 establish a secure channel between each other to then use symmetric cryptography 03:27.440 --> 03:34.240 to transfer some data and this is vulnerable to passive attackers with quantum 03:34.240 --> 03:40.360 computers so people can do is if they're sitting on the wire see your 03:40.360 --> 03:44.960 connection the key exchange that's ongoing and then use the passive snooping 03:44.960 --> 03:51.040 from that to attack you with a quantum computer as opposed to signatures which 03:51.040 --> 03:55.640 cannot be attacked passively by quantum computers or they need an active attacker 03:55.640 --> 04:00.920 in other words at the moment if somebody is talking about attacking something 04:00.960 --> 04:05.120 with a quantum computer because there is no large enough quantum computer at least 04:05.120 --> 04:09.320 that we know of they are meaning to attack the key establishment because that 04:09.320 --> 04:15.240 can be done today and that is sort of the next slide so nobody has a quantum 04:15.240 --> 04:18.680 computer that's large enough to do any of this at the moment what everybody 04:18.680 --> 04:25.560 has is lots and lots of storage and probes on fiber cables only not saying 04:25.560 --> 04:30.680 that this particular NSA data send a new data is exactly that but they also if 04:30.680 --> 04:34.960 you asked them they won't really tell you what it does right so the entire 04:34.960 --> 04:41.200 idea is here a three-letter agency and it doesn't necessarily have to be the US 04:41.200 --> 04:45.240 one there are many others on the world right they will store your encrypted 04:45.240 --> 04:49.720 communication then as soon as they get their hands on a large enough quantum 04:49.720 --> 04:54.280 computer they will break the key exchange that gives them the symmetric key and 04:54.280 --> 04:58.920 with the symmetric key they can then decrypt the communication that they have 04:58.920 --> 05:03.880 also stored and suddenly what you believe was transmitted in an encrypted 05:03.880 --> 05:09.440 fashion is plain text for them right and that could be passwords which you 05:09.440 --> 05:13.320 might have changed in the meantime but it could also be like medical records 05:13.320 --> 05:17.800 and it's you will find it kind of hard to change your medical history right 05:17.800 --> 05:21.800 that kind of thing goes with you and depending on what's in there that could 05:21.800 --> 05:26.840 for example be used to blackmail you right and that's an unrealistic scenario 05:26.840 --> 05:33.560 that a three-letter agency might be interested in so let's look at how quick 05:33.560 --> 05:39.120 we need to do things there are two points of views on this the one is kind of 05:39.120 --> 05:44.240 from a regulation point of view and the other one is common sense so from a 05:44.240 --> 05:49.200 regulation point of view the US depending on your use case once post quantum 05:49.200 --> 05:56.120 cryptography somewhere between essentially yesterday and 2030 now I would argue 05:56.120 --> 06:00.120 we're in Europe here given the current state of the US administration we 06:00.120 --> 06:04.600 should not particularly care what the US wants so like this is a problem for 06:04.600 --> 06:10.600 realm but for fedora purposes let's just ignore it the EU has also some rules 06:10.600 --> 06:15.640 on this where they say for high risk use cases I haven't actually looked into 06:15.640 --> 06:20.440 the definition they want this to be completed by 2030 but also interesting they 06:20.440 --> 06:25.400 want software updates to be quantum safe by the end of 2030 and that is 06:25.400 --> 06:30.320 interesting because that's not encryption right that is for signatures so that's 06:30.320 --> 06:36.800 the first real hard timeline for signatures I would say and like I picked out 06:36.800 --> 06:42.480 the US in the EU but essentially every country around the world that has some 06:42.480 --> 06:46.560 documentation on when they when they want this some with most specifics some 06:46.560 --> 06:50.320 with less specifics there's a link down here on the slides I'm going to upload 06:50.320 --> 06:53.520 them later if you want you can check that out to get the picture for your 06:53.520 --> 07:00.040 country now I would say like fedora we're an open source product the EU can 07:00.040 --> 07:03.960 can want many things why should we care like we don't have to comply with 07:03.960 --> 07:08.560 that for us let's just do with a common thing since thing and and I have 07:08.560 --> 07:13.040 this on this slide essentially time moves down on this slide and you have two 07:13.040 --> 07:18.880 ticking clocks the one on the left is the time you will need to do that 07:18.880 --> 07:23.960 transition fortunately for fedora like we release every six months and we only 07:23.960 --> 07:28.680 support a release for one year so that means we get a new chance for every 07:28.680 --> 07:33.840 year to ship some new software so for us the time to transition can be reasonably 07:33.840 --> 07:39.320 short like enterprise distros have this problem debyan supports the release 07:39.320 --> 07:44.040 for much longer you want to they will have a much longer transition time line 07:44.040 --> 07:48.440 then then fedora for example has and then you need to add on top of that the 07:48.440 --> 07:52.760 time that you need to your data to stay secure and that just really depends on 07:52.760 --> 07:57.360 what kind of data you process on there and you transfer from that machine right 07:57.360 --> 08:01.720 so that's something I kind of give you a number on that but I also kind of give 08:01.720 --> 08:05.840 you a number on the other bar in here the time to build a quantum computer and 08:05.840 --> 08:11.600 even when somebody managed to build a cryptographically relevant quantum 08:11.600 --> 08:18.320 computer they might not tell you so there's sort of a lot of fuzziness around 08:18.320 --> 08:22.640 that timeline and really the the question that we're asking ourselves today is 08:22.640 --> 08:27.680 like are we making a bad today that in 15 years nobody will have built a 08:27.680 --> 08:33.680 quantum computer that's large enough it might never happen even but still at the 08:33.680 --> 08:38.600 moment we need to get the work started to make sure that in 15 years we're not 08:38.600 --> 08:43.640 using anything that's that's susceptible to attacks and if we don't do the 08:43.640 --> 08:47.800 work now that means we make about that 15 years nobody has built a quantum 08:47.800 --> 08:52.400 computer that's not about I want to make which is why I'm working on this 08:52.400 --> 08:58.480 transition okay so let's move to protocols and this is where we're getting 08:58.480 --> 09:01.920 out of the gloomy section and into the look we're actually making some good 09:01.920 --> 09:07.640 progress here section so for TLS you need TLS 1.3 if you have stuff that doesn't 09:07.680 --> 09:15.520 talk TLS 1.3 your first action item is to get that updated but TLS 1.3 has an 09:15.520 --> 09:20.760 IETF draft out it's not an RFC yet but it should be relatively soon and 09:20.760 --> 09:24.440 everybody in the kitchen sink has started implementing it like open SSL 09:24.440 --> 09:30.640 genutial SS NSS and go in the current versions in fedora already support the 09:30.640 --> 09:36.360 key exchange using MLKM so that's safe against quantum attacks and open SSL 09:36.360 --> 09:42.200 genutial SSS also support signatures using MLDSA already that's also quantum 09:42.200 --> 09:49.680 safe note here though hybrid signatures actually something that is not yet 09:49.680 --> 09:56.680 supported in in fedora so X5 and I certifies this standardization on going how 09:56.680 --> 10:01.000 the hybrid certificates are actually going to look like and it seems like the IETF 10:01.000 --> 10:06.040 and the Etsy have different opinions and also not everybody agrees 10:06.040 --> 10:09.760 that hybrid certificates are even something that that should happen in the 10:09.760 --> 10:17.040 first place so there will be more time required here notably some of the work 10:17.040 --> 10:22.040 that we did to make this work in fedora was funded by the EU they have this 10:22.040 --> 10:27.040 horizon program where they fund post quantum transitions and a part of that 10:27.040 --> 10:32.240 was the QB project where Redhead and a few other partners from universities 10:32.240 --> 10:40.040 for example god money to show both a server and a web browser with support 10:40.040 --> 10:44.920 for post quantum key exchange in hybrid fashions and post quantum signatures 10:44.920 --> 10:50.760 in hybrid fashions so that's actually why fedora has had that for a quite a 10:50.760 --> 10:55.800 one now let's look at SSH the situation there's also actually quite good 10:55.800 --> 11:02.080 open SSH 10 0 added support for MLKM key exchange and they even had a 11:02.080 --> 11:06.720 different post quantum key exchange scheme before that we didn't enable by default 11:06.720 --> 11:14.560 in fedora but it was supported and so alternative implementations are also working 11:14.560 --> 11:18.640 on it already so lipis and sage I think the code is merged upstream now the 11:18.640 --> 11:23.600 maintainer just left because they had catch a flight but it should be released 11:23.600 --> 11:29.200 upstream soon and then we'll re-basit into fedora and we'll get that standardization 11:29.200 --> 11:38.600 is also ongoing for the SSH MLKM key exchange signatures so at the moment you 11:38.600 --> 11:44.320 can't really make all your SSH keys post quantum safe because nobody has a good 11:44.320 --> 11:48.600 idea on how that should look like so there's a draft ITF standard but it's 11:48.600 --> 11:54.400 nowhere near in the state where we can actually get that implemented right a 11:54.400 --> 12:00.720 short slight demo you can use your open SSH client and hopefully the open quantum 12:00.720 --> 12:05.680 safe project has a test server that offers every signature and key exchange 12:05.680 --> 12:10.760 combination under the sun 6195 just happens to be the one that comes within so the 12:10.760 --> 12:15.320 port number happens to be the one that comes with an MLDSA 65 signature and an 12:15.320 --> 12:21.600 X25519 MLKM 768 key exchange and we can actually see this working so this 12:21.600 --> 12:26.640 is done on current fedora 43 and it will actually be used by default if you're 12:26.640 --> 12:31.160 if the other endpoint support set like cloud fair for example has this rolled 12:31.160 --> 12:36.960 out widely already so you will get this key exchange and be safe against harvest 12:36.960 --> 12:44.480 now decryplated attacks on modern fedora good then remember that I mentioned the EU 12:44.480 --> 12:49.920 once quantum safe software and firmware upgrades enabled by default by the end of 12:49.920 --> 12:57.440 2030 and that brings us to what fedora uses to actually ship artifacts and RPM mostly 12:57.440 --> 13:05.000 and in these RPMs come with open PGP signatures there is an open PGP draft that is in 13:05.000 --> 13:10.360 the RFC editor queue so we're expecting it to become an RFC any day now that 13:10.360 --> 13:17.520 supports a post quantum cryptography it does support MLKM for encryption so 13:17.520 --> 13:22.960 a defense against harvest now decryplated but it also supports hybrid 13:22.960 --> 13:29.320 signatures unfortunately the most common PGP implementation 13:29.320 --> 13:34.920 a new PGP has now forked away from the open PGP standard into a 13:34.920 --> 13:41.120 libre PGP and both libre PGP the standard and new PGP the implementation do 13:41.120 --> 13:46.440 not currently support post quantum signatures and I haven't seen any plans of 13:46.440 --> 13:52.840 making that available any time soon either but fedora has been using Sequoia 13:52.840 --> 13:59.480 for a few releases already to verify the package signatures and there is a fedora 13:59.480 --> 14:05.760 a Sequoia pre-release available that has both post quantum support for MLDSA 14:05.760 --> 14:11.160 and SLHDSA and it has support for PGP-C11 which is important because you 14:11.160 --> 14:15.360 want your signing keys to be in a hardware security module and not somewhere on 14:15.360 --> 14:21.720 some server's disk so using that via PGP-C11 is good in that particular 14:21.720 --> 14:29.480 case and we also needed some changes in RPM because RPM now in the latest 14:29.480 --> 14:33.840 version 6 format supports multiple open PGP signatures so that allows us to 14:33.840 --> 14:38.760 have package signed with a classic RSA and then add the the post quantum 14:38.760 --> 14:46.320 thing on top I have a demo for you and that let's see what I can 14:46.320 --> 14:59.440 make it work and oh you can't see that right now right let me move that 14:59.440 --> 15:10.480 over I mean a little bit more font size would be a good idea right 15:10.480 --> 15:30.160 good so doing life demos doing life demos how am I time was 10 minutes okay 15:30.160 --> 15:44.760 that's a work must have rebooted my machine in the meantime good so this 15:44.760 --> 15:49.480 uses and I need to click into that window otherwise it's not going to work 15:49.480 --> 16:00.600 yes so ask you crypto key is a tool to manage keys on APKS is 11 token in this 16:00.600 --> 16:05.480 set up I'm using a software token because I don't have PC cable hardware attached 16:05.480 --> 16:12.400 to my machine you can see here that I'm generating an MLDSA ED25509 key that is this 16:12.400 --> 16:20.840 particular parameter here keys generated I can show the keys that are on the 16:20.840 --> 16:25.920 token you can see here at the top it says description cryoptic that's the software 16:25.920 --> 16:30.680 token implementation that I'm using that scroll down I we can actually see the 16:30.680 --> 16:37.080 PC test key here if you look at the I need to scroll down another night we see 16:37.080 --> 16:43.160 here key type C key key MLDSA so that's the post quantum part further down there's 16:43.160 --> 16:50.960 the the ED25509 part of this that I'm just gonna ignore for now we can take a 16:50.960 --> 16:55.000 look at the public key that was generated we see here the fingerprint string and 16:55.000 --> 17:02.680 below that says MLDSA 65 and ED25509 so it is a post quantum key reporting 17:02.680 --> 17:07.360 that particular certificate and now I need to configure my RPM sign 17:07.360 --> 17:10.960 implementation to actually sign with that particular keys I need to tell it to 17:10.960 --> 17:18.840 use SQ and then look at me type very fast I also need to tell it which which key 17:18.840 --> 17:22.840 to actually use and I need an RPM to sign it on have one so I'm hoping that 17:22.840 --> 17:29.280 in the network works because otherwise this demo is gonna break reasonably slow 17:29.280 --> 17:34.520 but it does go somewhere so now I'm downloading a copy of G-lip C from Fedora this 17:34.520 --> 17:42.320 will have an RSA signature we'll see that in a second it's actually really slow 17:42.320 --> 17:50.400 so and what we'll see after is that I sign this with the post quantum key and then 17:50.400 --> 18:03.120 after what it will have the the PQC signature yes yeah the RPM isn't super large 18:03.120 --> 18:10.880 but this is a container so if I run it with no refresh it will have no 18:10.880 --> 18:24.760 metadata there's a leg I was wondering what exactly actually let me like I get there 18:24.760 --> 18:31.520 like you have to just trust me on this that this is actually correct because I don't 18:31.520 --> 18:41.920 think I get to the end if I if I don't now I don't see can I close this please 18:41.920 --> 18:49.800 oh now it finished right so I can't press enter so we see the G-lip C here oh no it 18:49.800 --> 19:03.200 did actually fail so never mind the rest of it will fail as well so okay back to the 19:03.200 --> 19:15.560 slides so the demo gets I'm sorry a wood of work I trust me there's a video online 19:15.560 --> 19:21.640 as well we you can take another look at it so essentially had the demo work we would have 19:21.640 --> 19:30.280 seen that we can sign RPMs with PQP and have PQC keys but that's not really all there 19:30.280 --> 19:34.520 is to it and there's this long list of things we actually need to take care of in Fedora 19:34.520 --> 19:39.080 before we can roll this out like the tooling it's to support it we need an action hard 19:39.120 --> 19:44.440 security module to support PQC we need to generate the key distributed make sure 19:44.440 --> 19:50.360 everybody has it we need to consider bootstrapping new Fedora releases an older Fedora 19:50.360 --> 19:55.760 versions and that can't break and then their Fedora does not just release RPMs there's 19:55.760 --> 19:59.960 also containers flat packs of S3 images bootsy and probably more stuff that I'm not 19:59.960 --> 20:06.440 aware of and there's tooling out there the use new PG to parse public keys but that won't 20:06.520 --> 20:11.320 work because new PG does not understand these particular sort of keys and then there's also 20:11.320 --> 20:17.880 copper and apple so there's a long list of things that we still need to take care of before 20:17.880 --> 20:24.920 we actually make this a reality in Fedora and to add insult to injury like this is a list of 20:24.920 --> 20:31.320 random protocols that I'm wiggly aware of that use asymmetric cryptography and a lot of these 20:31.320 --> 20:36.920 will probably have to have updated standards updated implementations and fix the bugs in those 20:36.920 --> 20:41.560 new implementations and then they need to have upstream releases and be shipped in Fedora 20:41.560 --> 20:47.640 and hopefully have some kind of backwards compatibility to the huge road of work ahead of us 20:47.640 --> 20:54.040 and if you maintain any of these then just you know reach out and I can probably give you a 20:54.040 --> 20:59.160 couple of pointers I can't do the work for you because this is just too many like the crypto team is 20:59.240 --> 21:04.280 large but not large enough to take care of all of these and with that we have some time for questions 21:05.640 --> 21:09.480 yes 21:29.160 --> 21:45.480 so the question is like we've used this the classic cryptography algorithms for years we know 21:45.480 --> 21:50.440 the secure we've learned as the hardware that the post quantum stuff is reasonably new 21:51.320 --> 21:56.840 should we use hybrids and in this I guess that PQC stuff even secure 21:57.800 --> 22:03.320 so one thing to be aware of a lot of this PQC algorithms that we now see shipped aren't super 22:03.320 --> 22:07.720 new like they've been invented ten years ago and mathematicians have looked at them 22:07.720 --> 22:13.720 it's still you're absolutely right we like there will be new implementation bugs just because it's new code 22:14.360 --> 22:21.320 so we should use hybrids of the existing classic algorithms and post quantum algorithms wherever possible 22:21.400 --> 22:27.240 we're doing this for the signatures we're doing it for key exchange like some people are 22:27.240 --> 22:32.920 like specifically the NSA has written a document where they say look this is not necessary just go 22:32.920 --> 22:38.840 for the post quantum thing at directly but I don't particularly trust what the NSA says that 22:38.840 --> 22:44.280 I'm not in ten people but are there okay any other questions yeah 22:44.520 --> 22:54.680 are the question is does unreleased new PQC have a signature support in PQC 22:54.680 --> 23:00.760 no not that I'm aware so 23:00.760 --> 23:08.360 lip G crypt has support for MLDSA but new PQG does not and to my understanding Werner who's 23:08.360 --> 23:12.200 maintaining that doesn't think it's currently necessary maybe there has changed in the 23:12.200 --> 23:19.240 last few days then I'm not aware of it but yeah okay let's maybe take a question from over there 23:21.240 --> 23:30.040 yeah the NSA not the ITF also gave it a thumbs up in Danford's teacher but the other question 23:30.040 --> 23:35.160 like these implementations are relatively new they've been like they've really we're 23:35.160 --> 23:40.280 reasonably sure about science and security so the question is are we reasonably secure 23:40.360 --> 23:47.560 about side channel security in those new implementations quick comment on the ITF thing that 23:47.560 --> 23:54.600 Bernstein widely publicized yes it sounds like the ITF agreed to have pure MLDSA but it's really 23:54.600 --> 23:59.720 just them assigning an identifier for the few people that want to use that and not endorsing it 24:00.440 --> 24:07.080 which I don't see quite as harsh as Bernstein does in terms of side channel security we're actually 24:07.160 --> 24:13.720 doing the testing like Red Hat has a few good people that are knowledgeable about statistics 24:13.720 --> 24:19.640 and putting the work into do the side channel testing on these it's easy concern but it's been 24:19.640 --> 24:29.080 taking care of John cap forum baseline requirements for the public internet TLS basically still does 24:29.080 --> 24:37.000 not have a MLDSA approved or even a ballot for it where do you see we're gonna when will we get 24:37.000 --> 24:42.680 there because privately in the door to show you the cap of a browser that does it but apart from 24:42.680 --> 24:49.640 internet that wouldn't be usable on the public internet for them so the question is when will the 24:49.640 --> 24:57.400 CA browser forum actually get the stuff together and specify what their requirements for PQC certificates 24:57.480 --> 25:05.240 is going to be I don't have an answer for that so my understanding is that Google is not a huge fan 25:05.240 --> 25:11.800 of the PQC TLS certificates because of their size so maybe they are coming up with an alternative 25:11.800 --> 25:19.000 implementation but I'm hoping that everybody else in the CA browser forum will prevail and at least 25:19.000 --> 25:24.920 get us MLDSA certificates relatively soonish and until that time unfortunately the best thing you can 25:25.560 --> 25:32.120 do is run it in your internet which really doesn't help us much but yeah I'm hoping that they will 25:32.840 --> 25:38.600 get this soon so we're out of time thank you for attending if you have more questions I'll be outside