Flock 2026 Post Quantum Cryptography For Fedora Infrastructure

Okay, thank you everyone for coming here. [clears throat and cough] We are going to get through the current state of the um post postquantum transition [sighs] looking at what Fedora needs and where Fedora stays in in this transition plan. And I must say that part of this work was um and is being supported by the European uh commission funded um research project. It's called QR. It's um postquantum initiative that tries to get the um um application level prepared for like quantum computers future. And uh we are both from Red Hat represent different functions in Red Hat. I'm working with the identity management uh things and Jakob is working on the crypto side and with the actual crypto libraries and um SSH lia SSH and all the things there. So the cryptography relevant quantum computers they are not there yet at least there is a debate when they will be there and the interesting thing is that the um estimations were like okay 30 2035 then 2030 then Google this year bump it down to 20 29 and that's like merely three years left on their estimation. Even if the estimations are incorrect and too aggressive, that still means that we are less than 10 years away from the original estimation and uh there's a lot of activities around it. So IBM for example on June 2nd announced that they will get like 10 billion into building up around the quantum computing and the um real answer is that the um policies the the governmental policies change as well and the deadlines like loom towards the commercial vendors and for many commercial vendors they rely on open source software. So [clears throat] this indirectly pushes the open source projects which might not be having resources to do all of this. Um and the numbers like you see here uh what it is this December uh 2031 is when all the postquantum algorithms are effectively required for all commercial usage uh in the governmental sector in US except documented exceptions and exceptions is basically really on a one to one like base for view. Everyone has to to be postquantum and um there's a really like existing attacks already. We know that there are existing actors maybe state actors maybe non-state actors that are collecting data over internet in a in a hope that they will be able to decrypt it. a lot of data being collected because it's uh its value is beyond uh decades. For example, your medical records, your actual um property ownership deals that can be then uh modified if they were able to crack all the certificates that or signatures on them and put something else. So, somebody else will be owning your mortgage for example. But there's also another problem as everything is software now. The software being sign it when when it's delivered for example on the mobile phones it's it's the thing um but it's also the thing in the Linux distributions if you're able to crack the keys with which your packages sign it you get uh in trouble because somebody can install malware effectively. So we need to be prepared for that. And then obviously the public key authentication if somebody is able to take over your old keys they will be able to login where your keys are there. And for us this is this means that there are multiple ways of kind of uh addressing this. Some of them have nothing to do with the postquantum stuff. Um they are protocol changes. they are like rotating keys fast enough and so on. These are the things that um need to be taken into account as well. [snorts] And um this is what we see in the market. There are two big directions. One of them is hey let's reduce the amount a cryptographically relevant token is used. Let's say we use we issues a certificate for five minutes and you can log into the machine with that SSH certificate for five minutes only. That's kind of ideal case but there's a churn of issuance things. The other one is let's switch to algorithms that so far we know they are resistant but we don't have the full proof but there's like a faithful hope that they are resistant to those attacks and a part of this is the algorithms that we use need to be able to plug in into the protocols and we spent how much like five years already doing protocol agility work replacing um updating new RFCs and so on for a lot of protocols. So with the um shorter lifetimes and purposes, there's a bit of drama happening now um in the um in in the um uh browser world. So in the browser world is basically um CA browser forum. Uh they they go with the redu reduction approach. So reducing the lifetime of the certificates, reducing the purpose of those certificates um to to the point that for example public CAS are asked to only have a single CA chain to issue certificates that are trusted by Google Chrome by default. You can install you know your own CA chain, right? Um but for the public ones there is only a single one now per each public CA. Before that there was like two three uh CA chains from the same same one. Um and the other part is that um Google decided that they will not allow to public CAC issue postquantum um enabled traditional certificates because they become unwantedly large and it's hard to handle all this thing and the churn of those certificates every days uh will create a lot of traffic things. So they started looking into something that they call Miracle 3 certificates which is still being um in the work and then let's encrypt already announced it as a public CA that they will get this Miracle 3 certificate in production next year and in staging environment late this year. They are not saying the dates because it's obviously contingent on when they implement and when the standardization happen. Fedora has nothing to do uh or let's say has no software to do that and not only Fedora actually there's none in in open source implementations and the um procedural approach is kind of interesting if you look into the requirements to public CAS they are constantly reducing the amount of renewal time you go now so now it's 200 100 days in 2029 it will be 47 days. So every certificate you have with the website will be 47 days at most and it will have to be rotated within the week of its own um time ending. Imagine the amount of uh automation you would need to to have in place the automation by default effectively which is not the case. still not the case. Then on the software side is basically there's one giant protocol acne that's used to cover this and it's more or less understood since uh when let's encrypt introduced it in tw 2012 I think um that it's it's the way to go. There's a lot of extensions. There are more than 20 RFC's that um cover extensions of the AGMA protocol. Two interesting ones is this ARI and STAR. The STAR is short-term automatically renewed ones where the server basically renews and you're picking up renewed one. So you don't need to know Acme protocol. You just need to know where to retrieve already renewed one. That's a good one for dumb clients. The other one is the acme renewal information which is basically driving the acme client to pick up from uh correct intervals and so on self adjust based on that stuff and in Fedora we have sort monger for nonac stuff. So we have a fairly good coverage on of this. None of this predicates which type of certificate will be delivered. that's specific to to kind of specific CA and Merkel tree certificates is one of those that just got the um fourth draft released last month. Yeah, nobody supports it. Hopefully let's encrypt will do implementation by end of year and the demo software from the public CAS like um I think what was there Diggyert for example that the Fedora is using for its own public search um they have like maybe 40% of the draft one implementation in their playground software the difference between draft one and draft four is they are binary incompatible. So you cannot use that implementation again no support in Fedora. So what we did is part of this work is the new ACMA server and ACMA client that among the other things implements the Merkel tree certificate and I will try to be faster and show you the actual demo. This is running on the same machine. So it kind of over local host uh spawns the ACMA server and then retrieves the Merkel tree certificate out of it. There's a lot of data there because it's it's using this with the um postquantum algorithms. So you can see that I have a CA with the postquantum MLDDS87. I'm asking for MLDDSA65 um certificate and it's using the different algorithms just for the like showing the difference um on it. So the um the actual certificate size is like 3 kilobyte. Um this is 10 times or seven times more than um traditional RSA um you see DSA the format itself while it's X509 kind of wrapper the internal structure is different. So you can see for example the issuer is completely different thing the um log numbers index entries and then signature algorithms are different and so on. There is this public key that includes like 15k um bits in it. That's the big one. And um one thing that is important here it includes this Merkel tree certificate proof. So I don't need to have a a CA certificate step to it to to do the um validation of it. That's all information I need plus some base kind of detail and um I can retrieve that base detail and this is this is the row height. So we deal with what we have in row height with the Python. >> Yes, there is a patch but it's not built yet. And yes, um and then we can do a validation against that one. And I cut it down to basically yes, the um [snorts] the client side software did the hash calculations and did the match of the of the certificate against what it retrieved from the actual CA um for this one. So if we look at this thing in uh opensl the open SSL couldn't be even able to parse this because it doesn't know how this thing goes but of course because this is SN1 kind of outer shell the outer shell can be seen and some some data this is the public search thing. Um so let me get um to the point that you can test this in copper. Um it's in a usable shape but to bring this to Fedora we need to build some Rust packages and do normal Rust uh all normal new package process. [clears throat] So I I I want I want to see volunteers to help with this. Thank you. um but it will take some time to bring this in. Um so this is was the demo. Now um from the um postquantum side we have um two big groups here. So the there is this key encapsulation part and I will be fast on this one so that the there is something Yellen can talk about. Um and uh performance-wise it's not that bad. Um compared to the uh uh classic crypto there is like maybe 25% overhead. Most of these overhead will be eaten by the um other latencies in the process. But of course this is increasing the um need for compute a bit and also for the bandwidth stuff. But interesting that for example the P256 is slower than the um ML ML Cam 768. The other part is the signatures the digital signatures. This is significantly worse in terms of what it is. Look at these ones. These are not bits. These are bytes. the public key sizes, the private key sizes, the signature sizes are 10 to 15 to 20 times larger. That's what we will have to deal with. It's for hardware vendors. This means an expansion of the hardware storage requirements. uh for um any software that stores these things like public keys, it's an expansion of not only storage but also indexing and searching through th those things. You you literally start seeing the effects of it. And um the um the problem is that while this one ML cam and specifically hybrid ML cam is supported for TLS connections in in most browsers nowadays and even um I think it's already uh above 50% use in the mobile uh browsers because it's aggressively pushed by the um browser vendors with automatic update to the new versions of those browsers. This one doesn't really work in in in the browser. So, Firefox has no support for MLDDSA. So, you cannot authenticate with a certificate or accept MLDDSA certificate enabled ser uh site. The chromium in Fedora doesn't support either. I've been told that the uh Chrome Canary build which is like alpha alpha is able to support MLTSA certificates but not the um the other things and um signing so issuing certificates is expensive roughly 15 to 20 times compared to the ECDSA. Uh verification is fast. So verification is within two times of ECDSA and actually faster than RSA. That's the interesting part. Um this is comparison for example for our Acme server. We able to do um relatively within the same like six to 10% issuing certificates. The Acme the whole process is a more complex. So we can amorticize there the cost for this one. And for the OL stuff, it's more interesting. OL is like about the same um maybe 10 times uh in the worst case um performance-wise. But these tokens you have to still store them somewhere. And this is on the um right side from your point of view. uh the token sizes are blowing up. So something doesn't fit into cookies for example, you can only use them as bearers. So applications will have a lot of trouble with that. And this really affects everyone. So let's switch now. Okay. So uh sorry Alexander already mentioned that uh you are probably using uh postplanum crypto cryptography in TLS connections in your mobile browser in your computer browsers if the server is uh already updated to something that supports it. uh but the issue is that uh both client needs to be updated, server needs to be updated and only TLS 1.3 will be supported because this won't go back to the older uh TLS versions. Um if you are using SSH and you've got again updated client server, you are already using hybrid key exchanges uh with MLCAM or the other. There are links to the drafts and RFC's that are already published. Uh signatures are still being standardized and I heard uh just before the meeting that uh Open SSH finally merged some uh experimental support for MLDDSA signatures hybrids ones. Okay. So you can look forward that very soon hopefully. uh but this also affects the sign signed content signed upstream uh tarballs uh I will go get to that later but there is some mismatch with the standardization if you are familiar there is the open PGP standard that is being almost finalized and there is the library PGP and then there is mess there are containers that can be signed using these and uh if if you are lost in is uh how to manage it, how to make sure that you are using postquantum crypto or not. You should look into the crypto policies if you don't know what is it. Check it out. It's it's nice. You can basically switch with one switch enable disable postquantum old algorithms when RSA will become broken. There will be just like in theory one switch that you that we will flip or you will flip and uh you will be hopefully safe uh systemwide. Okay, so there are the compatibility issues with the TLS 1.3 that MLDDSA cannot have the channel binding that's unspecified. That's a problem for GSS API. If you want to know more, talk to Alexander. I don't know this. [laughter] uh mutual TLS uh has also issue because you have you you need larger TLS buffers if you want to chain couple of the couple of certificates the buffers go can grow to 50 50 kilobytes and that's something that doesn't fit into all the places where you have to push them through such as uh mod proxy and Tomcat so this is another stuff that Alexander figure out by trying >> we we found out that for example with the smallest sizes like MLDDS844 um the size of TLS buffer is um within the 8 kilobytes but if you put like MLDDSA 65 which is larger but it's a it's a medium one you get one bite past that buffer size and everything breaks and finding out these problems uh is almost impossible with without like analyzing and in instrumenting the debugging things because it's TLS 1.3 it's forward secrecy you cannot really see what's happening other than failures >> okay one more thing about compatibility is the open PGP uh there is the open PGP standard that is being developed that support postquantum cryptography that I already mentioned but there is Um, Federra is already using the late well Federra is not using the latest open PGP standard but we have some work in progress but there is the GNU PG that doesn't support open PGP standard and they develop their own standard that is incompatible and that's something that we will see a little bit more of in the future. We already saw that like the large uh RPM signatures using MLDDSA that we do in real broke on old old RPM because old RPM had some artificial limit. Well, I don't I don't say artificial but some limitation of the of the size of the header that can be and if it was over it just exploded. We had uh like half a year ago we had issues that Fedora RPM wasn't able to uh eat the uh RPM signatures with MLDDSA keys because it didn't understand them. This should be fixed. Uh I already talked about it with Fabio that that should be fixed. That should be working now. And back to Alexander. >> I will be very short here. So we have finally got the uh bits and pieces for free APA to issue MLDDSA based certificates that included a whole stack of the things there. There was a lot of problems upstream. So for example, it took four months to get the um Python cryptography to merge a basic support and four months before that to develop that basic support. So like eight months on it. uh and the Python cryptography is more advanced at once in in accepting AI generated contributions. They actually regularly develop with um AI tools all of these things and they are the the Python cryptography is Rust. So it it benefits a lot from from the AI stuff. But we finally have this thanks to Jeremy Klene who is doing talk next to us um at the same time. um for getting this in Fedora like three weeks ago. We are we there we can do it. The standardization moves really slow and as you can see no time there but nothing is standardized fully yet. There's a plenty of things that has to be worked on. We aim to get some prototype for Kerber stuff at the IETF next um month. Um, so I will go with the things that already exist in Fedora. This is all supported on the crypto library side. So you're safe. Um, the language is more or less there. Go will get 127 will release in August. Hopefully we will get MLDDSA support there. Uh, Python standard library supports already the TLS connection through OpenSSL. Uh we have on the rust level few crates that do have support for um postquantum stuff and then this is the library that we base all new stuff on that is using either NSS or OpenSL and natively supports all the uh postquantum things. This is I'm skipping these slides will be available the uh things available in copper. I cannot do the demo unfortunately because I'm out of time. And a lot of stuff is left. What I want you to do is call for action slide. This is basically what you as open source contributor could do. You can help your own upstreams. You can help distributions. You can help by testing. You can help by helping to develop protocol changes where you know they are not ready yet. Publicize, test, help to change. help be prepared because amount of work is not something that even a single company can cover. It's the fundamental industrial act. Thank you.