Emerging Cryptography, AI, and Future Readiness

Introduction and Context

Cryptography is not a finished technology. It changes as computing power, communication systems, regulation, and adversarial capabilities develop. A cryptographic design that is secure today may become unsafe when new mathematical attacks, implementation weaknesses, or quantum computers emerge. Future-ready cybersecurity therefore requires more than selecting a strong algorithm. It requires understanding technological change, managing transitions, protecting privacy, and making responsible decisions about automation.

This chapter examines six closely related areas: post-quantum cryptography, quantum threats, crypto-agility, lightweight cryptography, privacy-enhancing technologies, blockchain applications, and artificial intelligence in cryptographic operations. These areas should not be treated as isolated innovations. They form part of a broader lifecycle in which cryptographic systems are designed, deployed, monitored, updated, and eventually retired.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain why quantum computing threatens some widely used public-key algorithms.
2. Describe the purpose and main families of post-quantum cryptography.
3. Explain crypto-agility and identify practical steps for migration.
4. Distinguish lightweight cryptography from conventional cryptography.
5. Describe important privacy-enhancing technologies and their uses.
6. Evaluate appropriate and inappropriate applications of blockchain.
7. Explain how artificial intelligence can support cryptographic operations and how it can introduce risk.
8. Apply a structured approach to future-readiness and cryptographic governance.

1. The Quantum Threat

1.1 Classical public-key cryptography

Many current systems use public-key cryptography for key establishment, digital signatures, identity management, and secure web connections. Two historically important families are RSA, based on the difficulty of integer factorisation, and elliptic-curve cryptography, based on the difficulty of certain discrete logarithm problems.

Their security depends on the practical inability of classical computers to solve these mathematical problems at operational scale. Symmetric cryptography, such as AES, is affected differently. A sufficiently powerful quantum computer could use Grover’s algorithm to search a key space faster than a classical exhaustive search. This does not destroy symmetric cryptography, but it reduces its effective security margin. Using adequately long keys and sound implementation remains an important mitigation.

1.2 Shor’s algorithm and cryptographic disruption

Shor’s algorithm provides a quantum method for solving integer factorisation and discrete logarithm problems more efficiently than known classical methods. If a cryptographically relevant quantum computer becomes available, it could compromise many RSA, Diffie–Hellman, and elliptic-curve deployments, including systems used for certificates, virtual private networks, secure email, and software signing.

The threat is not only immediate decryption. An adversary may copy encrypted traffic today and attempt to decrypt it later after obtaining a quantum computer. This is called harvest now, decrypt later. It is especially serious where information has a long confidentiality lifetime, such as medical records, defence information, intellectual property, and diplomatic communications.

1.3 Security migration is a lifecycle problem

Quantum risk depends on several factors:

• the expected availability of cryptographically relevant quantum computers;
• the value and required secrecy period of protected information;
• the time needed to inventory, redesign, test, and replace cryptographic systems;
• dependence on suppliers, standards, firmware, and embedded devices; and
• the possibility that systems cannot be updated after deployment.

Organisations should therefore begin preparation before a cryptographically relevant quantum computer exists. Waiting for a confirmed breakthrough may leave insufficient time for migration.

2. Post-Quantum Cryptography

Post-quantum cryptography, or PQC, consists of cryptographic algorithms intended to resist attacks from both classical and quantum computers. PQC is not the same as quantum cryptography. PQC normally runs on existing classical computers and networks. Quantum cryptography, by contrast, uses quantum physical effects and requires specialised communication equipment.

2.1 Main algorithm families

Several mathematical approaches have been studied:

The table describes broad families, not a guarantee that every algorithm within a family is secure. Security depends on the precise construction, parameter choice, implementation, and continuing cryptanalysis.

2.2 Key encapsulation and digital signatures

A key encapsulation mechanism, or KEM, allows two parties to establish a shared secret over an insecure network. A simplified process is:

1. The recipient generates a public key and a private key.
2. The sender uses the public key to encapsulate a randomly generated shared secret.
3. The sender transmits the encapsulated value.
4. The recipient uses the private key to decapsulate the same shared secret.
5. Both parties use the shared secret with symmetric encryption and authentication.

