Thank you for coming. I want to talk to you today about Fedora's road to post quantum
cryptography and I am the product owner for the real crypto team and the real crypto team
also happens to maintain a couple of the packages that are relevant in what I'm about
to talk to in Fedora. So that's the reason why I sort of know a few things about this
this if you've never seen one is a quantum computer this particular model built
by IBM the actual chip that does the computation sits at the very bottom that I
cut off down here and it's super cool to a fraction above zero Kelvin meaning
essentially this thing I think I heard a number costs about a million to run
just due to the cooling and power requirements a year. So suffice it to say
nobody will have one of these in their home anytime soon. The thing to know about
quantum computers is that they are probabilistic which means they they give you a
result with a certain probability if you run the exact same computation again it
might give you a different result but again with a with a probability say you run
things multiple times and hope that the probability distribution is such that the
result you get most often is actually useful to you. At the moment the because
they are probabilistic they also have error rates and the error rates and the
sizes of the quantum computers that we have right now are not actually large enough
to be dangerous to the cryptography that we are currently using. So that essentially
means for now we're kind of safe right the question is how long did I get to that.
So that was a quick intro to quantum computing and I want to get into how that
relates to cryptography and what that means for us so that harvest now
decreplated largely may have heard that already but I have more details on it in a
second. Then we look at what are the timelines and actually moving to post
quantum cryptography and then the end I'm I'll talk a bit about a few specific
protocols and I have an outlook on all the other protocols that I will not
have time to talk about. So in cryptography there are essentially three large
types this is a bit of a simplification but bear with me for now we have
symmetric cryptography that shares a key so you have multiple parties and they
share the exact same key typically symmetric cryptography is super fast that's
for example AES and we use it for bike data transfer and is if your key sizes
large enough safe against quantum quantum computers so there we don't have a big
action item and AES will be fine to be used in the future and then there's
asymmetric cryptography and that is actually the part that quantum computers
can efficiently attack. Those fall into two categories key establishment and
signatures key establishment is used whenever you have two parties that try to
establish a secure channel between each other to then use symmetric cryptography
to transfer some data and this is vulnerable to passive attackers with quantum
computers so people can do is if they're sitting on the wire see your
connection the key exchange that's ongoing and then use the passive snooping
from that to attack you with a quantum computer as opposed to signatures which
cannot be attacked passively by quantum computers or they need an active attacker
in other words at the moment if somebody is talking about attacking something
with a quantum computer because there is no large enough quantum computer at least
that we know of they are meaning to attack the key establishment because that
can be done today and that is sort of the next slide so nobody has a quantum
computer that's large enough to do any of this at the moment what everybody
has is lots and lots of storage and probes on fiber cables only not saying
that this particular NSA data send a new data is exactly that but they also if
you asked them they won't really tell you what it does right so the entire
idea is here a three-letter agency and it doesn't necessarily have to be the US
one there are many others on the world right they will store your encrypted
communication then as soon as they get their hands on a large enough quantum
computer they will break the key exchange that gives them the symmetric key and
with the symmetric key they can then decrypt the communication that they have
also stored and suddenly what you believe was transmitted in an encrypted
fashion is plain text for them right and that could be passwords which you
might have changed in the meantime but it could also be like medical records
and it's you will find it kind of hard to change your medical history right
that kind of thing goes with you and depending on what's in there that could
for example be used to blackmail you right and that's an unrealistic scenario
that a three-letter agency might be interested in so let's look at how quick
we need to do things there are two points of views on this the one is kind of
from a regulation point of view and the other one is common sense so from a
regulation point of view the US depending on your use case once post quantum
cryptography somewhere between essentially yesterday and 2030 now I would argue
we're in Europe here given the current state of the US administration we
should not particularly care what the US wants so like this is a problem for
realm but for fedora purposes let's just ignore it the EU has also some rules
on this where they say for high risk use cases I haven't actually looked into
the definition they want this to be completed by 2030 but also interesting they
want software updates to be quantum safe by the end of 2030 and that is
interesting because that's not encryption right that is for signatures so that's
the first real hard timeline for signatures I would say and like I picked out
the US in the EU but essentially every country around the world that has some
documentation on when they when they want this some with most specifics some
with less specifics there's a link down here on the slides I'm going to upload
them later if you want you can check that out to get the picture for your
country now I would say like fedora we're an open source product the EU can
can want many things why should we care like we don't have to comply with
that for us let's just do with a common thing since thing and and I have
this on this slide essentially time moves down on this slide and you have two
ticking clocks the one on the left is the time you will need to do that
transition fortunately for fedora like we release every six months and we only
support a release for one year so that means we get a new chance for every
year to ship some new software so for us the time to transition can be reasonably
short like enterprise distros have this problem debyan supports the release
for much longer you want to they will have a much longer transition time line
then then fedora for example has and then you need to add on top of that the
time that you need to your data to stay secure and that just really depends on
what kind of data you process on there and you transfer from that machine right
so that's something I kind of give you a number on that but I also kind of give
you a number on the other bar in here the time to build a quantum computer and
even when somebody managed to build a cryptographically relevant quantum
computer they might not tell you so there's sort of a lot of fuzziness around
that timeline and really the the question that we're asking ourselves today is
like are we making a bad today that in 15 years nobody will have built a
quantum computer that's large enough it might never happen even but still at the
moment we need to get the work started to make sure that in 15 years we're not
using anything that's that's susceptible to attacks and if we don't do the
work now that means we make about that 15 years nobody has built a quantum
computer that's not about I want to make which is why I'm working on this
transition okay so let's move to protocols and this is where we're getting
out of the gloomy section and into the look we're actually making some good
progress here section so for TLS you need TLS 1.3 if you have stuff that doesn't
talk TLS 1.3 your first action item is to get that updated but TLS 1.3 has an
IETF draft out it's not an RFC yet but it should be relatively soon and
everybody in the kitchen sink has started implementing it like open SSL
genutial SS NSS and go in the current versions in fedora already support the
key exchange using MLKM so that's safe against quantum attacks and open SSL
genutial SSS also support signatures using MLDSA already that's also quantum
safe note here though hybrid signatures actually something that is not yet
supported in in fedora so X5 and I certifies this standardization on going how
the hybrid certificates are actually going to look like and it seems like the IETF
and the Etsy have different opinions and also not everybody agrees
that hybrid certificates are even something that that should happen in the
first place so there will be more time required here notably some of the work
that we did to make this work in fedora was funded by the EU they have this
horizon program where they fund post quantum transitions and a part of that
was the QB project where Redhead and a few other partners from universities
for example god money to show both a server and a web browser with support
for post quantum key exchange in hybrid fashions and post quantum signatures
in hybrid fashions so that's actually why fedora has had that for a quite a
one now let's look at SSH the situation there's also actually quite good
open SSH 10 0 added support for MLKM key exchange and they even had a
different post quantum key exchange scheme before that we didn't enable by default
in fedora but it was supported and so alternative implementations are also working
on it already so lipis and sage I think the code is merged upstream now the
maintainer just left because they had catch a flight but it should be released
upstream soon and then we'll re-basit into fedora and we'll get that standardization
is also ongoing for the SSH MLKM key exchange signatures so at the moment you
can't really make all your SSH keys post quantum safe because nobody has a good
idea on how that should look like so there's a draft ITF standard but it's
nowhere near in the state where we can actually get that implemented right a
short slight demo you can use your open SSH client and hopefully the open quantum
safe project has a test server that offers every signature and key exchange
combination under the sun 6195 just happens to be the one that comes within so the
port number happens to be the one that comes with an MLDSA 65 signature and an
X25519 MLKM 768 key exchange and we can actually see this working so this
is done on current fedora 43 and it will actually be used by default if you're
if the other endpoint support set like cloud fair for example has this rolled
out widely already so you will get this key exchange and be safe against harvest
now decryplated attacks on modern fedora good then remember that I mentioned the EU
once quantum safe software and firmware upgrades enabled by default by the end of
2030 and that brings us to what fedora uses to actually ship artifacts and RPM mostly
and in these RPMs come with open PGP signatures there is an open PGP draft that is in
the RFC editor queue so we're expecting it to become an RFC any day now that
supports a post quantum cryptography it does support MLKM for encryption so
a defense against harvest now decryplated but it also supports hybrid
signatures unfortunately the most common PGP implementation
a new PGP has now forked away from the open PGP standard into a
libre PGP and both libre PGP the standard and new PGP the implementation do
not currently support post quantum signatures and I haven't seen any plans of
making that available any time soon either but fedora has been using Sequoia
for a few releases already to verify the package signatures and there is a fedora
a Sequoia pre-release available that has both post quantum support for MLDSA
and SLHDSA and it has support for PGP-C11 which is important because you
want your signing keys to be in a hardware security module and not somewhere on
some server's disk so using that via PGP-C11 is good in that particular
case and we also needed some changes in RPM because RPM now in the latest
version 6 format supports multiple open PGP signatures so that allows us to
have package signed with a classic RSA and then add the the post quantum
thing on top I have a demo for you and that let's see what I can
make it work and oh you can't see that right now right let me move that
over I mean a little bit more font size would be a good idea right
good so doing life demos doing life demos how am I time was 10 minutes okay
that's a work must have rebooted my machine in the meantime good so this
uses and I need to click into that window otherwise it's not going to work
yes so ask you crypto key is a tool to manage keys on APKS is 11 token in this
set up I'm using a software token because I don't have PC cable hardware attached
to my machine you can see here that I'm generating an MLDSA ED25509 key that is this
particular parameter here keys generated I can show the keys that are on the
token you can see here at the top it says description cryoptic that's the software
token implementation that I'm using that scroll down I we can actually see the
PC test key here if you look at the I need to scroll down another night we see
here key type C key key MLDSA so that's the post quantum part further down there's
the the ED25509 part of this that I'm just gonna ignore for now we can take a
look at the public key that was generated we see here the fingerprint string and
below that says MLDSA 65 and ED25509 so it is a post quantum key reporting
that particular certificate and now I need to configure my RPM sign
implementation to actually sign with that particular keys I need to tell it to
use SQ and then look at me type very fast I also need to tell it which which key
to actually use and I need an RPM to sign it on have one so I'm hoping that
in the network works because otherwise this demo is gonna break reasonably slow
but it does go somewhere so now I'm downloading a copy of G-lip C from Fedora this
will have an RSA signature we'll see that in a second it's actually really slow
so and what we'll see after is that I sign this with the post quantum key and then
after what it will have the the PQC signature yes yeah the RPM isn't super large
but this is a container so if I run it with no refresh it will have no
metadata there's a leg I was wondering what exactly actually let me like I get there
like you have to just trust me on this that this is actually correct because I don't
think I get to the end if I if I don't now I don't see can I close this please
oh now it finished right so I can't press enter so we see the G-lip C here oh no it
did actually fail so never mind the rest of it will fail as well so okay back to the
slides so the demo gets I'm sorry a wood of work I trust me there's a video online
as well we you can take another look at it so essentially had the demo work we would have
seen that we can sign RPMs with PQP and have PQC keys but that's not really all there
is to it and there's this long list of things we actually need to take care of in Fedora
before we can roll this out like the tooling it's to support it we need an action hard
security module to support PQC we need to generate the key distributed make sure
everybody has it we need to consider bootstrapping new Fedora releases an older Fedora
versions and that can't break and then their Fedora does not just release RPMs there's
also containers flat packs of S3 images bootsy and probably more stuff that I'm not
aware of and there's tooling out there the use new PG to parse public keys but that won't
work because new PG does not understand these particular sort of keys and then there's also
copper and apple so there's a long list of things that we still need to take care of before
we actually make this a reality in Fedora and to add insult to injury like this is a list of
random protocols that I'm wiggly aware of that use asymmetric cryptography and a lot of these
will probably have to have updated standards updated implementations and fix the bugs in those
new implementations and then they need to have upstream releases and be shipped in Fedora
and hopefully have some kind of backwards compatibility to the huge road of work ahead of us
and if you maintain any of these then just you know reach out and I can probably give you a
couple of pointers I can't do the work for you because this is just too many like the crypto team is
large but not large enough to take care of all of these and with that we have some time for questions
yes
so the question is like we've used this the classic cryptography algorithms for years we know
the secure we've learned as the hardware that the post quantum stuff is reasonably new
should we use hybrids and in this I guess that PQC stuff even secure
so one thing to be aware of a lot of this PQC algorithms that we now see shipped aren't super
new like they've been invented ten years ago and mathematicians have looked at them
it's still you're absolutely right we like there will be new implementation bugs just because it's new code
so we should use hybrids of the existing classic algorithms and post quantum algorithms wherever possible
we're doing this for the signatures we're doing it for key exchange like some people are
like specifically the NSA has written a document where they say look this is not necessary just go
for the post quantum thing at directly but I don't particularly trust what the NSA says that
I'm not in ten people but are there okay any other questions yeah
are the question is does unreleased new PQC have a signature support in PQC
no not that I'm aware so
lip G crypt has support for MLDSA but new PQG does not and to my understanding Werner who's
maintaining that doesn't think it's currently necessary maybe there has changed in the
last few days then I'm not aware of it but yeah okay let's maybe take a question from over there
yeah the NSA not the ITF also gave it a thumbs up in Danford's teacher but the other question
like these implementations are relatively new they've been like they've really we're
reasonably sure about science and security so the question is are we reasonably secure
about side channel security in those new implementations quick comment on the ITF thing that
Bernstein widely publicized yes it sounds like the ITF agreed to have pure MLDSA but it's really
just them assigning an identifier for the few people that want to use that and not endorsing it
which I don't see quite as harsh as Bernstein does in terms of side channel security we're actually
doing the testing like Red Hat has a few good people that are knowledgeable about statistics
and putting the work into do the side channel testing on these it's easy concern but it's been
taking care of John cap forum baseline requirements for the public internet TLS basically still does
not have a MLDSA approved or even a ballot for it where do you see we're gonna when will we get
there because privately in the door to show you the cap of a browser that does it but apart from
internet that wouldn't be usable on the public internet for them so the question is when will the
CA browser forum actually get the stuff together and specify what their requirements for PQC certificates
is going to be I don't have an answer for that so my understanding is that Google is not a huge fan
of the PQC TLS certificates because of their size so maybe they are coming up with an alternative
implementation but I'm hoping that everybody else in the CA browser forum will prevail and at least
get us MLDSA certificates relatively soonish and until that time unfortunately the best thing you can
do is run it in your internet which really doesn't help us much but yeah I'm hoping that they will
get this soon so we're out of time thank you for attending if you have more questions I'll be outside