3. Applied Cryptography and Digital Trust

Introduction and Context

Cryptography is the engineering discipline that protects information by transforming it so that only authorised parties can interpret or use it. In cybersecurity, however, cryptography is not merely a collection of mathematical algorithms. It is part of a wider system of digital trust involving identities, keys, devices, software, policies, procedures, and institutions. A technically strong cipher can still provide weak protection if keys are poorly generated, stored, rotated, or revoked.

Modern organisations use cryptography to protect data at rest, data in transit, software updates, identity assertions, financial transactions, industrial commands, and cloud services. Public-key infrastructures support secure web browsing and enterprise authentication; digital signatures establish integrity and accountability; hardware security modules protect high-value keys; and secrets-management systems control access to passwords, tokens, and API credentials. At the same time, advances in quantum computing create a need for cryptographic agility and planned migration to post-quantum algorithms.

The central professional question is therefore not simply, “Which algorithm should be selected?” It is, “What trust properties are required, who is trusted to provide them, how are cryptographic assets governed throughout their life cycle, and how can the system remain secure when assumptions or algorithms change?”

Learning Objectives

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

1. Distinguish confidentiality, integrity, authentication, non-repudiation, and related cryptographic objectives.

2. Evaluate symmetric encryption, asymmetric cryptography, hashing, message authentication codes, and digital signatures.

3. Explain how PKI, certificate validation, key management, and trust models operate in practice.

4. Select suitable secure protocols and identify common implementation failures.

5. Compare software secrets management with hardware roots of trust.

6. Design a cryptographic-agility and post-quantum migration strategy.

7. Assess the organisational, ethical, regulatory, and operational implications of cryptographic decisions.

Cryptographic Objectives and the Meaning of Digital Trust

Confidentiality prevents unauthorised disclosure. Integrity provides confidence that data has not been altered undetectably. Authentication establishes the identity or origin of a party, message, or service. Authorisation determines what an authenticated entity may do. Availability is not created by cryptography alone, but cryptographic failures can affect it—for example, when expired certificates interrupt a service. Non-repudiation is a stronger and context-dependent claim that a signer cannot credibly deny an action; a digital signature contributes technical evidence, but legal and organisational controls determine whether that evidence is accepted.

Digital trust arises when an entity can reasonably rely on an identity claim, a cryptographic operation, or a system state. Trust is never purely mathematical. It depends on assumptions about certificate authorities, endpoint security, time sources, hardware, administrators, legal jurisdiction, and the continued security of algorithms. A trust decision should therefore identify its trust anchors and failure consequences.

Important Terminology

Plaintext is understandable input data; ciphertext is the transformed output of encryption. An encryption algorithm uses a key to provide a reversible transformation, whereas a hash function produces a fixed-length digest intended to be computationally difficult to reverse or find collisions for. A nonce is a value intended for one-time use in a cryptographic operation. A salt is a random value added to password processing so that identical passwords do not produce identical stored outputs. A key-encryption key protects other keys, while a data-encryption key protects operational data. A cryptographic primitive is a basic construction such as a block cipher, hash function, or signature scheme; a protocol combines primitives with messages, state, identities, and rules.

Symmetric Cryptography: Efficient Protection of Data

Symmetric cryptography uses the same secret key, or closely related secret keys, for encryption and decryption. Its principal advantage is efficiency. Block ciphers such as AES process fixed-size blocks, while authenticated-encryption modes such as AES-GCM and ChaCha20-Poly1305 provide confidentiality and integrity together. Authenticated encryption should generally be preferred to encryption-only designs because ciphertext manipulation must be detected rather than silently accepted.

A nonce must be unique under a given key in schemes such as GCM. Reusing a nonce can expose relationships between plaintexts and, in serious cases, compromise authentication. Nonces do not usually need to be secret, but their generation and storage must be designed carefully. Randomness, correct mode selection, key separation, and validation of authentication tags are operational requirements, not optional refinements.

Symmetric cryptography creates a distribution problem: communicating parties must obtain the same secret without exposing it. In a large organisation, pairwise key arrangements become difficult to administer. This limitation explains why symmetric and asymmetric cryptography are commonly combined rather than treated as competing alternatives.

Asymmetric Cryptography and Hybrid Design