Digital signatures serve different purposes. They provide authenticity, integrity, and evidence that a holder of a private signing key approved a message or software release. A migration plan must therefore address both key establishment and signatures. Replacing only encryption while leaving vulnerable signature systems in place does not provide complete quantum resilience.

2.3 Hybrid deployment

A hybrid design combines a classical algorithm with a post-quantum algorithm. For example, a session key may be derived from outputs of both a conventional key exchange and a PQC KEM. If the combination is designed correctly, compromise of one component should not expose the session key, provided the other component remains secure and the key-combination process is sound.

Hybrid deployment can reduce transition risk, but it increases message sizes, implementation complexity, testing requirements, and operational cost. It must not be treated as automatically secure merely because two algorithms are present.

2.4 Migration inventory

A practical PQC programme begins with cryptographic discovery. The organisation should identify:

• algorithms and key sizes in use;
• certificates, certificate authorities, and trust stores;
• protocols such as TLS, IPsec, SSH, and secure messaging;
• software-signing and firmware-signing processes;
• hardware security modules and embedded cryptographic libraries;
• data with long confidentiality requirements;
• suppliers and services that cannot be modified internally; and
• locations where cryptography is hidden in applications, appliances, or operational technology.

A cryptographic bill of materials can record algorithm, purpose, owner, system, data classification, expiry date, dependency, and replacement plan. This turns an invisible technical dependency into a manageable organisational asset.

3. Crypto-Agility

Crypto-agility is the ability to replace or modify cryptographic algorithms, parameters, keys, certificates, and protocols without unacceptable disruption. It is a design and governance capability, not a single software product.

3.1 Principles of crypto-agile design

Important principles include:

• Algorithm separation: applications should call well-defined cryptographic services rather than implement algorithms throughout business logic.
• Configuration rather than hard-coding: approved algorithms and parameters should be changeable through controlled configuration.
• Explicit algorithm identification: protocols should identify algorithms unambiguously and reject unsafe or unknown values.
• Centralised policy: security teams should define approved cryptographic profiles, while systems enforce them.
• Key and certificate lifecycle management: generation, distribution, rotation, revocation, archival, and destruction must be planned.
• Versioned interfaces: cryptographic libraries and services should support controlled upgrades.
• Testing and rollback: changes require test environments, monitoring, staged release, and recovery procedures.

3.2 Governance model

Crypto-agility requires cooperation among security architects, software engineers, procurement teams, legal specialists, risk managers, and system owners. Procurement contracts should require information about algorithms, update support, certificate handling, vulnerability response, and end-of-life procedures.

A useful governance cycle is:

1. Discover cryptographic dependencies.
2. Classify data and system criticality.
3. Assess current and future threats.
4. Select approved algorithms and migration priorities.
5. Test interoperability and performance.
6. Deploy in stages.
7. Monitor failures, attacks, and cryptographic developments.
8. Retire obsolete components and update the inventory.

3.3 Common obstacles

Legacy applications often contain hard-coded algorithms, proprietary formats, or unsupported libraries. Internet of Things devices may lack sufficient memory or update mechanisms. Certificate chains may exceed size limits when new signatures are introduced. Performance may degrade because PQC keys and signatures can be larger than classical equivalents. These issues are engineering constraints, not reasons to postpone planning.

4. Lightweight Cryptography

Lightweight cryptography is designed for devices with constrained memory, processing power, energy, bandwidth, or physical size. Examples include sensors, smart cards, industrial controllers, medical devices, and low-power wireless equipment.

Lightweight does not mean weak. It means that the algorithm and implementation are designed to achieve an appropriate security level under resource constraints. Security must still include confidentiality, integrity, authentication, and resistance to implementation attacks.

4.1 Design trade-offs

A lightweight system may reduce code size, memory use, communication overhead, or energy consumption. However, reducing resource use can create trade-offs:

• smaller messages may limit flexibility;
• lower computation may increase reliance on secure hardware;
• simple interfaces may make misuse more likely;
• constrained devices may lack secure random-number generation;
• physical access may expose keys through side-channel or fault attacks.

