Thank you for the introduction, and I would like to tell you a little bit more about Banks' perspective on this entire subject. A little bit about us. We are Wultra.
Basically, our motto is that we are shipping post-quantum authentication today to customers. We work mainly with banks, Raiffeisen, Erste, OTP Group, essentially in Europe most of the time, but also in Southeast Asia. And so what we can see with our customers is that they currently spend most of the time with two main subjects. The first one is artificial intelligence, the biggest buzzword everywhere. I think that people are getting slowly sick and tired of talking about AI, but they do it anyway. And the second one is compliance in general.
PSD3 is probably more fitting for banks, but also EYD wallet has a significant impact. So banks are a little bit under regulatory pressure. And what we are preaching for is that they should also focus on this new subject of post-quantum cryptography, which seems a bit technical.
Actually, the presentations before mine were quite technical. I was able to follow just because I studied at the Faculty of Mathematics and Physics, but long forgot everything. So happy to chat later. And what is post-quantum cryptography? How do we talk about it with banks? It's basically a branch of cryptography focused on methods that would remain secure against attacks by quantum computers. We do not really look at practical mathematics there. We just say that's a branch of cryptography. And it is important more and more, actually, over time.
If I look at what Coppinger Cole thinks about it in our report Rising Star Ultra, basically they say that the rise of quantum computing threatens to break widely used cryptographic algorithms, rendering traditional authentication methods vulnerable. So that's by Alejandro Jalil from March. But it's not only Coppinger Cole. Even lesser known consulting agencies are actually putting post-quantum cryptography on their radar. Gartner actually put post-quantum cryptography among top 10 technology trends overall. So basically, it's the main subject line for companies working with Gartner.
And they basically highlight this year, 2029, as a deadline for businesses. And from the bank's perspective, the impact is really vast. It's not just about authentication. It's basically about every single piece of software the bank is currently operating. If you look at it practically, cryptography is everywhere. It's invisible, but it's everywhere. And if you ask banks where, they typically don't know. This is why they need to first categorize everything in the inventory. So if you think about it practically, EUID wallet was something that we already touched upon.
But banks also need to replace payment cards by the Q day. They also replace customer authentication. They have to timestamp digital signatures on their current contracts. If you look at any blockchain deployments, these will be affected. So it's everywhere. Everything that banks invested in in the past 5 to 10 years has to be replaced or updated. And the impact is vast, but we already heard the timeline.
Basically, there is 2030 as a deadline. Unless banks want to operate with some level of regulatory compliance risk.
Of course, we have a new kid in the Czech Republic, our national cyber and information agency, who suggest to already start switching to quantum resistant cryptography. Banks could decide not to follow it, but it would be quite complicated. For example, when you go to financial arbiter and then you have to argue your case, it's not the easiest. And practically speaking, banks are not the fastest. So if you look at 2030 and we ask most of the banks, have you budgeted for it? Like none of them raises hands. Nobody budgeted for replacing all of their software or updating all of their software.
So that's something that we are currently urging. Second, they would have to probably search for some new vendors, because some of the software will never get updated. That will take them one year, practically speaking. Then it's RFP time, a lot of competition, people talking one year lost. Then they are running the project, implementing, replacing. And then maybe in 2029 they could be done. So unless they start in 2026, banks just won't make it on time. So what I want to argue is that the advice, let's build a catalog now, is just insufficient.
You know, they just need to move much faster and we need to recommend a bit more at this point in time. Also, a bit of a side note, we always used Harvest Now, Decrypt Later as the only argument how to solve the future problem now. But now it's again, not the time for it. We need to basically push large organizations to switching much sooner. Physicists in the audience will be probably laughing now because there is a bit of a debate about Microsoft's announcements. But every now and then there could be a technology breakthrough. We saw it with AI.
If you remember AI five years ago, it was basically a joke of every presentation, really. If you put AI on slides, the first question was, OK, and so how many interns do employ to do the AI manually? This would be basically the view of most of the discussions. But now it's quite normal to talk with a computer.
You know, we can just ask him to do something and they can actually comply pretty easily. And we can have a big surprise in quantum computing as well. Somebody can have a great idea. I think that our biggest enemy is a quiet guy sitting somewhere at Google wearing a badly fitting sweater and colored socks, thinking about stuff, drinking yerba mate and suddenly having an idea, right? Because actually the trust sort of breaks down shortly after this idea is put into practice.
And so, yeah, maybe everything can happen even faster. So long story short, from our perspective, banks will have to change customer authentication. If they don't do it, they will have a major problem in trust. Sometimes we even hear discussions about basically just shutting down digital channels temporarily to be able to withstand the problem, which is quite unexpected and quite a radical solution, but maybe the only one solution if you do not make everything in time.
And so what we are trying to do, as good as we currently can with the current state of technology, is to roll the banks on post-quantum authentication. That's a term that we try to coin. We are leading in the segment, maybe because we just started too early and suddenly the time was right. And this is basically authentication resistant to emerging quantum threats in all possible aspects and touch points. So what does it mean practically? So banks have multiple different authentication methods. All of them have to be quantum safe.
If they have hardware authenticators, for example, security keys based on 502 standards, these would have to be replaced. That's actually quite problematic. If somebody is buying security keys based on 502 now, they will probably have to throw them away in two or three years time. But also mobile authentication. That's currently the most frequently used method for consumer authentication and banking, built most frequently on elliptic cryptography as a baseline.
But even if we zoom in to a single authentication method, like a mobile-first authentication, there are many changes that have to be done. In the front end, in how the systems communicate, in what happens on the server, and in how we encrypt the database. And of course, while we are at it, we also update all other cryptographic primitives to have stronger hashing functions, even though we don't have to. But we are touching it already, so we will just make it better all over the place. Another discussion is about what does it bring to us? Practically, from the user perspective, nothing.
So basically, the pitch on the board level goes like this. You will have to replace all of your software, spend a lot of money. It will be difficult, complicated, with possible negative impact on your customer. But it has no real positives for the users. So not the easiest discussion about budgeting. Then we get into the discussion, when does it have to happen? And eventually, we are able to convince some of the customers that they should start now.
I mean, sometimes it has to happen. Everybody gets it, but there's a bit of a discussion about timing. And part of the discussion about timing is actually about this hybrid versus non-hybrid approach. So I think that on the general level, there is quite a bit of a discussion about should we go just with pure post-quantum cryptography or hybrid. But in banking, you cannot just go to a bank in 2025 and say, hey, look, you can use these new algorithms. They are completely untested, standardized in August 24, and just go with it. We have to go for hybrid scheme.
We basically have to tell the bank that there is a baseline, which is at least as strong as the previous version of their authentication. So we had to build a hybrid scheme, which actually neatly leads towards crypto agility. Because in five years, elliptic curve cryptography will not add much into the entire scheme. So we will have to replace cryptography again, and maybe in five years again. So we can no longer accept this approach that we accepted until today, that we are with RSA for 30 years or 40 years or with elliptic curve cryptography for decades.
We have to get ready for crypto agility and the ability to easily switch cryptographic algorithms. For practical reasons, we also selected crystals-based algorithms, Kyber and Deletium. They seem to be the most pragmatic choices if you want to build a system today. So what is the challenge then for our customers also? It is not a simple drop-in replacement in general. Sometimes it's quite easy, but sometimes it can be quite complicated. The first problem with authentication is that it requires active participation of the user.
If you have, for example, passkey enrolled, you cannot really magically turn RSA key or elliptic curve cryptography key into Deletium key. You have to re-enroll. Second problem, it must be done before the Q-day with different impacts in different situations. I will talk about it a bit later. And typically, you need to mobilize your vendor. So if you delay the switch, you will have basically concentrated effort, and you may put too much pressure on your vendors to actually be able to respond to your specific inquiries. They will focus on someone else.
And so we have identified basically three migration strategies for banks to go from classical cryptography to post-quantum. The first one is using their current existing authentication to enroll a new quantum-resistant authentication scheme. This has one big caveat. You have to do it while the current authentication is still trusted, so typically long before the Q-day. If you don't make it, you would have to re-enroll all the customers. Banks are able to re-enroll customers digitally through identity verification.
And the third option would be to basically wait for some third-party provider that would re-enroll the customers for you so that you don't have to do it. The practical problem is that if you look at the cost of authentication versus identity verification, identity verification is quite costly. You can easily pay two euros per identity verification, which can result in 20 to 40 times more expensive migration from your current user base to the newly enrolled one. This doesn't have to be a problem. If the bank is a small, specialized bank with 5,000 customers, that's fine.
You will just re-enroll them again. But banks with millions of customers can save significantly more money if they decide to use their current authentication as the enrollment method. And the biggest problem with the last option that we already heard, there is currently no real initiative to, for example, make European ID wallet quantum safe. There are auxiliary efforts, but it's not in the architectural framework. It's not in the legislation. Nobody really thinks about European ID wallet or any external authentication methods to be quantum safe.
I think the most telling is our discussion with our local agency for issuing physical plastic documents. They are currently selecting new vendors for plastic cards with no requirement on quantum resistance. So we will issue identity cards that will stay with us for the next 10 years without a quantum safe chip in it. Probably. We will not issue them. We will buy them and throw them away, which is the typical government approach to efficiency. So what I want to argue is that currently, if there is any RFP or any discussion, quantum resistance should be a requirement.
If not quantum resistance, at least crypto agility. If you are not able to provide quantum resistance solution now, you should have a clear migration strategy. And ideally, you should be able to switch from current legacy cryptography to a new modern post quantum cryptography easily. And so just to have a final call to action, let's do it now together. We are here, all industry specialists. Let's help our customers to be ready for the Q day. It is approaching. So the timeline is getting shorter and shorter. And the more we wait, the more concentrated the effort will have to be.
Regulatory pressure is rising. The deadline on 2030 will eventually be enforced. And finally, the transition takes time. So we really need to help our customers to do everything on a timely manner. Thank you very much. Ready for questions. Thank you. Any questions? Please raise your hand. On the last slide, and I think you mentioned that before you were saying the recommendation was 2030. If I recall the NIST recommendations correctly, 2030 was for encryption. It's not for signatures. Signatures was, I think, 35. So NIST actually separates recommendation into deprecation and disallowed.
For deprecation, it's 2030. For disallowed, 2035. I'm pretty sure signatures was 35 for deprecation. How would it work practically?
I mean, the far bigger challenge right now is use cases where we can store and decrypt later. I guess my main question is, right now, digital signatures still have migration time. I'm fully with you that we need migration pass, but I wouldn't say we need to build everything right now with post-quantum signatures. We can double check it with NIST paper, but very practically, yes, harvest and decrypt later is problem today.
Like really, there are already attacks happening where, you know, typically government agencies are stealing, stealing, recording, encrypting data so that they are able to decrypt them later. From this perspective, digital signatures still have some time because they currently are safe. But as the timeline moves forward and the Q-day approaches, it would become like a practical challenge to replace digital signatures on time. And once there is a Q-day, once you have a quantum safe computer, the race really starts.
So we might, for example, argue that the first quantum computer won't be really generally available, you know, as a module in Azure, for example. It will be only available to someone.
Also, we don't know how fast it will be. Can it crack RSA signature in a second or in, I don't know, half a year, maybe. If it is half a year, we can still, you know, use RSA with three year, sorry, three month lifetime of the key. We can just, you know, speed up the rotations to be very, very short lived. But this is not sustainable in the long term. And I understand that for a typical business, this doesn't represent such a big problem. We are looking at it from the banking perspective where a bank typically, they take years to make changes.
So, you know, I get it. It's not as urgent. But if you look at the timeline, we actually have to start with them now. Yeah. And we will double check the timeline just to make sure. I'm mostly reading NIST through our local cyber security agency. And actually, if you open a list of recommended cryptographic protocols from February this year, the first chapter is about post-quantum cryptography. And with every single algorithm, they mention if it is quantum safe or not. And then they recommend switch by 2030. So maybe it is just a slight misinterpretation in basically in translation there.
Thank you. Yeah. Any further questions from the audience? I actually have a question of my own. So all these things we have been discussing so far are major strategic products which require years of planning and implementation. Are there any smaller things like which companies like Benz could start with to ease their strategic projects in the future to get some quick wins, training ground, sandboxes, if you will? Quick wins? I think that if you want to make a quantum safe announcement, we did this quantum safe, I would start with document signatures in the PDF documents.
Because that's really easy to do technologically, as we heard in the previous presentation. You can easily add quantum safe signature to your existing contracts. And it's this type of project where you just have to run all your PDF files through a single API call, essentially. So this would be like a quick win for everyone. It is typically a one-time operation. So it doesn't require integrations all over the place, just like authentication. Authentication products are heavily integrated. So it takes time to replace them. This would be probably it.
Also, what our national cybersecurity agency does, they deploy the TLS on their website, which is quantum safe. So there's also they use it mostly as a marketing announcement. You can now visit our website through quantum safe cryptography. But it's easy to do. Does it actually give the teams who will be responsible for the biggest projects any additional skills? Or is it just a checkbox? So the ideas that I mentioned would be mostly a checkbox, but also a learning opportunity for the teams. Because they would essentially have to go through everything related to post-quantum cryptography.
They would have to familiarize themselves with timelines. And also, they would get their hands on the actual algorithms, which is sometimes helpful. Because authentication system is typically a combination of these algorithms that's put together. And if you understand individual algorithms, and for example, understand how is ECDH handshake different from ML chem handshake, that's quite helpful. Because you will have to replace it everywhere in the follow-up implementations. There's one thing I, as an analyst, hear a lot from other areas of cyber security.
That everything starts with discovering, you know, classification and building the inventory of your things, be it APIs or databases. Is this step necessary for crypto agility as well?
Yeah, it's necessary. Everybody should do it. I think that the reason why we do not put so much emphasis on it is that we are not a consulting agency that can help with that. But we recommend our customers to actually find someone to help them with catalogization of all cryptographic primitives and mapping out the impact. Because maybe, just maybe, some organizations will have AES-256 in 75% of their impact analysis. And they are pretty much safe in 75% of use cases.
But maybe they will find some digital signatures, asymmetric encryption, shorter variants of AES, which may or may not be problematic. Sometimes there is also discussion about, do we really need to encrypt it?
Like, can we just protect the parameter of the solution instead of like re-encrypting everything? So yeah, definitely, inventorization is a necessary step, mandatory. I'm just saying it's not the only one. And it should be probably done in parallel with some other activities.
Okay, well, thank you very much. Do we have any further questions?
Oh, if not, then again, thank you. Thank you.