Asymmetric cryptography uses a mathematically related public key and private key. The public key may be distributed openly; the private key must remain controlled by its owner. Public-key encryption can establish confidentiality without a pre-shared secret, while signature algorithms use the private key to create verifiable evidence that a message or transaction was approved by the holder of that key.

Asymmetric operations are generally slower and may involve larger keys or more complex validation than symmetric operations. Secure protocols therefore use hybrid cryptography. For example, a protocol may use an authenticated key-establishment mechanism to create a temporary symmetric session key, then use that session key for bulk data transfer. Ephemeral keys can provide forward secrecy: compromise of a long-term private key should not automatically reveal previously recorded sessions, provided the protocol and implementation are correctly designed.

The security of asymmetric systems depends on the authenticity of public keys. If an attacker substitutes a false public key, encryption may protect data from everyone except the attacker. Certificates, certificate authorities, transparency mechanisms, and explicit key verification address this problem, although each introduces governance and operational dependencies.

Hashing, Passwords, and Integrity Controls

A secure cryptographic hash has preimage resistance, second-preimage resistance, and collision resistance. Hashes are useful for file-integrity verification, content addressing, digital signatures, and constructing other protocols. A hash alone does not authenticate data: an attacker who can modify a file can often modify its hash as well. Integrity against an active adversary requires a secret-key MAC or a digital signature.

Password storage requires password-hashing functions designed to be expensive and memory-intensive, such as Argon2id, rather than fast general-purpose hashes. Each password should have a unique salt, and parameters should be calibrated to organisational resources and threat models. Peppering may add a separate secret held outside the password database. Password managers, phishing-resistant authentication, and hardware-backed credentials can reduce dependence on passwords altogether.

A MAC, such as HMAC, proves that a party possessing a shared secret generated the message and that the message was not altered. It does not provide public verifiability because every holder of the shared key could have generated the MAC. Digital signatures provide a different trust model and are suitable where many verifiers need to validate a statement without receiving the signing secret.

Digital Signatures and Trustworthy Transactions

A digital signature is created over a message or, more commonly, its hash. Verification uses a public key and confirms that the message corresponds to the signature. Signatures support software distribution, electronic contracts, financial instructions, certificates, audit records, and secure boot chains.

A signature does not prove that a human freely intended an action, that the underlying data was truthful, or that the signer was authorised for every possible use. Reliable systems bind signatures to context: the action, transaction amount, audience, timestamp, protocol version, and purpose should be explicit. Private signing keys require strong protection, and signature validation must include certificate status, validity periods, algorithm constraints, and trusted issuer rules.

PKI and the Architecture of Public Trust

Public-key infrastructure is the collection of technology, policies, roles, and procedures used to issue, distribute, validate, renew, suspend, and revoke certificates. A certificate binds a public key to an identity or service through a digitally signed statement. A root certificate authority is a trust anchor; intermediate authorities issue certificates under the root and reduce the need to use the root key directly. Registration authorities may verify identity before issuance.

Certificate validation is more than checking a date. A relying party should verify the signature chain, trust anchor, name or identity binding, key usage, algorithm constraints, validity period, and revocation or status information where applicable. Revocation may be communicated through certificate revocation lists or online status protocols. Large environments must also consider short-lived certificates, automated renewal, clock accuracy, inventory, and emergency replacement.

PKI models vary. In a hierarchical model, a root delegates to intermediates. In a web-of-trust model, trust is distributed through user certifications. In a federated enterprise, organisations may trust one another through agreed identity providers and certificate policies. Private PKIs are valuable for internal services, but their trust anchors must not be confused with those of the public Internet.

Key Management as a Life-Cycle Discipline

Key management is often the decisive factor in cryptographic security. A complete life cycle includes requirements analysis, generation, registration, distribution, activation, storage, backup, rotation, suspension, recovery, archival, destruction, and incident response. Keys should be classified by sensitivity and purpose. Reusing one key across encryption, signing, development, and production increases the impact of compromise and complicates evidence.

Key generation requires an approved random source and suitable parameters. Distribution should minimise exposure and authenticate the recipient. Storage may involve encrypted key stores, access-controlled services, hardware security modules, or platform key stores. Rotation limits exposure and supports policy, but rotation without a dependency inventory can cause outages. Destruction must address backups, replicas, caches, and exported copies.