Authenticated encryption is generally preferable to using encryption alone because it protects confidentiality and detects unauthorised modification. A nonce, or number used once, must follow the algorithm’s rules. Reusing a nonce with the same key can seriously compromise security for many authenticated-encryption schemes.

4.2 Deployment guidance

Before selecting a lightweight algorithm, designers should measure energy consumption, latency, memory use, code size, message expansion, hardware acceleration, update capability, and resistance to physical attacks. They should also examine the complete system rather than the primitive alone. A mathematically strong algorithm cannot compensate for an exposed key, predictable randomness, unsafe firmware updates, or poor access control.

5. Privacy-Enhancing Technologies

Privacy-enhancing technologies, or PETs, reduce unnecessary disclosure or enable useful processing without exposing all underlying information. They support data minimisation, purpose limitation, and controlled disclosure.

5.1 Important PET categories

5.2 Differential privacy

Differential privacy provides a formal way to limit how much the inclusion or removal of one person’s record changes the distribution of an output. It is commonly described using a privacy parameter, often written as ε. Smaller ε generally indicates stronger privacy, but the relationship between privacy, accuracy, query composition, and repeated releases must be analysed carefully. Differential privacy is not the same as simply removing names; it addresses inference from outputs.

5.3 PET selection

PETs should be selected according to the threat model. If the main risk is unauthorised database access, encryption and access control may be central. If several organisations do not trust one another but need aggregate results, secure multiparty computation may be relevant. If a public body releases statistics, differential privacy may be appropriate. PETs can reduce risk, but they do not remove the need for governance, secure implementation, data-quality controls, and legal compliance.

6. Blockchain and Cryptographic Applications

A blockchain is a distributed record system in which cryptographic techniques help participants agree on the ordering and integrity of records. Hash functions link records, digital signatures authenticate transactions, and a consensus mechanism determines which updates are accepted.

6.1 Appropriate uses

Blockchain may be useful where multiple organisations need a shared record, do not want one participant to control the database completely, and can define rules for participation and correction. Potential applications include supply-chain provenance, inter-organisational audit trails, digital credentials, asset registries, and automated settlement.

6.2 What blockchain does not guarantee

Blockchain does not guarantee that input data is true. It does not automatically provide confidentiality, legal validity, fair governance, or resistance to all attacks. If false information is entered by an authorised participant, the ledger may preserve false information very reliably. Public blockchains may also expose transaction relationships, create scalability problems, and consume substantial resources depending on their consensus design.

Immutability can conflict with privacy and data-protection rights. Sensitive personal data should generally not be placed directly on a broadly replicated ledger. A safer design may store protected data off-chain and place only a carefully designed commitment, reference, or proof on-chain. Even then, metadata and linkability must be assessed.

6.3 Smart contracts

Smart contracts are programs that execute agreed rules on a blockchain platform. They can automate transfers and verification, but code defects may produce irreversible consequences. Secure development requires code review, testing, formal analysis where appropriate, access-control checks, incident response, and a governance mechanism for exceptional events.

7. Artificial Intelligence in Cryptographic Operations

Artificial intelligence can assist cryptographic work, but it does not replace cryptographic proof, expert review, or governance.

7.1 Beneficial applications

AI and machine learning may support:

• discovery of cryptographic algorithms and libraries in large codebases;
• classification of systems according to migration urgency;
• detection of unusual certificate, key, or protocol behaviour;
• prioritisation of patching and certificate renewal;
• identification of possible side-channel patterns in controlled testing;
• analysis of malware that attempts to steal keys;
• generation of test cases and protocol misuse scenarios; and
• optimisation of resource allocation in cryptographic infrastructure.

AI can also help security teams search technical inventories and identify systems that use obsolete algorithms. Its recommendations should remain explainable enough for experts to validate.

7.2 Risks and limitations

AI systems may hallucinate insecure code, recommend deprecated algorithms, misunderstand protocol context, or produce plausible but incorrect security explanations. Training data may contain vulnerable examples or confidential material. An AI assistant connected to key-management systems could become a high-impact attack target. Prompt injection, data poisoning, model theft, and unauthorised automation are relevant risks.

