Coffee with the Council Podcast: A Panel Discussion on Cryptography
Hello and welcome to our podcast series, Coffee with the Council. I'm Andrew Jamieson, VP, Distinguished Standards Architect for the PCI Security Standards Council. And I'll be your host today for an exciting panel discussion about the current state of cryptography.
moreI'm joined today by some cryptography experts, who I originally brought together at the 2025 North America Community Meeting in Fort Worth, Texas. You're going to hear a very good discussion today. I invite you to visit our Global Content Library on YouTube to view the full session if you're interested.
My guests for this episode are Richard Kisley, Chief Engineer IBM HSM, for IBM Corporation; Jillian Benedick, Cryptographer, Atalla, of Utimaco; Joachim Vance, Chief Security Architect, of Verifone; and finally, Steven Bowles, Regional Security Officer - North America, for Ingenico. So, with that, Let's get started.
Andrew Jamieson: So, we're going to be talking a lot around cryptography, but there's probably going to be a bit of a focus around quantum computing and post quantum cryptography. So, I'll ask Joachim to start to give us a bit of an introduction of what is that, what does it mean for the folks, who may not know?
Joachim Vance: So, a lot of you have heard of a quantum computer, and maybe you don't understand why it's a risk or what provides the risk. So, the difference is like in a classical computer, you have bits, ones, and zeros. A quantum computer has qubits, which are ones, zeros, and kind of everything in between. Maybe a way to think of it is you flip a coin, you get heads or tails, but if you spin the coin, you're not sure if it's going to be heads or tails at any given point, right? So, what that turns quantum computers into is very good at doing predictive analysis.
So, you can do materials science, you can do chemistry, biology, you can do best paths, or travel paths (traveling salesman problem) and things like that. But you can also do things like predict what the key might be and factor RSA or ECC (Elliptic Curve Cryptography) keys. That does take a very large quantum computer. That does take a very large quantum computer. One of the discussions I think we need to have is, how soon do we think that'll happen? Sometimes it's called a cryptographically relevant quantum computer or CRQC. That's kind of the risk, is there's an algorithm called Shor’s algorithm that can pretty quickly attack RSA (Rivest–Shamir–Adleman) or ECC keys and factor them and break them, so they become useless.
Andrew Jamieson: Okay, so let's start with that. In terms of the threat that these pose - so Joachim was mentioning that these quantum computers can be used to attack certain types of algorithms including RSA. And there's actually a paper that came out recently that talked about the fact that it moved the number of qubits, the number of quantum bits that exist or are required to do this from 20 million down to 1 million, which is a big drop. Are we going to continue to see that sort of drop? Are we going to, over time, not only see quantum computers getting better and bigger, but also the need that's required; the size required to break this cryptography to go down? And can I start with you on that, Richard?
Richard Kisley: Yes, I think that that number will go down, although I'm not a mathematician at that level. So, I will yield to you on that one (Jillian). But I think that the number of quantum bits that you're going to need, so that is noisy qubits, that paper and the time prediction, I think for that 1 million qubit answer was one week. So, I think RSA factoring, and was 3n qubits, logical qubits, and I think elliptic curve was 6n (where n is the bits of the key being attacked) and that results in a quantum computer of roughly the same size for those two. But I do think that the quantum computers are on an engineering path versus a theoretical, maybe someday path. And I think the algorithm improvements will be coming along as well.
Andrew Jamieson: Excellent. Interesting. So, Jillian, you've been name checked here, so what's your opinion on that?
Jillian Benedick: Yeah, I think it will continue to drop. This last speed up was due to both factoring speed ups and error correction. So, I think we will continue to see both things get better over time. I don't think it really matters by how much, I think, like Richard was saying, the time it takes is the most important. I think there's two big questions: Will RSA 2048 be broken? Eventually, yes. And what is the risk to fielded systems, and can it break fielded systems already? And I think once we see it demonstrated, theoretically we'll start doing more risk calculations on how long it will take and the value of your keys and when you need to work towards changing those algorithms that will be broken.
Andrew Jamieson: Okay, thank you. Steve, I'm going to come to you with a question. We've seen the change from Single DES (Data Encryption Standard) to Triple DES. Are we going to see if we migrate and when we migrate to better algorithms than Triple DES, are we going to see a long tail of Triple DES still existing in the market?
Steven Bowles: I think the conversation's going to be very consistent with what we've had previously in the sense of moving from Single DES to Triple DES. We didn't rush with that, and we found mitigations by using things like DUKPT (Derived Unique Key Per Transaction) to make it harder to break those weaker keys. We've done the same sort of thing with Triple DES to AES (Advanced Encryption Standard), and I think it's going to be the same sort of conversation, with do we move to quantum algorithms? And that's probably the bigger question from a threat risk assessment, is where are the risks due to these things? I'm doubtful as to how much risk there is in the transaction path from the point of interaction back to the host gateway. But once you get into the gateway area and the processing environment where you have aggregation of data, where you have big volumes of value to the hacker community, that's where you're going to see this sort of attack hit first. And when we're thinking about agility in our infrastructures, whether it be crypto-agility, whether it be infrastructure agility, we've got to go through that threat risk assessment and focus on applying the changes to those higher risk elements first. The path from the POI (Point of Interaction) to the gateway, to me, is a lower threat.
Richard Kisley: But don't you think some of the techniques though would be helpful there? I mean, a static key system is not going to be that quantum resistant, right? And because over time, the value that that key protects will grow. So even though maybe it's not a gateway that's being attacked, the volume of transactions that can be attacked and the number of people that can be attacked because of the time aggregation will grow if static keys are used. So that pushes me towards more of a zero-trust architecture or framework for protecting those systems where you still see Elliptic Curve or RSA.
Steven Bowles: Oh, absolutely. I think the implementations are going to be hybrid, right? It's going to be a mix of things, and there are going to be specific areas where making use of some of the signature algorithms, or other things like that, may be practical and appropriate for those organizations. But data encryption, of small data sets, we'll probably be using - Triple DES will hopefully start disappearing soon. And I'm very hopeful that it'll be AES that we'll be relying on for some time yet to do that kind of transactional data encryption.
Joachim Vance: I think there's an interesting question there though, right? Like you just pointed out, how many people have AES deployed in their payment infrastructures, right? And I agree with you a hundred percent; I think we have to look at where is RSA and ECC being used? But are we going to get to the point where we say, oh, well, payment terminals are kind of unique key per device in their use of RSA and ECC keys, and maybe that's not going to get attacked because, you know, in the 1 million qubit theoretical computer, it's going to take a week to attack. So, we're not going to attack those. We're going to attack the central ones. And yeah, nobody should worry about their payment terminals.
There might be some accuracy there, but at the same time, does that cause us to delay things that we should advance in and when we can do it, like start to replace where we use RSA and ECC in payment terminals and the HSMs (Hardware Security Modules), now? I get concerned about that. We're still stuck with Triple DES, and we should have all moved to AES. And there's a lot of reasons why we haven't, but part of it is lack of pressure, and that we haven't kind of moved forward as an industry together and say, we have individuals moving forward at one at a time. But if there's no real reason to move forward together, I think we need to kind of understand, we absolutely need to address the risk, but we should figure out how do we move forward together rather than say, oh, we can keep those guys to the side. They're not going to be attacked. I don't like that.
Richard Kisley: Yeah, there's going to be this crazy future where all the devices support AES, but nobody's got it turned on.
Steven Bowles: And that's exactly, I think the mistake that we've made so far is that all of the focus when we went from Single DES to Triple DES and now Triple DES to AES, the focus was on the endpoint. There weren't mandates; there weren't things that forced the backend to change. And really, I think when we do talk about this change in moving to post quantum cryptography and the protections against that, we almost have to do it in the reverse order, be more concerned about those processing and not saying that we don't have to worry about, and we don't have to do the end points, but the end points in some ways have the lowest threat. There's a threat, but it's a lower threat. We've got to focus on the backend.
We've got to make sure that those centralized systems where technologies like IBM, creates with the HSMs and all of that, those are the places where we're focusing our early efforts while we get there. Because for the most part, the endpoints are ready, we just need to talk about firmware updates. We need to talk about key distribution and key updates and how to do that in a way that's there, but it's the backend systems because of the money that it's going to take to actually do those backend systems.
Andrew Jamieson: So, Jillian, as the cryptographer on the panel, do quantum computers and does the risk of a cryptographically relevant quantum computer apply equally to all of those algorithms? Or is there a difference?
Jillian Benedick: No. The asymmetric algorithms are more at risk. I think we need to focus on moving to PQC (Post-Quantum Cryptography) and AES kind of at the same time. Since we're late on moving to AES, we should have already done that. But the asymmetric algorithms are going to be broken first. AES 128, 256 it's kind of debatable within the community, which is going to be the safest against quantum computers if 128 is enough, or if we need to really move to 256, and I think it depends on where in the system it is, right? I think your top-level keys absolutely should be at AES 256. But some of the other lower transaction keys can remain at AES 128 and still be secure for a really long time. Everybody's been mentioning crypto-agility. So, I think it's interesting because there was this big push to move from RSA to ECC, and we again, kind of missed that. A lot of people have not made that move. And now moving from ECC to PQC is actually harder because ECC keys are a lot smaller. Their cipher texts are a lot smaller, and PQC keys are very, very large. So, I think moving to a hybrid scheme or pure PQC at this point from RSA is probably the way to go. I don't think it makes sense now to go from RSA to ECC and then to a hybrid or PQC model.
Andrew Jamieson: Okay. So, Steven, we talked about the fact that people need to have started going through their systems, looking at where they use cryptography, starting to do that accounting so that they can figure out, as you say, what are the high-risk systems we need to attack first as opposed to others. What's your feel about how that's gone?
Steven Bowles: To a certain degree, I think different organizations are at different levels of maturity as far as this goes. I think the good question is a lot of you folks out there are at least asking the question. Because I've had a lot more conversations with my customers this calendar year as opposed to last calendar year about migration from Triple DES to AES, about you know, what it means to adopt post quantum cryptography and the risks and all of that sort of stuff. And conversations about, what's in the way, what things are blocking and what things need to be moved on. So, you know, have we done enough yet? No, I don't think so. But people are starting to think about these issues a lot more seriously. They're asking the right questions. And I think keep those conversations happening, keep challenging your service providers and your vendors to guide you as best they can.
Andrew Jamieson: Okay. Interesting. Richard, we're talking about post quantum here and, you know, migrating to AES and potentially Post Quantum Cryptographic algorithms. There's a lot of focus on crypto-agility and so forth. Are we doing that to the detriment of something else? Is there something else that we should also be keeping an eye on in cryptography and key management whilst we're making these changes? Or is that the primary focus right now?
Richard Kisley: The change to PQC?
Andrew Jamieson: Yeah.
Richard Kisley: So, I think it's to the detriment of moving to AES.
Andrew Jamieson: Interesting.
Richard Kisley: I mean, we still need to move, as we've said, from TDES to AES. And one of the other examples was key blocks. And I'm not sure key blocks is completely rolled out everywhere. I think we still get questions. PCI SSC still gets questions about key blocks, so that rollout isn't complete. The move to PQC is people are starting inventories, and I agree with Steven that you're seeing people start inventories, and some people have a few of their systems transitioning, but the PQC algorithms were just standardized a year ago. So, they're not built into places where people can use them for their applications yet. So, what's next? I would like to see crypto-agility as what's next where we start to define protocols so that they're agile instead of dependent on certain algorithms at certain strengths. So, I do think that agility is hopefully what's next.
Steven Bowles: I think there's certainly a number of issues that are important. It's good that we're talking about PQC and all these kinds of things because it is a long conversation, but we can't lose sight of the fact that we need evolution in things like TLS (Transport Layer Security). We need to be looking at our infrastructure, as much as you were talking about agility, is do we have estate management solutions out there that allow us to help maintain that inventory, that allow us to push out firmware updates or to do remote key loading for migration as we go? These are the kinds of things that we need to kind of, you know, building the roads and the highways before we start worrying about putting up the buildings and stuff of these PQC solutions and implementations.
We've got to make sure that there are ways to make those updates easily. Because as a lot of people have talked about, we've got big estates of thousands, millions of devices that at some point are going to have to be updated, and the prospect of replacement is a brutal, costly prospect. I mean, as a vendor, I'd love for y'all to sell your stuff and buy more of mine, but that's not realistic at the same time. So, we have to worry about putting in place mechanisms that allow to take that existing infrastructure and lift it up.
Andrew Jamieson: That's a good point, I think, and to Joachim, what should people also be doing, you know, when they're going through this process of migrating to AES or PQC, either, you know, you might as well do this other thing as well, so you don't have to do it later. Is there anything along those lines?
Joachim Vance: That's a good point. The overfocus on PQC is still, there's not a lot to do yet. I mean, I think that the challenge is, it depends on the industry you're talking to. Like, I've talked to some industries and they're like gung-ho trying to run and figure out how to use some of the algorithms, although they're still running ahead of some of the standards as we're still seeing standards still playing catch up in IETF (Internet Engineering Task Force). There's still a little bit of ways to go in X9. There's still a little way to go. We'll probably see another year’s cycle before we see PQC in all the standards where we need them. So right now, it's still about maintaining inventory. In the meantime, I think we need to stop doing bad things. I still see organizations trying to invent new protocols when they don't need to invent them or trying to use protocols in a way that they shouldn't be.
I've seen multiple instances of regions around the world trying to use RSA-OAEP (Optimal Asymmetric Encryption Padding), which is a great encryption algorithm to do key transfer. So unauthenticated, so without, in a way that could be spoofed or even using RSA for just data encryption. I know there's a lot of organizations that like to do that, but at the same time, it's like if you're doing public key encryption from your end point devices, they can be spoofed. So, I think we need to look at how do we do proper end-to-end security that's authenticated and encrypted? How do we implement TLS in a way that's for data protection as a defense in depth, but not saying, oh, we're going to use that as the sole method of data protection, you know, encrypted data and use TLS. I mean, we need to be using systems together properly and building them the right way. So, it's good to go back and look at our systems and go, maybe we didn't do that one right. And that's an opportunity to, as we build a solution correctly, and then also prepare for PQC, you know, we can correct some of the mistakes so that we're ready for moving to PQC as well.
Andrew Jamieson: So, Jillian, these post quantum algorithms ratified by NIST (National Institute of Standards and Technology), they've only been around for about a year, thereabouts, give or take. How much confidence do you think people can place in those algorithms at this point? And what can people do to help mitigate the risk of that?
Jillian Benedick: Yeah, I think NIST did an extensive review with experts on the algorithms, but they are all pretty new. They're not the types of algorithms that we've used in the past, like AES and Triple DES, the key block, or the block algorithms. So, lattice algorithms are relatively new for cryptography. I think a lot of people still have doubts about it. So, if you are in that bunch, then you should probably move to hybrid first, pair it with ECC, and then you kind of still have the strength of ECC until quantum computers at least come around, should these algorithms be broken before we get a quantum computer. And then when we do, you're still safe as long as the algorithm has not been broken yet. So, I think you see two buckets of people: the people that have full faith and want to go full PQC and the people that want to go hybrid. And I think it just depends on your implementation and your own trust. I personally trust them, so I would go full, but I think other people have different stances.
Andrew Jamieson: Anybody else have any points of view on this?
Joachim Vance: I think you should hedge your bets. I'm a full fan of hybrid for a bunch of different reasons. One is that then you have the confidence of you're getting the security strength that you know you're going to get now, you know, ahead of PQC or a cryptographically relevant quantum computer. But then you're also preparing yourself for using it. And hybrid means, we should explain some of our terms, but hybrid means that you're using a post quantum cryptography algorithm. That's what PQC means, along with a traditional algorithm like an RSA or ECC, an asymmetric algorithm at the same time. So, you're using them together in a way where you get the strength of both together. So, if for some reason tomorrow IBM invents some crazy technology where they could break RSA, you still have your PQC algorithm that is protecting you.
Or if the other, conversely, is true, if the PQC algorithm falls to a classical attack, somebody figures out how to break it, now you have your ECC algorithm or your RSA algorithm to protect you. So, you get the best of both worlds. I think it's, if you use hybrid, you build a stronger system together, and you can easily get rid of one or another later if we have more confidence. I'm a little concerned that NIST has been pushing that we only need PQC, and we're going to do PQC only. The European Commission has said we should do hybrid. So, we have some areas around the world where is it one or the other? I'm concerned a little about the NIST push that seems like in some of the federal systems, they'll be saying if you do hybrid, we don't like it. So that might start to push for maybe there'll be a lot of systems that get built that are PQC only. I'm just not sure. I think we're all better off if there's a choice. I think hybrid is a good way to go. I'm not unconfident in PQC algorithms. We just haven't had time with them.
Steven Bowles: We've seen that the algorithms are solid. We probably will continue to see or need to maybe even update some of them to put in new mitigations for new attacks, whether they be side channeled attacks or others. But I think probably the bigger question right now, at least in my mind, is the usability, especially in the payment space and how it's going to function with the different operating environments we have. The use of PQC in an HSM in a data center is one thing. Which of these algorithms is going to work best in a low-cost chip set on a Point-of-Interaction device is a completely different question. And we're just starting to do those studies now to be able to see how those algorithms work. Thankfully, we've got the choice of a handful of signature algorithms that work with. Right now, we've only got one KEM (Key Encapsulation Mechanism) to work with. So there's certainly some concern there as to, you know, from a performance perspective whether or not that's going to give us trouble, or whether or not we've got to take some time to wait for some of the other algorithms that are still being studied, still being challenged and peer reviewed, and eventually could be standardized.
Jillian Benedick: Yeah, and I think with hybrid it's going to work great in some places, but the PQC keys are so big that then adding an ECC key or an RSA key into these small spaces is going to be an issue in some places.
Richard Kisley: I think also that hybrid can be implemented incorrectly. So, there are ways to do multiple signatures where the outer signature can be stripped off without impact of the inner package, right? So, the hybrid construct has to be correct, and NIST has some guidance, I think, on hybrid KEM usage. So, if people follow the NIST guidance on hybrid KEM usage and then follow industry standard guidance on which composite signatures or hybrid signature patterns they use, hopefully they'll not stray too far.
Andrew Jamieson: Can I ask you this question, Richard? I'm sadly old enough to remember when Triple DES was mainly implemented in software on, you know, in POIs is often eight-bit processes. And the speed at which you could do that was really important. And it took a long time. I mean, obviously now, we have a lot of these algorithms, at least the symmetric algorithms and some of the asymmetric baked into the silicon of chips. And as a HSM manufacturer, are we past the point where the speed of cryptographic processing is an issue? Is it still an issue? And what are the post quantum algorithms going to do to that kind of processing time?
Richard Kisley: So, one limiting factor for these algorithms is the space that they take up in hardware. They do require some room, right? They're not like Ascon where it takes up a significantly smaller footprint than AES, but the PQC algorithms take some room. But with that done, they can be accelerated to comparable speeds. At least the lattice algorithms can be accelerated to comparable speeds to RSA definitely, not quite elliptic curve, but definitely comparable to RSA, particularly when you compare bit strengths. You do RSA 8K or 16K, right? And that's actually comparable bit strength to AES 256. Or to category five security, nobody's going to do that. It's so slow that nobody would do that. But that's the comparable bit strength. So, PQC algorithms are better there. They're just not where, you know, like you were saying, we got so lucky with ECC, that we're not that lucky on the PQC algorithms yet.
Andrew Jamieson: You mentioned Ascon. So Ascon for those who aren't familiar, is what's referred to as a lightweight cryptography standard. It was recently ratified by NIST, and it's designed to be essentially smaller in hardware, take up smaller memory footprint, than AES does. It's a symmetric algorithm. To the panel here, is there any utility in Ascon that we might see in payments or is everywhere where you might use it in payments, you're better off using AES? I'm going to open that up and see who jumps in first.
Richard Kisley: You can optimize the cycle processing time for the algorithm, but you can't optimize the size of the objects for storage or for transmission. So, the PQC keys or cipher text or signatures, depending on the algorithm, are so much larger. It's hard to optimize that out. You're going to see a noticeable impact, if you're transferring them a lot. And hopefully you build systems and protocols where that's amortized properly. And then, for Ascon, people are talking about it, I'll talk about it from the standards perspective, but I'm thinking people are saying, okay, we'll allow it, but use cases aren't turning up right now.
Joachim Vance: I think it's a distraction for our industry specifically. There's no value in using that over AES, right? I don't think there's any situation that I can think of in the next 10 years where Ascon, any of those Ascon algorithms, this lightweight cryptography, it's symmetric key only. It's not asymmetric key. It was designed by NIST as a contest for very specific purposes. A lot of really cool things came out of it. They're also AES 128-bit only, or 128-bit security strength only, which is also an interesting side effect of it. But I don't think, unless we're talking about like some super small memory devices that are built into like our fingernails or something like, that can't handle AES I'm really not sure. I think you could even do from your AirPods, I think you could do AES, so I don't think using AES is going to be a problem, especially in our industry.
Steven Bowles: I mean, one of the benefits that we have in our use cases is that we're not trying to do things in nanoseconds or microseconds. We're talking about transactions that, you know, the user experience of bringing your card or whatever your payment credential is and packing your groceries and doing all that, it's all measured in seconds. And we're effectively using AES today in many operations with our customers. And it's not impacting the cardholder experience, which I think is the measure, the absolutely fantastic use cases in IoT for Ascon. But I can't see us, in the payment industry except, you know, unless there's kind of new technologies that are limited memory and other stuff like that aren't kind of mainstream yet, maybe. But for the most part, I think there's, you know, AES is well established as far as from a usability perspective. It's just that adoption part that we've got to hit.
Andrew Jamieson: If you're new to this industry, if you're new to cryptography, what do you think is the best way for people to skill up and learn what they need to learn?
Jillian Benedick: Yeah, I think there are a bunch of great blogs out there by cryptographers that they can make use of. I think not reading the standards. The standards aren't going to help you if you don't understand cryptography. It's just going to confuse you more. If you're interested in actually getting into cryptography, I think there are some good YouTube channels. There are some great classes. I would say find a mentor that is into cryptography, because you'll learn more from them, especially how it's implemented in your industry. Far more than you'll learn from anywhere else.
Steven Bowles: Perhaps it's not just about cryptography, but I think in talking about one of the things we haven't talked about enough on this panel is key management. And key management isn't all about technology. It's also definitely the part of what we do that definitely pulls in the people and process sides of things. So, in your companies, if you do have cryptographic functions and stuff like that, one of the best ways to start getting into that kind of spot is volunteer to be a key custodian for your company. We’re begging for people to do key custodian activities. It's hard to find people to do it, but it really gives you insight into the processes and rigor that you have to go through to actually protect key material, in the clear as you manage all of these devices. So, it's a fantastic way of getting your foot in the door to start understanding kind of what's going on. Then you can get deeper into trying to build out whether it's a deeper understanding of cryptography.
Joachim Vance: So, one thing I was just going to add was you haven't mentioned the PCI SSC Cryptography Guidance document as a source of education about cryptography, but it actually, I was re-reviewing it just this week, and I was kind of surprised. It has a lot of really good content in there, including about PQC, post quantum cryptography. I think there's some really good guidance in there, as a base. So, as a guidance document, it also teaches a lot about key management, security strengths, and basics of cryptography. There's a lot of good in there as a core. I think we'd be remiss by not also saying what everybody's already doing for other technologies is ask your AI, your favorite AI, right? And honestly, I've been finding that, I will say that six months ago, I was asking questions that I obviously knew the answer to, and it was kind of off. And in the last two to three months, it's giving me answers that I'm like, oh, this is exactly what I go ask from a cryptographic intern. Like, he could give me this or she could give me these answers. So, I think there's a lot of really good that's coming out of like AI as a tool for understanding the issues, right? Maybe not necessarily implementing cryptography, because we're not asking anybody to do that. But if you're trying to learn about key management or best practices for key management within PCI, if you ask ChatGPT, you're going to get great answers. And it's a good way to be able to answer more specific questions.
Richard Kisley: So, you mentioned volunteering to be a key custodian. I think another area where you will see PQC start to be adopted, more readily in the next, just in the next year, is object signing, code signing, or either firmware or software signing or message signing. So, that is another place in most enterprises, most businesses that do development, where you can get involved and help out with a process that has cryptography associated with it.
Andrew Jamieson: I'd like to thank our cryptography experts for joining me on this panel for such an engaging discussion. Again, you can watch the full conversation in our Global Content Library on YouTube. We've linked the video in the blog transcription of this podcast episode on our website. Thank you, again, for joining us on Coffee with the Council.
Like what you’ve heard? Subscribe to PCI SSC’s “Coffee with the Council” podcast by visiting any of the following platforms: Apple Podcasts, Spotify, Amazon Music, Anchor, Castbox, Google Podcasts, iHeartRadio, Pocket Casts, RadioPublic, or Stitcher.