Root Causes 270: What Is the Difference Between KEM and PKE?

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

January 20, 2023

One of the little known changes that has come to the world of TLS is that the secret handshake and key exchange updated from Public Key Exchange (PKE) to Key Encapsulation Methods (KEM). In this episode we explain the difference between the two methods and why this change is taking place.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanToday, we want to talk about a subtle change came into the world of SSL with TLS 1.3, which is that we moved from traditional public key exchange, PKE, to KEM, key exchange methods, and this comes up now because as we are talking about the post quantum crypto algorithms we keep using this word KEM, KEM, and we thought maybe it would be worthwhile to explain what the difference is between the two and exactly what occurred there.

Jason SorokoSure, Tim. So with TLS 1.3 one of the things, of course, we have to keep in mind is we are currently using very classic cryptographic algorithms. And so, therefore, we are using PKE or what I would call public key encryption. And basically, in order to be able to have that secret handshake occur, and then of course the symmetric key which then opens up that line of encrypted communication between the web browser and the web server, a PKE is really just utilizing the ability for basically to encrypt something with your public key and then have it decrypted by the other party with a private key. And there’s really not much else going on there. So, therefore, the creation of the symmetric key in order to be able to then encrypt all subsequent communication is happening in the separate part of the TLS 1.3 handshake.

Tim CallanRight.

Jason SorokoSo, basically – what’s interesting of course about the future is that if you take a look at, we’ve talked a lot in the past about the NIST post quantum algorithms that have been chosen to go to standardization, these aren’t PKE, these are KEMs. So key encapsulation methods also use - basically there’s involvement of public and private key as well but the nature of a KEM is that it will generate a symmetric key as part of its process. And why that is, why the post quantum algorithms are mostly KEMs – not all of them are. The ones that have been selected are but if you take a look at the list of the previous, you know, what NIST was selecting from, not all of them were KEMs, so it didn’t have to be. So what I’m suggesting to you, Tim, is that the nature of the TLS 1.3 handshake for classic what we are doing today will have to fundamentally change. And, in fact, IETF is working on that right now.

Tim CallanSo you just threw a lot of stuff in there that I want to touch on and unpack and in no particular order. So, not all – and I didn’t realize this. Not all of the candidates were KEMs. So that wasn’t deemed to be any kind of problem in the contest?

Jason SorokoNo. It wasn’t, because of the fact that really – here’s what’s interesting. A PKE with a sufficiently large plain tech space can pretty trivially be turned into a KEM.

Tim CallanOk.

Jason SorokoAnd a KEM itself can be turned into a PKE by adding some symmetric encryption, right. So let’s really talk about why we are throwing in this blend of asymmetric and symmetric keys.

Tim CallanSure.

Jason SorokoThe beauty of asymmetric is something we’ve covered on this podcast quite often. That ability to not have to know each other. You and I if we want to do business together with an asymmetric secret, it’s a lot better than having to have a shared secret that you and I have somehow shared to each other over who knows how secure of a channel.

Tim CallanRight.

Jason SorokoWe know we have an insecure channel so with an asymmetric secret that really aids in helping us to avoid man-in-the-middle attacks and those sorts of things.

The problem with public private key encryption is that it’s not really efficient when you are trying to encrypt large blocks of data. So, in other words, a web stream such as communication between your browser and web server. That is best done by symmetric encryption. And so, therefore, whenever you are making these decisions, SSL, right, the traditional web server use case, there is initially a handshake - a TLS 1.3 currently handshake – but then, of course, all the rest of the communication that is occurring. So you get the best of both worlds. You get this we don’t know each other yet and then we get the now we have a very, very safely established encrypted communication between each other. That is efficient. Efficiently encrypted with symmetric key encryption. So you get the best of both worlds.

I think some of the reasons why you are starting to see a lot more of KEM within the postquantum algorithms that were selected for standardization is because of the fact that quantum is just different, Tim. Quantum is different so therefore there is a lot that has to be communicated between the process even of any kind of a handshake. And so therefore, that automatic generation of a symmetric key just made sense. Sometimes it’s just because of the constraints of the way that quantum algorithm works. But it’s typically because something needs to be communicated in order for the communication to occur and therefore a KEM just makes more sense.