AI should never be permitted to invent keys, bypass approval controls, disable cryptographic protections, or make irreversible trust decisions without appropriate safeguards. Secret keys must not be submitted to external AI services. High-risk actions should require separation of duties, authenticated approval, logging, and independent verification.

7.3 Ethical principles

Responsible use of AI in cryptographic operations should follow these principles:

• Confidentiality: protect keys, personal data, and sensitive system information.
• Integrity: validate generated code, configurations, and recommendations.
• Human accountability: assign responsibility to named decision-makers.
• Transparency: record why an automated recommendation was accepted.
• Fairness: check whether automated prioritisation disadvantages particular groups or regions.
• Proportionality: use the least intrusive level of automation that achieves the security goal.
• Reversibility: ensure that high-impact actions can be reviewed and, where possible, undone.

8. An Integrated Future-Readiness Framework

A future-ready organisation treats cryptography as critical infrastructure. Its framework should include five dimensions.

Technology

Maintain approved algorithms, secure libraries, hardware support, randomness sources, monitoring, and tested update mechanisms.

Information

Classify data by sensitivity and required confidentiality lifetime. Protect long-lived information against harvest now, decrypt later attacks.

People

Train developers, administrators, procurement staff, auditors, and managers. Ensure that cryptographic responsibility is not concentrated in one unavailable specialist.

Governance

Maintain policy, inventories, ownership, risk acceptance, supplier requirements, incident response, and independent assurance.

Change management

Test new algorithms, support interoperability, measure performance, communicate changes, and retire obsolete technology deliberately.

A useful prioritisation method considers exposure, data lifetime, system criticality, migration complexity, and supplier dependence. The output should be a staged roadmap rather than a vague statement that the organisation will become quantum-safe in the future.

Applied Case: Illustrative Healthcare Migration

Background

A regional healthcare network operates hospitals, diagnostic laboratories, cloud applications, connected medical devices, and a long-term patient-record archive. The network uses conventional public-key cryptography for web services, remote administration, software updates, and digital certificates.

Problem

An initial review discovers that the organisation has no complete cryptographic inventory. Some medical devices cannot be updated remotely, several suppliers do not document their algorithms, and archived records must remain confidential for decades. The organisation is concerned about harvest now, decrypt later attacks and future disruption caused by rushed migration.

Analysis

The highest priorities are long-lived patient records, software-signing keys, remote access, certificate authorities, and devices that cannot easily be replaced. The organisation also identifies a privacy risk in a proposed blockchain project intended to share laboratory results. Directly placing patient data on a replicated ledger would create unnecessary exposure and conflict with correction and deletion requirements.

Approach and solution

The network establishes a cryptographic asset register containing algorithms, key owners, certificate dependencies, data lifetime, suppliers, and update capability. It adopts a central cryptographic service for new applications and introduces crypto-agile interfaces. New remote-access services are tested with a hybrid key-establishment approach using approved classical and post-quantum components. The organisation requires suppliers to publish migration plans and support secure firmware updates.

The blockchain proposal is redesigned. Patient records remain in governed clinical systems, while a limited integrity proof is stored separately for audit purposes. Access remains subject to healthcare privacy controls. An AI tool is used to identify obsolete libraries in source repositories, but every finding is reviewed by engineers before remediation.

Outcome

The organisation does not claim that all systems are immediately quantum-safe. Instead, it gains visibility, prioritises high-value information, tests migration paths, reduces unnecessary data disclosure, and creates a repeatable process for future algorithm changes.

Learning points

1. Discovery is a prerequisite for migration.
2. Long-lived confidentiality changes the urgency of quantum preparation.
3. Crypto-agility reduces the cost and risk of future replacement.
4. Blockchain should solve a clearly defined coordination problem, not serve as a general-purpose database.
5. AI can accelerate analysis but must not replace human accountability.

Challenges and Limitations

Emerging cryptography is subject to uncertainty. New algorithms may be weakened by future cryptanalysis. Standards and implementations may evolve. Larger PQC messages can affect bandwidth, certificate chains, and embedded systems. PETs may reduce analytical accuracy or impose substantial computation. Blockchain governance can be politically and technically difficult. AI systems can create false confidence and expand the attack surface.

