From Q-Day
Jump to navigation Jump to search

Quantum computers have been gaining traction since recent years. What we're seeing in the technology field is that there are divided opinions on whether to act upon the possible threat today. Hence, some organisations are waiting for NIST and the standardization to be settled further before proceeding, while other organisations are taking actions already and another group that chooses to ignore it.

One of the core questions you might wonder as organisation is:

Is it a realistic threat we should act upon today?

There are already three key reasons why organisations should identify and start working on the migration to PQC now already:

1. Sensitive information is at risk of being intercepted and stored now and decrypted in the future with a quantum computer. Such an attack is called a store-now-decrypt-later attack. There are serious suspicions that this harvesting of encrypted data is already taking place. Thus, data which needs to remain protected for a long time is already at risk of being decrypted before the end of this confidentiality period.
2. Long-lived systems and critical infrastructures developed and deployed now are very hard or even impossible to update to PQC later on. Even if it is possible to upgrade the software running on these systems, PQC requires heavier machinery to function, which might be impossible to replace once the system is deployed.
3. Updating or replacing cryptographic infrastructure to post-quantum alternatives is a very cumbersome and resource-consuming task. Judging from previous migrations, it is expected that updating legacy systems will require a lot of planning and preparation. As an example, it took over five years to migrate from SHA-1 to SHA-256 for all organisations, vendors, and other parties even after the specifications and implementations were already available.

If you fall under one of these three cases - the next thing you will need is a migration framework.

The migration framework, and the migration plan that documents it, comprises the following three stages: Inventory compilation, Preparation of the migration plan and the Migration execution


Before PQC diagnosis, you should choose what persona you identify with.

The three main PQC personas are listed below. Division is based on the following characteristics.

- Attack surface: What infrastructure does the organisation provide/have which is prone to attacks aided
by a quantum computer?
- System types: Which kind of systems are handled and what is the impact of a malfunction of these systems?
- Data types: Which kind of data and information is handled in terms of criticality, disclosure sensitivity
and the consequences of unauthorised and undetected modification?
- Time pressure: How quickly does PQC migration need to take place to ensure safety of data and systems, taking into account store-now-decrypt-later attacks?
- Dependency on other organisations: How do different organisations depend on one another?
- Threat level: How realistic is it that a malicious actor with a quantum computer will choose to attack this organisation?

Urgent adopters 🚨❗

Urgency: Start PQC diagnosis as soon as possible

Subpersonas Urgent Adopters

- Organisations that handle personal data with a long confidentiality span (risk for store-now-decrypt-later attacks). E.g. Governments, organisations in healthcare such as hospitals, financial organisations and insurance providers. There are currently no laws in place for protecting personal data against quantum computers or the use of PQC to mitigate it. Note: The owners may be held responsible in case a quantum computer is used to decrypt data which is currently being stored
- Organisations that handle organisationally sensitive data with a long confidentiality span (risk for store-now-decrypt-later attacks). E.g. State secrets, transactions, minutes, trade secrets, and any information which is classified for entities outside of the organisation. Examples of such organisations are the military, national intelligence organisations, governments, financial organisations, knowledge institutes and universities. Impact of such data breach would be: breaking laws regarding personal information, losing (some of) its competitive advantage in the market, a loss of knowledge or state security, or a general negative impact on the entire economy.
- Organisations that provide systems that are crucial for the functioning of large groups of people e.g. towns, cities, provinces or even countries. Systems that provide things such as water, electricity, transport, communication and healthcare. Daily lives may be disrupted. It may cause serious damage, injury or even death. Malware or ransomware have shown how disruptive it can be for malfunctioning of such systems. Examples of critical infrastructure providers are energy or water providers, transport organisations
such as train companies or airports, communication companies such as telecom providers, web browsers and healthcare providers such as hospitals. - Organisations that provide systems which are built to have a long life-span Post-quantum cryptography usually has different (usually heavier) hardware requirements than current cryptography, because of which the production of systems with a lifespan of more than 20 years should already take these hardware requirements into account. Examples are satellites, payment terminals, cars, telecommunication networks, energy providers, smart meters, smart industry (4.0) and sensor networks.

Regular adopters

Any organisation that does not identify as any of the urgent adopter personas.

As organisation you do:
- Handle data
- Provide systems

However, the data is:
- Not prone to store-now-decrypt-later attacks
- Not critical or long-lived
- May be prone to attacks using a quantum computer
- Beneficial to await further standardisation

Urgency: There's no need to react immediately. However, organisations should make sure that they are in the best condition to migrate later. The following recommendations apply:

- Make sure they are up-to-date with the latest security guidelines (for instance migrate from TLS 1.2 to TLS 1.3)
- Favour crypto-agile solutions
- Predict performance of cryptographic algorithms on PQC update
- May start doing the risk-assessment and diagnosis steps
- Follow the standardisation efforts

Some organisations may want to act proactively and go further in applying the migration plan. Some reasons of which are:

- Your organisation is about to make large infrastructure investments

- Your organisation changes its activity or your organisation has new clients, which changes the risk assessment.

Either way, these steps will have to be taken at some point, so it is never completely useless to initiate diagnosis.

Cryptography Experts

We mention this persona because it is important:

- For urgent adopters to know this group exists
- What urgents adopters can expect from this group
- To bring concrete advice to this group. E.g. Cryptography Experts should be ready to expect questions from customers, PQC migration related
- Urgent adopters may ask whether their products are quantum-safe or not, if not, when they expect their products to be quantum-safe. Urgent adopters may have to choose to switch to a different vendor for their cryptographic assets.

Subpersonas Cryptography Experts