Tim CallanSo does that suggest that sometime in the future when we are using PQC SSL certificates, certificates with (inaudible 0:06:43.8) in them that we are going to require TLS 1.3 for it to work.

Jason SorokoYou probably are going to have to have TLS 2.0 or whatever they want to call it. All those fancy marketing people over at IETF I’m sure will come up with a name. No, we are gonna need something new.

Tim CallanOk. So this is an important point. So the version of TLS that is running on the servers is gonna need to be upgraded to support post quantum cryptography.

Jason SorokoSo, Tim, you’ve mentioned quite often the fact that in the public world, CA/Browser Forum hasn’t said yes to anything yet. It’s because there’s a pile of work that needs to be done.

So, in other words, we are starting to get now in these conversations – this is a great conversation, because we are starting to get into the guts of what’s it gonna take. What’s it gonna take for public trust to start using post quantum algorithms and, hey, that big use case of the TLS handshake that happens at the web browser, web server level, that has to be rethought out because of the fact that the cryptographic algorithm is fundamentally different.

Tim CallanSo today – today in the world we have right now I’m seeing a mix of PKE and KEM in my real-world usage. Is that correct?

Jason SorokoYes. Yes, it’s true, but I would say PKE is probably more common and the symmetric aspect that’s necessary is a secondary part of the handshake as the way things are defined today.

Tim CallanAlright. Then, but as with supportive TLS, if TLS 1.3 is in place then I should expect that it’s KEM. Is that how it goes?

Jason SorokoNope.

Tim CallanOk.

Jason SorokoPKE.

Tim CallanOh, I see.

Jason SorokoSo it’s PKE but the symmetric piece which would normally be automatically done for you with a KEM scheme, is actually done as a secondary - - it’s a second, third, fourth step depending on how you want to define the TLS handshake. It’s a later part of the handshake that’s defined and it’s not necessarily part of the encryption scheme.

Tim CallanSo should I expect as a normal, just an average user - -

Jason SorokoYou’ll never see it.

Tim CallanYeah. I won’t detect any difference?

Jason SorokoYou’ll never see a difference at all. However, if you go to people who have really been hammering on this – Cloudflare. I absolutely invite everybody to go to their blogs because they have some of the very best, hey, we are playing with it; we want to see what the latencies are like; how long does it take to complete one of these handshakes with a post quantum certificate and they are saying, yeah, it does take longer. So more work has to be done to really make it efficient because people really have come to expect almost instantaneous TLS handshake and what happens if that’s not true in the future. It could be a little different, right?

Tim CallanYeah. Absolutely. I mean we just think we don’t - - I mean whatever time is being spent on the TLS handshake, it’s small enough that, you know, moving my hand to my mouse is bigger, right, and so I don’t even notice it or care.

Jason SorokoSo more than likely most of us will probably see Kyber handshake, right? I Kyber KEM handshake in maybe the first time we ever see one of these things in use and with a real public certificate. Who knows. Will we see a noticeable difference? I do know that in IETF right now Douglas Stebila and others are working on this and I’d love to get one of those people on to talk it through but, for now, what we have are the Cloudflare blogs that are definitely worth reading if you are interested in this topic.

Tim CallanAlright. Good. That’s my questions. Is there anything else on this topic, Jay?

Jason SorokoI hope that was enough. It’s funny. These really do seem like extremely esoteric things but they are important and the reason I think, Tim, why we are bringing them up is because it helps to explain it’s not just the, hey, let’s come up with a good post quantum algorithm, these are the guts of the things that have to be solved before we are using post quantum - -

Tim CallanAnd this is – and this to some degree this is why it takes a long time is because if these details need to be right and if these details aren’t right you can’t run a secure performative interoperable global PKI, right?

Jason SorokoIt has to be dead right. And, in fact, think about how long it’s taken to have TLS 1.0, 1.1, 1.2. Take a look at how long that progression has been to get to even 1.3. It’s not taken lightly and it’s not an even upgrade right through the world so it will be interesting to see how this plays out and that’s why I would like to talk to somebody from IETF real soon.

Tim CallanMaybe we should recruit someone.

Jason SorokoI think we should. So, anyway, more on this topic soon.

Tim CallanMore on this topic soon. Thank you, Jay.

Jason SorokoThank you, Tim.

Tim CallanThis has been Root Causes.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!