There is also a strategic risk of technology-driven decision-making. An organisation may adopt a fashionable technology without identifying the actual threat or business requirement. Sound security begins with assets, adversaries, consequences, and controls. Technology selection follows that analysis.

Best-Practice Checklist

• Maintain a complete, owned cryptographic inventory.
• Identify information requiring long-term confidentiality.
• Separate key establishment from digital-signature migration planning.
• Use approved, reviewed implementations rather than experimental code in production.
• Design systems with replaceable algorithms and central policy controls.
• Test PQC and hybrid protocols for performance and interoperability.
• Protect randomness, keys, certificates, and firmware-signing processes.
• Select PETs according to a documented threat model.
• Avoid placing unnecessary personal data on blockchains.
• Treat AI outputs as recommendations requiring validation.
• Log, review, and approve high-impact automated actions.
• Include cryptographic lifecycle requirements in supplier contracts.
• Plan decommissioning, recovery, and incident response before deployment.

Chapter Summary

Future-ready cryptography requires continuous adaptation. Quantum computing threatens important classical public-key systems, making post-quantum migration a present planning concern, especially for information requiring long-term confidentiality. PQC includes several mathematical families and must address both key establishment and digital signatures. Hybrid deployment can support transition, but it introduces complexity and must be engineered carefully.

Crypto-agility enables organisations to replace algorithms, keys, certificates, and protocols without redesigning every application. Lightweight cryptography addresses constrained devices while retaining appropriate security. Privacy-enhancing technologies reduce unnecessary disclosure through methods such as tokenisation, differential privacy, secure computation, homomorphic encryption, trusted execution environments, and federated learning.

Blockchain uses cryptographic integrity and consensus but does not guarantee truthful input, privacy, or sound governance. Artificial intelligence can improve discovery, monitoring, testing, and prioritisation, but it can also generate insecure recommendations, expose secrets, and automate harmful decisions. Human accountability, validation, least privilege, transparency, and strong lifecycle governance are essential.

The central professional lesson is that cryptographic strength is only one part of security. Future readiness depends on visibility, sound design, update capability, privacy awareness, responsible automation, and disciplined change management.

Key Terms

Post-quantum cryptography: Cryptography designed to resist attacks by classical and quantum computers.

Quantum computer: A computer that uses quantum-mechanical states to perform certain computations.

Shor’s algorithm: A quantum algorithm that threatens factorisation- and discrete-logarithm-based public-key systems.

Grover’s algorithm: A quantum search algorithm that can reduce the effective security margin of symmetric keys.

Harvest now, decrypt later: Collecting encrypted information now for possible future decryption.

Key encapsulation mechanism: A mechanism for establishing a shared secret using public-key techniques.

Crypto-agility: The capability to replace cryptographic components with limited disruption.

Lightweight cryptography: Cryptography designed for constrained devices and environments.

Nonce: A value intended for controlled, often single, use in a cryptographic operation.

Privacy-enhancing technology: A technology that reduces privacy risk or limits unnecessary data disclosure.

Differential privacy: A formal privacy approach that limits the effect of one individual’s data on an output.

Homomorphic encryption: Encryption that permits specified computations on encrypted data.

Federated learning: Collaborative model training in which data remains near its original source.

Blockchain: A distributed record system using cryptographic linking and a consensus process.

Smart contract: A program that executes defined rules on a blockchain platform.

Cryptographic inventory: A structured record of algorithms, keys, certificates, uses, owners, and dependencies.

Cryptographic agility roadmap: A staged plan for assessing, testing, replacing, and retiring cryptographic components.

Side-channel attack: An attack that infers secrets from physical effects such as timing, power, or electromagnetic emissions.

Authenticated encryption: Encryption that provides confidentiality and detects unauthorised modification.

Cryptographic bill of materials: A record of cryptographic components and their relationships within systems.

Review Questions

5 Short Answer Questions

1. Why can quantum computing threaten RSA and elliptic-curve cryptography?
2. What is the difference between post-quantum cryptography and quantum cryptography?
3. Define crypto-agility and give one example of its value.
4. Why is nonce management important in lightweight authenticated encryption?
5. Name two privacy-enhancing technologies and describe one use for each.