Separation of duties is particularly important for root keys, certificate issuance, recovery operations, and high-value signing. Dual control or threshold approval can prevent one administrator from unilaterally creating or using sensitive keys. Key-management decisions should be documented in a cryptographic policy that defines algorithms, ownership, retention, recovery, audit, and exceptions.

Secrets Management and Hardware Roots of Trust

Secrets include passwords, API tokens, database credentials, private keys, signing material, and service-account credentials. Storing secrets in source code, container images, spreadsheets, or ordinary configuration files creates persistent exposure and makes rotation difficult. A secrets-management platform centralises protected storage, access policies, leasing, automated rotation, and audit trails. Applications should retrieve secrets at runtime through authenticated identities rather than embedding long-lived values.

A hardware root of trust is a protected component that anchors identity or cryptographic operations. Examples include trusted platform modules, secure elements, hardware security modules, and hardware-backed mobile keystores. Such components can protect private keys from ordinary operating-system compromise, support measured or secure boot, and enforce non-exportability. They do not make a system automatically secure: weak authorisation, compromised firmware, poor provisioning, or misuse of an authorised interface can still defeat the intended control.

Cloud key-management services provide scalable controls, but customers must understand shared-responsibility boundaries, provider access models, regional requirements, backup behaviour, and exit options. High-assurance environments may use customer-controlled or externally held keys, but greater control also brings greater operational responsibility.

Secure Protocols in Practice

Transport Layer Security illustrates layered cryptographic design. A modern TLS deployment negotiates algorithms, authenticates a server and sometimes a client, establishes session keys, and protects application traffic against alteration. Security depends on certificate validation, disabling obsolete protocol versions and cipher suites, correct hostname verification, secure randomness, and proper handling of session resumption.

Other protocols apply related principles. SSH uses host keys and user authentication; IPsec protects network-layer traffic; secure email combines encryption and signatures; software-update systems sign release metadata and packages. In every case, protocol security includes message ordering, replay protection, downgrade resistance, error handling, and endpoint verification. Implementers should use mature libraries and secure defaults rather than designing new cryptographic protocols.

Cryptographic Agility and Post-Quantum Migration

Cryptographic agility is the capability to change algorithms, parameters, keys, and providers without redesigning an entire system. It requires algorithm identifiers, versioned formats, central inventories, configurable policy, automated certificate renewal, and tests for migration and rollback. Agility does not mean permitting arbitrary algorithms; approved choices must remain constrained and observable.

Quantum algorithms create a long-term concern. A sufficiently capable quantum computer could threaten widely used public-key systems based on factoring or discrete logarithms, while symmetric cryptography is affected differently and can generally be strengthened through appropriate key sizes. The “harvest now, decrypt later” risk is important for information that remains sensitive for many years.

A post-quantum programme should begin with discovery: catalogue cryptographic assets, data lifetimes, protocols, dependencies, certificates, vendors, and embedded systems. Classify systems by exposure and replacement difficulty. Test standardised post-quantum mechanisms and hybrid approaches where appropriate, measure performance and message-size effects, update procurement requirements, and define transition milestones. Migration must include signatures, key establishment, firmware, archives, backups, and third-party services—not merely web encryption. Algorithms should be selected according to current standards and validated implementations rather than marketing claims.

Illustrative Case Study: University Research Cloud Migration

Background

A research university operated a hybrid cloud platform supporting medical-data analysis. The environment used public certificates for Internet-facing services, an internal PKI for service-to-service authentication, cloud key management for storage encryption, and several legacy applications with credentials stored in configuration files.

Situation and Problem

An expired intermediate certificate interrupted access to a data-processing service. Investigation found no complete certificate inventory, inconsistent renewal ownership, duplicated private keys, and several credentials committed to source repositories. The university also faced contractual requirements to protect research data for decades, raising concern about future cryptanalytic advances.

Analysis

The immediate outage was a life-cycle and governance failure rather than a failure of the underlying cryptographic algorithms. The university lacked ownership records, automated renewal, separation between development and production, and a defined recovery process. Long-lived research data increased the significance of future public-key migration.

Approach and Solution

The security team created a cryptographic asset register covering certificates, keys, algorithms, owners, locations, expiry dates, data lifetimes, and dependencies. It moved application credentials into a secrets-management service and replaced static credentials with workload identities where feasible. Root and intermediate CA duties were separated, certificate issuance was logged, and automated renewal was tested before deployment.

