Almost every bank transfer, hospital record and signed contract crossing a GCC network today is protected by public-key cryptography. A sufficiently powerful quantum computer is expected to break it. No such machine exists yet, and that is little comfort, because adversaries can intercept and store encrypted traffic today and decrypt it once the hardware matures. Security agencies call this tactic ‘harvest now, decrypt later’. For data that has to stay confidential for decades, the exposure started long before anyone switches on a working quantum computer.
In August 2024, the US National Institute of Standards and Technology (NIST) published its first 3 post-quantum cryptography standards, and Washington has set 2035 as the horizon for moving government systems onto quantum-resistant algorithms. Most enterprises in the region have yet to take the step that comes before any migration, which is finding out where their cryptography sits across ageing infrastructure, cloud workloads and the AI systems now being layered on top.
Dr Mukul Ramesh Kulkarni, Director, PQC, Cryptography Research Centre at Abu Dhabi’s Technology Innovation Institute (TII), works on both sides of that problem. His centre designs the algorithms intended to replace today’s encryption and analyses them for weaknesses, and he co-authored PERK, a digital signature scheme submitted to NIST’s continuing search for additional standards. That position gives him a clear view of how unsettled the field remains. Candidates that looked sound have fallen to cryptanalysis mid-competition, and in his view the organisations best placed for the transition will be those able to replace an algorithm without rebuilding everything around it. He spoke to AI Times about where GCC enterprises should begin.
Most organisations still do not know where all their encryption lives, and many are still wrestling with legacy systems and the move to AI. What should a GCC enterprise map first, before it can begin migrating to a quantum-safe system?
This matters because you cannot improve what you do not measure. Technically, we call it the discovery phase, and there are tools that can help with automated discovery. If you want some low-hanging fruit, those tools work in a way very similar to intrusion detection systems, so network data is probably one of the easier places to start discovering automatically, and you can go from there. More broadly, an organisation can think of data being protected at 3 levels: at rest, in transit, and when entities are communicating and authenticating with each other. Ask yourself where you are logging in and where you are authenticating, because those are systems where you should expect to find cryptography. When you communicate over the internet, you will definitely find cryptography in your network systems. Then address your backups, your important data and your redundancy protocols, because you will find it there too.
Attackers are already collecting encrypted data so that they can decrypt it once quantum computers mature. Which sectors in the region hold data that will still be valuable by the time that becomes possible?
You should think about the long-term shelf life of data. Financial data is the usual concern, because it covers your savings, your retirement plans and your loans. Another kind is biometric and health data, which you cannot change; it stays with you and grows with you. Legal contracts that run for long durations are another. These are the kinds of data I would prioritise.
Many companies are running classical and post-quantum cryptography side by side during the transition, much as they ran legacy and new systems together during earlier technology shifts. How long should this hybrid phase last, and what risks does it carry?
The reason you want a hybrid is that, cryptographically speaking, the new standards and algorithms are not yet as mature as we would like. They have not been around for 20 or 30 years. We want to combine them with something we know has provided security over the long term, and then eventually migrate. So the answer is for as long as you can afford to, until you gain the confidence. The timeframe is my personal opinion, but in perhaps 10 years we will have more confidence in the new algorithms and can move over to them fully. The US government, for example, has said that around 2035 most of these algorithms will be considered mature.
There are 2 risks. The first is that you carry twice the cryptographic material, so everything grows in size and performance suffers, because you are doing double the computation. The second is less visible to people: you also have to maintain 2 different codebases, 2 different sets of implementations, and that adds complexity overall. That complexity is a bigger risk than the size or communication overhead.
Cryptographic agility means being able to swap one algorithm for another without rebuilding an entire system. Why is that agility becoming as important as the choice of algorithm itself?
It goes back to the maturity of the new algorithms. We need time for experts to cryptanalyse and validate them. To give you an example, NIST is running another competition to select new standards and algorithms, and it runs in rounds over a multi-year process. Only a couple of months ago, one of the very promising candidates was confirmed to be vulnerable and is now out of the competition. It is a very dynamic and evolving situation. We have a good idea of certain candidates and their security, and we believe they are good enough, but you never know what lies ahead. That is a hard-learned lesson from the past. We want to be able to swap quickly and as seamlessly as possible, and this is where agility comes in.
Post-quantum algorithms often need larger keys and more computing power. Where in enterprise infrastructure today does that cost become a real obstacle?
The main problem is bandwidth, or the larger sizes. Performance with the new standards is generally good, and sometimes they are even faster than what we already use. Size is the real issue. Anything that is very bandwidth-sensitive, or requires a very low memory footprint, is where post-quantum cryptography is harder to deploy today, and that is where organisations will feel the pain of migrating. We are getting better at it, though. As a community we understand the problem and are working on it, and there are some great projects trying to reduce the memory footprint so these algorithms can run on really lightweight devices.
When enterprises set out to build that cryptographic inventory, can the job be automated, or does it still need people checking system by system?
It is very difficult to make cryptographic discovery completely automatic. It is also difficult to do it completely manually, because organisations are running live infrastructure and you cannot go and check every production system. What matters is for organisations to understand that the 2 approaches should complement each other and go hand in hand. Automated discovery, validated and guided by manual effort, is what brings value to the whole process. Another thing I notice is that organisations treat discovery or inventory as a one-time effort. In practice it goes much further than that. It is knowledge building: you can keep track of what is happening across your systems, learn from it, and use it to guide the migration itself.