5 Long Answer Questions

1. Explain the main stages an organisation should follow when preparing for post-quantum migration.
2. Compare lattice-based, hash-based, and code-based post-quantum cryptography, including one practical concern for each.
3. Discuss how crypto-agility depends on architecture, governance, procurement, and testing.
4. Evaluate the benefits and limitations of blockchain for inter-organisational healthcare records.
5. Explain the ethical and security requirements for using AI in cryptographic operations.

3 Analytical / Application Questions

1. A company stores financial records that must remain confidential for twenty-five years. Develop a prioritised plan addressing harvest now, decrypt later risk, cryptographic inventory, and migration testing.
2. A manufacturer wants to deploy low-power sensors with limited memory and intermittent connectivity. Analyse the security and engineering factors that should guide lightweight-cryptography selection.
3. A government agency proposes using an AI system to approve certificate renewals automatically. Evaluate the proposal and design controls for authentication, human oversight, logging, failure recovery, and protection of private keys.

Multiple Choice Questions with Answers

Question 1

Which classical public-key systems are most directly threatened by Shor’s algorithm?

A. RSA and elliptic-curve systems

B. AES and ChaCha20 only

C. Cryptographic hash functions only

D. Tokenisation systems only

Correct Answer: A. RSA and elliptic-curve systems

Question 2

What is the main purpose of post-quantum cryptography?

A. To require quantum hardware for every secure connection

B. To resist attacks from classical and quantum computers using deployable cryptography

C. To eliminate the need for digital signatures

D. To store all data on a blockchain

Correct Answer: B. To resist attacks from classical and quantum computers using deployable cryptography

Question 3

Which capability is central to crypto-agility?

A. Hard-coding one algorithm permanently

B. Replacing algorithms and keys with limited disruption

C. Disabling certificate renewal

D. Avoiding cryptographic inventories

Correct Answer: B. Replacing algorithms and keys with limited disruption

Question 4

Why can hybrid post-quantum deployment be useful?

A. It removes the need for testing

B. It combines classical and post-quantum components during transition

C. It guarantees that every algorithm is secure

D. It makes messages smaller in every case

Correct Answer: B. It combines classical and post-quantum components during transition

Question 5

Which statement best describes lightweight cryptography?

A. It is cryptography that intentionally provides no authentication

B. It is designed for constrained devices while maintaining an appropriate security level

C. It is only used for public blockchains

D. It always uses shorter keys than every conventional algorithm

Correct Answer: B. It is designed for constrained devices while maintaining an appropriate security level

Question 6

What does differential privacy primarily limit?

A. The effect of one individual’s data on an output

B. The physical size of a server

C. The number of blockchain validators

D. The speed of public-key encryption

Correct Answer: A. The effect of one individual’s data on an output

Question 7

What does a blockchain not automatically guarantee?

A. Cryptographic linking of records

B. That input data is truthful or that privacy requirements are satisfied

C. Some form of transaction authentication

D. A distributed record structure

Correct Answer: B. That input data is truthful or that privacy requirements are satisfied

Question 8

Which is an appropriate use of AI in cryptographic operations?

A. Submitting private keys to a public AI service

B. Allowing an unreviewed model to disable encryption

C. Identifying obsolete cryptographic libraries for expert review

D. Letting a model invent production algorithms

Correct Answer: C. Identifying obsolete cryptographic libraries for expert review

Question 9

What is harvest now, decrypt later?

A. Deleting encrypted data before it is needed

B. Collecting encrypted data for possible future decryption

C. Rotating keys after every message

D. Using blockchain to archive public records

Correct Answer: B. Collecting encrypted data for possible future decryption

Question 10

Why should sensitive personal data generally not be placed directly on a broadly replicated blockchain?

A. Blockchains cannot store any data

B. Replication, linkability, and difficulty of correction can create privacy problems

C. Digital signatures cannot be used on blockchains

D. Hash functions reveal every original value

Correct Answer: B. Replication, linkability, and difficulty of correction can create privacy problems