Storage encryption keys were separated by environment and data classification. High-value signing keys were moved to hardware-backed services with multi-person approval. TLS validation and monitoring were standardised through approved libraries and configuration baselines. Finally, the university began a post-quantum discovery project, prioritising long-retention research archives and systems with difficult upgrade paths.

Outcome

The organisation reduced the likelihood of certificate-related outages, improved auditability, limited the blast radius of credential compromise, and gained a migration roadmap. It did not claim that post-quantum migration was complete; instead, it established visibility and tested change mechanisms.

Learning Points

The case demonstrates that digital trust is an operational system. Inventory, ownership, automation, monitoring, recovery, and policy are as important as algorithm selection. It also shows why cryptographic agility must be developed before an emergency, not during one.

Risks, Limitations, and Professional Responsibilities

Common mistakes include using encryption without authentication, reusing nonces, selecting algorithms because they are familiar rather than approved, disabling certificate validation to solve an outage, storing keys beside encrypted data, failing to rotate compromised secrets, and assuming that a private key is safe merely because it is hidden in application code. Another serious error is treating compliance as proof of security. Compliance may establish a baseline, but it cannot replace threat modelling and operational testing.

Cryptography can create tensions involving lawful access, privacy, data localisation, and investigative needs. Weakening encryption through hidden access mechanisms introduces systemic risk and may expose innocent users. Organisations should apply data minimisation, transparent governance, access logging, retention limits, and independent review. Sensitive cryptographic operations should be auditable without unnecessarily exposing plaintext or personal data.

Effective practice includes the following principles:

• Use authenticated encryption and well-reviewed, standardised libraries.
• Maintain an authoritative inventory of keys, certificates, algorithms, owners, and dependencies.
• Separate key purposes, environments, duties, and administrative privileges.
• Automate renewal, rotation, status monitoring, and alerting where possible.
• Protect high-value keys with hardware-backed controls and multi-person governance.
• Test backup, recovery, revocation, compromise response, and algorithm replacement.
• Design protocols with forward secrecy, replay protection, downgrade resistance, and explicit identity validation.
• Include cryptographic requirements in procurement, architecture review, software development, and incident response.

Chapter Summary

Applied cryptography combines mathematical primitives with identity, policy, software, hardware, and operational governance. Symmetric encryption provides efficient data protection, while asymmetric cryptography enables scalable key establishment and public verification. Hashes support integrity but do not authenticate data; MACs authenticate shared-secret messages; digital signatures support publicly verifiable transactions. PKI binds identities to public keys, but certificate validation and authority governance remain essential.

Key management covers the complete life cycle from generation to destruction. Secrets-management platforms and hardware roots of trust reduce exposure when correctly governed. Secure protocols depend on implementation details such as nonce uniqueness, certificate validation, forward secrecy, and downgrade resistance. Cryptographic agility, asset discovery, and staged post-quantum migration are now strategic capabilities, particularly for long-lived sensitive information. The strongest cryptographic design is therefore one that is technically sound, operationally manageable, auditable, and capable of change.

Key Terms

Symmetric cryptography: Cryptography using a shared secret key for related encryption and decryption operations.

Asymmetric cryptography: Cryptography using mathematically related public and private keys.

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

Hash function: A function producing a fixed-length digest with intended one-way and collision-resistant properties.

MAC: A message authentication code generated with a shared secret.

Digital signature: A private-key-generated value that can be publicly verified against a message and public key.

Nonce: A value intended for controlled, often one-time, use in a cryptographic operation.

Salt: A random value added to password processing to frustrate precomputation and duplicate outputs.

PKI: The technology, policies, roles, and procedures governing public-key certificates and trust.

Certificate authority: An entity that issues and signs certificates.

Trust anchor: A pretrusted key or certificate from which validation begins.

Key life cycle: The stages through which a cryptographic key is generated, used, protected, rotated, archived, and destroyed.

Forward secrecy: Protection ensuring that later compromise of a long-term key does not reveal earlier sessions.

Secrets management: Controlled storage, access, rotation, and auditing of credentials and other sensitive values.

Hardware root of trust: A protected hardware component anchoring identity or cryptographic operations.

Cryptographic agility: The ability to change cryptographic algorithms and parameters with limited disruption.

Post-quantum cryptography: Cryptographic methods intended to resist attacks from quantum computers.

