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

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  Today, 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 Soroko

  Sure, 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 Callan

  Right.

• 

  Jason Soroko

  So, 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 Callan

  So 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 Soroko

  No. 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 Callan

  Ok.

• 

  Jason Soroko

  And 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 Callan

  Sure.

• 

  Jason Soroko

  The 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 Callan

  Right.

• 

  Jason Soroko

  We 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 Callan

  So 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 Soroko

  You 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 Callan

  Ok. 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 Soroko

  So, 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 Callan

  So 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 Soroko

  Yes. 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 Callan

  Alright. 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 Soroko

  Nope.

• 

  Tim Callan

  Ok.

• 

  Jason Soroko

  PKE.

• 

  Tim Callan

  Oh, I see.

• 

  Jason Soroko

  So 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 Callan

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

• 

  Jason Soroko

  You’ll never see it.

• 

  Tim Callan

  Yeah. I won’t detect any difference?

• 

  Jason Soroko

  You’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 Callan

  Yeah. 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 Soroko

  So 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 Callan

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

• 

  Jason Soroko

  I 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 Callan

  And 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 Soroko

  It 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 Callan

  Maybe we should recruit someone.

• 

  Jason Soroko

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

• 

  Tim Callan

  More on this topic soon. Thank you, Jay.

• 

  Jason Soroko

  Thank you, Tim.

• 

  Tim Callan

  This has been Root Causes.