So, hello everyone, welcome to our next talk about post-pantum cryptography from Clemens and
Andrew Twig. Welcome. Good morning everyone. Thanks for being here. My name is Drick Shellard.
I work at Red Hat. The reason we have chosen this topic because we see post-contum cryptography
also known as PQC. We are sitting at the intersection of quantum computing and today's
internet security. Quantum computing is important because it is certainly affecting the crypto
system that we rely on today and hence we want to define reliable path forward.
I would start by giving a high level intuition of quantum computing why today's cryptography
system are at risk and how we can safeguard our system's hybrid PQC approach. Then Clemens
would emphasise more on the current trends with PQC and how we can integrate the same in our
day-to-day software supply chain.
Are you in the DAV louder if someone was to go on your own computer?
Okay, let me just. Is it good now?
I think this. How about this?
I think it should come somewhere here. How about this?
All that. So we know that quantum computers are super powerful especially solving
problems that require massive power. At the same time we know that there is a constant threat
for our classical PQC system as well. So our PQC system has been there for decades.
It is acting as a silent guardian for us. All the DLS handshakes, digital certificates,
keys, they remain invisible when they work. Because they are definitely built upon certain
math problems which are super difficult to crack for the classical computers.
Now when we talk about math problems these are like integer factors and some discrete
log problems. So to give an example breaking real RSA it's like trying to figure out which two
giant prime numbers were multiplied to form a 500 digit number. It's that difficult and that
kind of difficulties keeping our entire email, web and blockchain secure today.
So quantum computing is important because it challenges the math behind this building blocks of
PQC. So a fully powerful, fault-around quantum computing system is known to affect
today's classical system using sure algorithm. So what happens is with classical systems it is
forced to get the pattern behind this math problems. But quantum computer using its
Q bits and entanglement makes interference that easy it helps identifying the patterns so
that the hidden patterns stand out instantly. So once you or quantum computing know the pattern
it makes easy to crack all the integer factorization or discrete logarithmic problems.
However, at this moment we don't have such quantum computing computer readily available with
that level of capacity of Q bits or let's say fault-around tolerance that requires to crack
these problems. So you might be wondering is this transition to PQC is really needed if you
don't have such quantum computer available or why people are seen this as why to Q or Q day problem.
Well, there is a constantly a looming threat behind this whole ecosystem. It's called
Harvest Non Decree Platter. Any adversary or attacker could try to store your encrypted data
to a and decode it later in the future when they have such powerful, fully fault-around quantum
systems readily available with them. So this is not, sorry, this is not really about future
proofing our system. So this transition is basically protecting your data today so that it cannot
be exposed tomorrow from the quantum attacks. So let's talk about timeline. This slide is
really about three clocks which are taking at the same time and the scary part is they are not aligned.
So time to transition is definitely larger than the arrival of quantum computers because it
includes a lot of standards, vendor upgrades, products supports and whatnot. So the list goes on.
And then there is another clock which says time you need your data to remain secure.
Now we briefly classify this into urgency model. So for example, you might have some keys that are
having low important or required or pose a low impact. So not everything needs to be migrated.
You need to classify what data you have. Then there could be a medium urgency where you have
TLS search SSH keys that need to be treated at medium impact. Then higher agencies therefore
especially for national security systems where decades of secrecy is required. You may have
some transact financial transaction or defense records that should not be exposed at any cost.
So you might be wondering what solution here how we can safely migrate to the PQC or how we
cannot affect our existing system so that the existing encryption doesn't break and yet we can
able to migrate to PQC. So the solution is obviously hybrid crypto which offers defensive
depth. How many of you like Swiss cheese? I certainly do. Yeah. So it offers security
at defensive depth just like Swiss cheese security. This approach has been used in various
industries like aviation security emergency units. So what it does it overlap multiple security
system so that if attacker has to attack it should be succeed attacking two system at once.
Then only the attacker could succeed. So the same approach has been used when we talk about hybrid
crypto. So thanks to some of the communities who are
proactively working on making this transition possible. One of the examples here is open SSL which
open SSL 3.5 with TLS 1.3. Nativity supports the PQC, KXN algorithms as well as digital signatures.
So when we talk about KXN, we have MLKM which is based on model lattice problem.
Then we have hybrid KXN where we combine this MLKM along with our classical ECDH key to form
a hybrid KXN just like MLKM plus the ECDH. Then there are post quantum signatures primarily
MLDSA and SSL GSA. The SSL GSA is based on digital hash setless hash and MLDSA is based on
model lattice problem. So there are certainly some variants that defines how these key exchange
and digital signature can be classified. So there are some performance rate of that we also need
to consider. So MLKM comes with three variants 512, 768 and 1224. So lower variants often
gendered smaller keys which is essential for faster handshakes. Then with higher variants
it produces larger keys but it also gives higher security margin. Same goes for digital signature.
Smaller the signature faster the verification of your trust with higher variants it produces larger
signatures but it is also better for long-leaved connections. For example, firmware search,
root search. So let's have a look at quick demo. I have just to give in context. I have
built a Fedora 43 system on top of which deployed engine server that runs and support the
open SSL 3.5 library as well. So I have kind of put both trust here. One is hybrid KXN
and the classical one just to see how fallback works when there is a client that is not
capable of interacting with the hybrid key actions. So we will take a look at both scenarios.
So first let's conform the open SSL and system release. So this is Fedora 43.
Then open SSL 3.5 onwards supports this KXN. Then are we listing all the KXNs that are
natively available within this open SSL library. So you can see these are digital signatures
with all the variants. Then I would be listing the KXNs. So primarily we are focusing on the
hybrid KXNs, the CDH plus MLKM. Now I would be creating a digital search, self sign
search based on this MLKM, based on the MLDSA as signature algorithm.
Now I would be creating a RSA search.
Now we would define this search key pair inside our engine X configuration so that when we try to connect
client it would pick up these certificates. So this is the typical engine X configuration where I have put
all MLDSA as well as RSA key pair.
Now just reloading the engine X configuration to get in effect with this server.
So if we just test the server it should be working fine, yeah it is working fine.
Now I would be trying to connect the server as a client using MLDSA search and then we could
see the key pair being used here. So when I try to connect it shows PR signature type MLDSA
and negotiated PLS group is hybrid KXNs. Now there might be some clients who cannot
interact using hybrid KXNs. So they can continue to use the RSA for example this.
So PLS signature shows RSA and just the ECDH key exchange.
So that's how a fallback basically works. In case you still have such clients.
Now you must have noticed this is possible because of PLS 1.3. One of the smartest design
is to like to redesign PLS 1.3 so that it can support key exchange independent love
cypher. So your existing cypher suits and encryption doesn't break right away.
And hence script agility is preserved. This also helps hybrid PQC which we just saw
because it can operate entirely into key exchange layer and not in the cypher suit layer.
So if you look at a typical PLS handshake for hybrid PQC, the key exchange
determines how secrets are created. Then the signature defines who is trusted to create them.
And then comes the cypher suits that are about how data is protected afterwards.
Now I would hand over KLEMAN who continue with remaining.
Yeah. Thank you. So where are we today? Here are some numbers.
Cloudflare has been measuring the amount or the share of key exchanges that they see from
human clients. So that means essentially browsers that use post quantum key exchange. And the
good news that it's almost at 60% was like at 58% recently. So IIT of working groups are working
on adding post quantum cryptography to a lot of protocols already. You've seen this work for TLS.
It's not an RC yet, but everybody in the kitchen sink has already started implementing it.
Like 60% of the connections use it, but it's not yet an RC. So Chrome 116 and later. So that's
quite a while ago. I had already do PQC key exchange. Fedora 43 now has it. And then IIT by default.
And then also the entire secure boot world that needs to do something because it's currently
based on RSA. And IBM is the first ones are that the gate with a Z16 chips that actually have
a lot of space signatures and a cam spaked into their firmware and boot chain. If you want
more details, there's link here that gives you a nice overview of what the set of your protocol
might be. So this is, sorry, wrong direction. This is the right direction. This is the graph
I was talking about from Cloudflare. We can currently see 58.3% and there's been going up steadily
over the last few months really. So one thing that we've now talked about, is encryption,
but did you know that the EU by the end of 2030 requires all software updates to be post quantum
safe and have a PQC signature? Like we guess open source community can say we don't really care what
the EU wants, but there are like commercial entities with certainly care and I like have to work for
one of them. So that remains relevant for me. One of the things that we clearly do sign a lot
are RPMs. Now the RPM packages that we sign today for example in REL, they will still be used
in 10 years and I don't today want to make about that in 10 years, nobody has built a quantum
computer. So this is why we're doing this transition. So there is an open PQP draft available that's
specifies the use of post quantum cryptography. Unfortunately GNUPG has forked the standard in
is now following Libre PGP and both of those do not currently have post quantum signatures.
They have post quantum key exchange, but not signatures. But there are implementations that are
working on getting the open PGPPQC implemented, notably Sequoia and a few others. I'm going to
focus in Sequoia now. I'm going to show you a quick demo of Sequoia PGP with a PQC 11 backend
which is important because you want your signing key to be inside of a hardware security module
because I don't have a hardware security module with me. I'm going to use a software token
that supports post quantum cryptography and that is cryoptic which is based on open SSL.
So let's see, it's a video, but I could run this locally. The demo you're seeing is essentially
me recording this automated thing. So ASQ Crypto Key is the way to manage the token and here I'm
telling it to create an MRDSA ED25519 key on the cryptographic token. That is done.
I can show the contents of the token. We can see this is a cryoptic token. That's a software token
and it's called PQC Test token. If you scroll further down we can see the PQC Test key.
This is the MRDSA part, as seen by the key type, CKK MRDSA here. There's also an EDSA part that I'm not
showing. We can inspect the public key. We can see that the public key says yes, it's an MRDSA 65
and ED25519 key. I'm importing that into ASQ setting. He's a later for signing.
And now I need to configure RPM sign so that it knows that to use Sequoia and to use that
particular key. Look how fast I can type. I need to actually sign an RPM. I don't have
one so I'm just downloading G-lip C and we'll see in a second that this copy of G-lip C currently
has an RSA signature made by the fedorarchy and I'm going to add an MRDSA signature. So this is an
OpenP2P version 4 RSA signature and now the RPM sign on that it's prompting me for the passphrase
of the PQC's 11 token and now I have an OpenP2PV6 MRDSA signature on that particular RPM.
Right. That's the demo. So in summary, like we've seen using hybrid crypto provides defense
in depth and using X25519 with MLK for a key exchange is our defense against harvest now
decreplated. This is clearly the priority. We should update all the protocols that do encryption
and do a key agreement to do to this. TLS 1.3 is essentially ready even though it's not a
finalist RFC yet but it's pretty close. So people are starting to implement it. SSH in open
SSH also has it, lib SSH is working on it upstream so that will also ship soon.
There's no PQC signing in SSH yet but somebody has also started an ITF draft for that already.
There is some global momentum in this. Like we've seen that 60% of the human TLS traffic going
to cloud for a already uses hybrid key exchange for PQC and for the supply chain signing we actually
have an answer today even though it's a bit hard to deploy at the moment but we have an answer
by the time that it will be required. With that, thank you for your attention. Are there any questions?
Hi guys, thanks very much for that. It's very interesting. We manufacture
committed systems, connected devices so this has been a worry of mine for a while. It was great
to see that you commented on the fact that what we ship today which might be in the full
of 10 to 15 years has to be CRA compliant. My concern is how do we make sure that we're quantum
safe now and in the future. A quick shout out and a question if I may
create a meta-quantum safe for youcto to try to play with LibOQS to look at the algorithms
and what we could do on different platforms. I'd love people to come and join me and see what we
could do with that. On more deeply embedded systems with our classes we're seeing the TPMs and
secure elements are coming out which talk about quantum agility and are starting just now to have
quantum safe algorithms. This seems to be problems without having trouble fitting those algorithms in.
I'm really concerned about what happens if we lay down hardware today and in a year or five
years or whenever find that we have to do something else. How do we be compliant with the
security legislation if the hardware doesn't do what we need it to do?
So this is a pretty long question. I'll try to summarize my answer to this.
So there's a long road ahead of us. There are many standards to be updated. You mentioned TPM,
right? There will have to be updated standards. Once the updated standards are roughly done
there will have to be updated implementations. Those updated implementations will have bugs.
We will have to test for those. We have to ship all of those because like all
they're not everybody runs fedore on updates that operate in system twice a year. So that's
essentially why we're starting now. We have some time but if we don't start with this now
then we may find ourselves in a timecrunch eventually. Speaking to liberal QS,
we've actually started out with that but we've seen that there's not a lot of momentum in getting
it shipped everywhere and people are more moving towards native implementations in the
cripple libraries. So feels like liberal QS is not the way to go for the future. It's great as a
testing tool. Great for testing especially the hybrid algorithms that are not completely
specified in done yet. For example for X5 and I in certificates but I don't think it's the
right tool for production use at the moment. I work very closely with the TLS working group and
you in the beginning of your talk you mentioned that it's obvious that the like the hybrid is the
way to go but that's not really correct. So there are a lot of debates happening in the TLS working
group that whether it should really be hybrid or whether it should be pure. You are creating
extra complexity by just having that thing which will eventually really break. What's the benefit
of doing that? So I don't think it's a solved problem so there are still some debates going on
and there is in addition to the draft that you are mentioning there is another draft which is pure
post quantum and that's already near to publication and I mean the statement that you made
it's obvious is really incorrect. Yeah I could acknowledge that and I have also seen a lot of
debating threats where people are just asking why not just pure ML pure PC algorithm instead of hybrid
because it obviously introduces more workload on the TLS handshakes that was also one of the
factors but the thing with ML came or precisely the pure PCL algorithm is that these are pretty new
having said that there are so no known threats or adversaries identified yet on the new PCL
algorithm that's why we thought let's combine both. We as in whole the community is working on
combining both so that it doesn't break the one. So when PCC is maturefully for our systems then
we can probably think of pure PCC in the near future. Like Laman said this is the right time I think
we need to start testing our systems to know how it works with the PCL algorithm and then gradually
we can move over the pure PCC. We have time to ask question. Can you see a word about the next
Etsy pointing time meeting worldwide next June in Ottawa? Sorry can you repeat the question?
Etsy? Yes. ETSI is a worldwide meeting about these subjects meeting on a regular basis and
the next one is in Ottawa in June. Can you say a word on that?
So I'm not personally involved in doing any of the standardization like I'm a product owner.
I have people that actually do the technical work but so my concern here is like Etsy and
ITF don't seem to fully agree on who should specify hybrid X5 and I certificates and in which
particular form. So I'm not going to get involved in that and let the people that are experts
in standardization figure it out and then we'll follow what makes sense. Thank you very much for
your presentation.