Key-encryption key: A key used to protect another cryptographic key.

Nonce reuse: Repeating a nonce with the same key, potentially compromising confidentiality or authentication.

Review Questions

Short Answer Questions

1. Why does encryption alone not guarantee message integrity?

2. Distinguish a MAC from a digital signature.

3. What is the function of a certificate authority in PKI?

4. Why are salts used when storing passwords?

5. Define cryptographic agility.

Long Answer Questions

1. Explain how symmetric and asymmetric cryptography are combined in a hybrid secure protocol.

2. Describe the major stages of a cryptographic key life cycle and the controls required at each stage.

3. Explain certificate validation and the operational causes of PKI failure.

4. Discuss how hardware roots of trust and secrets-management platforms complement one another.

5. Develop a post-quantum migration plan for an organisation holding long-retention sensitive data.

Analytical / Application Questions

1. A web service uses AES-GCM but occasionally repeats nonces after a server restart. Analyse the risk and recommend controls.

2. An organisation stores API tokens in a private source repository and uses one token across all environments. Design a safer replacement architecture.

3. A certificate outage occurs because no team owns renewal and the organisation has no certificate inventory. Analyse the governance failure and propose an improvement programme.

22. Multiple Choice Questions with Answers

Question 1

Which control provides integrity and authentication for a message using a shared secret?

A. A cryptographic hash alone

B. A message authentication code

C. A digital certificate without validation

D. Unauthenticated encryption

Correct Answer: B. A message authentication code

Question 2

Why are symmetric and asymmetric cryptography commonly combined in secure protocols?

A. Asymmetric cryptography is always faster for bulk data

B. Symmetric cryptography eliminates the need for identity

C. Asymmetric methods help establish keys while symmetric methods efficiently protect data

D. Symmetric methods provide public verifiability

Correct Answer: C. Asymmetric methods help establish keys while symmetric methods efficiently protect data

Question 3

What is the principal danger of reusing a nonce with AES-GCM under the same key?

A. The certificate authority becomes unavailable

B. Confidentiality and authentication may be compromised

C. The key automatically becomes longer

D. Password salts are discarded

Correct Answer: B. Confidentiality and authentication may be compromised

Question 4

Which statement best describes a certificate trust anchor?

A. A temporary session key generated by a client

B. A pretrusted key or certificate from which validation begins

C. A password stored in an application image

D. A hash digest that encrypts a file

Correct Answer: B. A pretrusted key or certificate from which validation begins

Question 5

Why is a password-specific hashing function preferred over a fast general-purpose hash?

A. It makes passwords reversible for administrators

B. It increases the cost of large-scale guessing attacks

C. It removes the need for unique salts

D. It provides public-key encryption

Correct Answer: B. It increases the cost of large-scale guessing attacks

Question 6

Which property is most directly associated with ephemeral session keys?

A. Forward secrecy

B. Certificate revocation

C. Password peppering

D. Data compression

Correct Answer: A. Forward secrecy

Question 7

A company discovers private signing keys embedded in source code. What is the most appropriate first response?

A. Rename the source files

B. Assume the repository is private and take no action

C. Revoke or replace the exposed keys and investigate their use

D. Hash the keys without changing them

Correct Answer: C. Revoke or replace the exposed keys and investigate their use

Question 8

Which feature most directly supports cryptographic agility?

A. Hard-coding one algorithm throughout every application

B. Versioned formats and centrally governed algorithm configuration

C. Using the same key for every purpose

D. Disabling certificate expiry checks

Correct Answer: B. Versioned formats and centrally governed algorithm configuration

Question 9

Why should post-quantum migration begin with cryptographic discovery?

A. Every algorithm can be replaced without testing

B. Discovery identifies assets, dependencies, data lifetimes, and difficult-to-replace systems

C. It guarantees that quantum computers already exist

D. It eliminates the need for symmetric encryption

Correct Answer: B. Discovery identifies assets, dependencies, data lifetimes, and difficult-to-replace systems

Question 10

Which statement about hardware roots of trust is most accurate?

A. They eliminate all risks caused by compromised software

B. They can protect keys and support trusted operations but still depend on provisioning and policy

C. They make certificate validation unnecessary

D. They allow private keys to be safely published

Correct Answer: B. They can protect keys and support trusted operations but still depend on provisioning and policy