What is post-quantum cryptography? A practical guide to surviving Q-Day

Started by Cheeky Kernel, Sep 29, 2026, 03:38 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Topic: What is post-quantum cryptography? A practical guide to surviving Q-Day   Views(Read 119 times)

Cheeky Kernel

SDxCentral has a useful explainer on post-quantum cryptography and how organisations should prepare for Q-Day, the point when quantum computers can break the encryption we rely on today. Post-quantum cryptography, or PQC, uses mathematical algorithms that should resist attacks from both normal and quantum computers. Unlike quantum key distribution, it runs on existing hardware and networks, which makes it far easier to roll out

NIST finalised three standards in 2024. ML-KEM is a lattice based method for agreeing shared secret keys, ML-DSA is a lattice based digital signature algorithm and SLH-DSA is a hash based signature standard that acts as a backup in case lattice methods turn out to have weaknesses. These are the building blocks most organisations will end up using

The biggest reason to act now is the harvest now, decrypt later threat. Attackers can collect encrypted data today and simply store it until a quantum computer can crack it. So anything that needs to stay secret for ten or twenty years is already at risk, even if Q-Day is some way off. That turns a future problem into a present one

The timelines are firming up. NIST wants quantum vulnerable algorithms removed by 2035, with high risk systems moving earlier. The UK's National Cyber Security Centre has set out discovery and planning by 2028, priority migrations by 2031 and completion by 2035. Google Cloud and Cloudflare are aiming to be ready by 2029

The practical advice is sensible. Find every place cryptography is used, including third party services, assess the risk based on how long data needs to stay confidential, test changes properly because larger keys affect bandwidth and speed, use hybrid approaches during the transition and build in crypto agility so algorithms can be swapped later. Suppliers need checking as well. As the article says, you do not need to predict Q-Day, you need visibility and a plan. Is anyone here working on a PQC migration yet?


Protocol15

Larger keys affecting bandwidth is a real issue for some systems. Tiny IoT devices and satellite links have very limited capacity. Some of the post-quantum signatures are much bigger than what they replace

That is why testing in realistic conditions matters. Lab results will not show every problem
My model overfit so hard it memorised my birthday

CaptainCipher10

We have started an inventory at work and it is eye opening. Cryptography is buried in places nobody remembers, from old VPN appliances to embedded devices in the building. Some of the suppliers have no migration plan at all

The inventory step alone will take us most of a year. Anyone who thinks this is a quick job is in for a shock. Start early

FinnHalliday

Supplier checks are the hardest part. You can control your own systems, but getting straight answers from vendors about their plans is painful. Contracts should start including PQC requirements. That gives some leverage

Evan

Q-Day estimates are all over the place. Some say ten years, some say never. The point of this guide is that it does not matter much

CrimsonNova28

The NCSC timeline is realistic for big organisations but tough for small businesses. Most small firms do not have anyone who knows what cryptography they use. They will rely entirely on software updates from vendors. That is fine for mainstream products. It is the old, forgotten systems that will be the problem

NovaBurst

Hybrid approaches are the smart move for now. If the new algorithms turn out to have a weakness, the classical part still protects you

It costs a bit more in performance but buys a lot of safety. Most browsers already use hybrid key exchange

Merchant89

Crypto agility should have been standard practice years ago. Hard coding a single algorithm into systems that last decades was always going to cause trouble. SHA-1 and older TLS versions taught us that. Hopefully this time the lesson sticks

Archie91

Good explainer. Clearer than most vendor white papers on the subject

Poppy

Harvest now, decrypt later is the bit people underestimate. Anything intercepted today could be readable in a decade

Related Topics (6)