- Standard Developing Organisations: These are organisations that define cryptographic standards and/or protocols on national or international level Examples are NIST, ETSI, IETF, TLS, IEEE, ISO/IEC, TCG, ANSI, W3C and ENISA.
- Cryptographic Infrastructure Providers: Organisations that develop, implement or service cryptographic infrastructure on national or international level Examples are FOX - Crypto, Logius, Compumatica, NXP, Brightsight, Technolution, Apache and MSSPs (Managed Security Service Providers) such as Cipher and SecurityHQ.
for other companies to use. - Providers of Cryptography Beyond Secure Communication: Organisations that develop, implement or service infrastructure based on cryptographic protocols which are used for purposes beyond secure communication Examples of such protocols are blockchain, Zero-Knowledge Proofs, Multi-Party Computation and Idemix.


READ THIS BEFORE PROCEEDING: Note: Although this document describes the migration steps (diagnosing-planning-executing) sequentially, in practice an organisation should not wait to entirely complete one step before starting the next one. Organisations should start by identifying their most critical assets, planning a first migration phase for these critical parts and proceeding to this migration, while in parallel actively working on extending the diagnosis to a larger part of their infrastructure that will be migrated in a second phase.

Risk assessment

Risk is assessed using these parameters:

- The value of the information
- The vulnerability
- The threat

The quantum does not change the value of the information but it creates new vulnerabilities - some information that was protected by cryptographic algorithms considered secure in a classical model is not protected any more. Organisations should anticipate on new threats created by this situation. A proper risk assessment will be vital to decide which systems should be migrated first.

Inventory cryptographic assets

Identify all the cryptographic assets within your organisation, including assets that will soon enter the organisations. It will be used to determine whether a cryptographic asset is vulnerable to quantum attacks and which quantum-safe solution could be used instead. This inventory could take the form of a Configuration Management Database (CMDB). You may use automated assest discovery tools such as

- Make sure all assets will be correctly migrated
- Both software and hardware
- The information collected should be as detailed as possible, including the nature of the algorithm, key length, usage, etc.
- For assets that are not controlled by your organisation, you should identify the supplier
- Take into account that this step will take a significant amount of time.
- Useful outside the scope of this migration project
- Will ease the mitigation of both quantum and non-quantum threats
- May also be used to simplify compliance issues
- This inventory should be continuously updated
- This inventory or overview should be properly secured and cannot be accessed by outsiders, as it contains very sensitive data, such as vulnerabilities of an organisation

Inventory data assets

More precisely, you do not need an exhaustive list of the data, but rather a list of types of data, depending on several factors:

- Kind of data (data at rest, data in transit or data in use);
- Location of the data;
- Value of the data (confidentiality, availability);
- Classification of data;
- Risk assessment for each data asset.

Inventory of the suppliers of cryptographic assets.

For most organisations, a significant part of the cryptographic assets (hardware and software) are provided by external suppliers. The goal of this inventory is to identify your cryptography supply-chain.

- Large part of migration is making sure the suppliers are migrating or finding new suppliers that are quantum-safe
- For each supplier, list all products that you use from them and whether you have an ongoing contract with them
- List the supplier's contact details
- This list should also include certificate authorities
- Besides the official suppliers of cryptographic assets, consider internal communication tools (instant messaging, collaborative platforms) as well as shadow IT.

Note: this also holds the other way around, if you supply solutions using cryptography. The organisations you supply to will be making a similar assessment of their dependencies and might require you to properly communicate your intentions with respect to PQC. It is not necessary to make an exhaustive list of all of your clients but keep this in mind when deciding on an appropiate strategy.


This page is for organisations that identify as urgent adopters, or regular adopters who would like to act proactively.

Checklist before migration planning

- You went through diagnosis (previous page)
- You have information about your current security architecture of your organisation

When to migrate? (With migration scenarios)

In a few years, certified post-quantum cryptographic standards and libraries will be released. Migration policy will depend on whether the organisation can afford to wait. Others may start migrating today.

Different migration scenarios

Take a look at these three variables: - Namely the time X the asset must remain secure
- The migration time Y
- The time Z left until a quantum computer will be able to break public-key cryptography

X + Y < Z, called Mosca’s inequality. The closer X + Y is to Z, the more urgent the migration is

Note: that all of these variables are merely estimates and may not fully represent reality. They are meant as a test to understand whether it is time to migrate

To understand when to migrate - there are four options your organisation can choose for when to migrate.

1. NIST Standards Announced

  (PRESENT, Extremely Urgent Migration)

2. NIST Standards Announced

  (2024, Urgent Migration)

3. Production-level PQC Libraries Available

  (≥2024, Semi-Urgent Migration)

4. Industry-certified PQC Libraries Available

  (≥2024, Less Urgent Migration)

Hence, the total migration time X + Y when migrating from Scenario i can be rephrased as X + Wi + Yi, whereby • X is the estimated time the data must remain secret; • Wi is the estimated waiting time until the milestone associated with Scenario i; • Yi is the estimated time it takes to perform the migration in Scenario i.

For some organisations it will be vital to migrate from Scenario 1, 2 or 3, which will mean migrating to PQC standards without certified libraries being available. It should be mentioned that this brings an extra disadvantage because using uncertified libraries can lead to certification issues and using non-production-level code can lead to a slew of security problems It is important to note, however, that the current most-used standard for cryptography, FIPS 140-2, already allows for hybrid schemes

NOTE: Any organisations claiming to be using hybrid encryption, make sure it is classical AND post-quantum algorithms at the same time for encryption

Planning of the migration

This section will answer the following: - which cryptographic assets need replacement
- what to replace them with
- in which order you should replace them

This involves prioritising, identifying dependencies and anticipating some consequences of the migration, such as the necessity to temporarily isolate some data assets.