Applied Cryptography and Key Management

Introduction and Context

Cryptography is the engineering discipline that protects information against unauthorized disclosure, alteration, impersonation, and repudiation. In network security, cryptography is not an isolated collection of algorithms. It is a system of algorithms, protocols, implementation practices, operational controls, and governance mechanisms. A mathematically strong cipher can still provide weak security if keys are generated predictably, stored insecurely, reused improperly, or not revoked when compromise is suspected.

Modern cryptographic engineering therefore addresses several security objectives:

• Confidentiality: preventing unauthorized disclosure.
• Integrity: detecting unauthorized modification.
• Authentication: establishing the identity or authority of a communicating party.
• Non-repudiation: providing evidence that supports attribution, subject to legal and operational assumptions.
• Forward secrecy: preventing compromise of a long-term key from exposing previous sessions.
• Availability and recoverability: ensuring that cryptographic controls do not make essential data permanently inaccessible.

This chapter examines symmetric and asymmetric cryptography, hash functions, message authentication codes, digital signatures, random-number generation, public-key infrastructure, certificates, TLS, protocol design, secrets management, key lifecycles, and preparation for post-quantum cryptography.

Learning Objectives

After completing this chapter, a student should be able to:

1. Compare symmetric and asymmetric encryption and select appropriate uses for each.

2. Explain the security properties and limitations of hashes, MACs, and digital signatures.

3. Evaluate randomness requirements and identify insecure key-generation practices.

4. Explain PKI, certificate validation, revocation, and trust models.

5. Analyze the security operation of TLS and common protocol failures.

6. Design a defensible key and secrets lifecycle.

7. Assess governance, implementation, and post-quantum migration requirements.

1. Cryptographic Security Models

A cryptosystem normally consists of an algorithm, keys, and a defined method of use. Kerckhoffs’s principle states that a system should remain secure even when everything except the key is public. Security through secrecy of an algorithm is therefore not an acceptable substitute for sound design and key protection.

A useful abstraction for authenticated encryption is:

\[

(C,T)=Enc_K(N,P,A)

\]

where \(P\) is plaintext, \(K\) is the secret key, \(N\) is a nonce or initialization value, \(A\) is associated data that is authenticated but not encrypted, \(C\) is ciphertext, and \(T\) is an authentication tag. Correct decryption verifies \(T\) before releasing plaintext. The nonce normally need not be secret, but its uniqueness requirements depend on the algorithm. For AES-GCM, nonce reuse under the same key is a serious failure that can reveal relationships between plaintexts and undermine authentication.

Security claims must be interpreted under assumptions. For example, confidentiality depends on algorithm strength, key secrecy, correct nonce use, endpoint security, and resistance to side-channel and implementation attacks. Cryptography cannot compensate for compromised endpoints or an application that logs plaintext credentials.

2. Symmetric Cryptography

Symmetric cryptography uses the same secret, or computationally related secret, for encryption and decryption. Its primary advantages are speed and suitability for large data volumes. AES is the dominant standardized block cipher, with 128-bit blocks and key sizes of 128, 192, or 256 bits. ChaCha20 is a widely used stream cipher, often paired with Poly1305 for authentication.

A block cipher is not normally used directly on arbitrary-length data. A mode of operation specifies how blocks, nonces, padding, and authentication are handled. Older modes such as ECB expose repeated plaintext patterns and should not be used for general data encryption. CBC can provide confidentiality when correctly configured, but it requires unpredictable initialization vectors and separate integrity protection; padding-oracle vulnerabilities have historically resulted from incorrect error handling. CTR converts a block cipher into a stream-like construction but provides no integrity by itself.

Authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305, is generally preferred. AEAD protects confidentiality and integrity together and permits authentication of metadata such as protocol version, sequence number, or message type. Applications must reject altered ciphertext and must not expose unauthenticated plaintext.

Symmetric systems create a key-distribution problem. If every pair of users requires a distinct shared key, the number of pairwise keys for \(n\) users is:

\[

\frac{n(n-1)}{2}

\]

This assumes one unique key per unordered pair. For 1,000 users, that is 499,500 pairwise keys, illustrating why large systems use centralized key services, group-key mechanisms, or public-key techniques rather than manually distributing pairwise secrets.

3. Asymmetric Cryptography

Asymmetric cryptography uses a public key and a mathematically related private key. The public key can be distributed widely; the private key must remain protected. Public-key encryption supports confidential delivery of a small secret, while digital signatures support authentication and integrity.

RSA security depends on the difficulty of factoring appropriately selected large integers. Elliptic-curve cryptography (ECC) relies on the difficulty of the elliptic-curve discrete logarithm problem and can provide comparable security with smaller keys. Elliptic-curve Diffie–Hellman (ECDH) is primarily a key-agreement method, not a direct bulk-encryption method. In practice, a protocol uses public-key operations to establish a shared session key and then uses AEAD for data.

Hybrid encryption is therefore standard:

1. Generate a fresh random symmetric session key.

2. Use public-key key agreement or encryption to protect or derive that key.

3. Encrypt application data with AEAD.

4. Authenticate the parties and bind the exchange to the intended identities and context.

Public-key operations are slower and more complex than symmetric operations. They also require validation of parameters, protection of private keys, resistance to side-channel attacks, and secure identity binding. A key exchange without authentication is vulnerable to a man-in-the-middle attack.

4. Hash Functions, MACs, and Digital Signatures

A cryptographic hash function maps an arbitrary-length input to a fixed-length digest. Desired properties include preimage resistance, second-preimage resistance, and collision resistance. A collision occurs when two different inputs produce the same digest. Hashes do not provide secrecy: anyone who knows the input can calculate its digest.

SHA-256 and SHA-3 are examples of general-purpose cryptographic hash families. MD5 and SHA-1 should not be used for collision-sensitive security applications. Password storage requires a password-hashing or key-derivation function such as Argon2id, scrypt, or PBKDF2, together with a unique salt and an appropriate work factor. Encryption of passwords is generally the wrong design because applications need verification, not reversible recovery.

A message authentication code (MAC) is calculated using a shared secret:

\[

T=MAC_K(M)

\]

where \(M\) is the message, \(K\) is the secret key, and \(T\) is the tag. HMAC constructs a MAC from a hash function and is widely deployed. A MAC provides integrity and authentication to parties sharing the key, but it does not provide public verifiability: either party holding the key can generate a valid tag.

A digital signature uses a private key to sign a message or, more commonly, a digest of the message. Anyone with the corresponding public key can verify it. Signatures support public verification and stronger attribution properties than MACs, but they depend on trustworthy key binding, secure private-key control, correct canonicalization, and suitable legal and organizational procedures. A signature does not automatically encrypt the signed content.

The choice is contextual. Use AEAD for confidential and integrity-protected data, MACs for efficient authentication between mutually trusted services, and digital signatures where independent verification, certificates, software distribution, or long-term evidence is required.

5. Randomness and Nonces

Cryptographic security frequently depends more on randomness than on algorithm selection. A cryptographically secure pseudorandom number generator (CSPRNG) is seeded from an adequate entropy source and produces outputs computationally unpredictable to an attacker. Operating systems normally provide suitable interfaces, such as the system random device or platform cryptographic API. Applications should not construct keys using timestamps, process identifiers, ordinary pseudo-random functions, or user-selected strings without a proper derivation process.

A nonce is a value intended for one-time use in a particular cryptographic context. A nonce need not be unpredictable in every construction, but it must meet the algorithm’s uniqueness or unpredictability requirements. Random nonces require sufficient collision resistance; counter-based nonces require reliable state management and protection against rollback. Distributed systems must coordinate uniqueness across nodes. Reusing a nonce with a key in a construction such as GCM can be catastrophic.

Entropy failure may result from early boot operation, virtual-machine cloning, embedded devices, faulty hardware sources, or incorrect seeding. A robust design uses the operating system CSPRNG, avoids homemade random generators, monitors failures, and defines behavior when randomness is unavailable.

6. Public-Key Infrastructure and Certificates

Public-key infrastructure (PKI) is the organizational and technical framework for issuing, distributing, validating, renewing, revoking, and governing certificates and keys. A certificate binds an identity or authorization claim to a public key through a digitally signed statement.

A typical X.509 certificate contains a subject or subject alternative name, issuer, validity interval, public-key information, key-usage constraints, serial number, signature algorithm, and extensions. A certificate authority (CA) signs certificates. A root CA is trusted through a trust store; intermediate CAs issue end-entity certificates while limiting exposure of the root private key.

Certificate validation commonly includes:

1. Building a chain to a configured trust anchor.

2. Verifying signatures in the chain.

3. Checking validity dates and basic constraints.

4. Confirming the requested hostname or identity in the subject alternative name.

5. Enforcing key-usage and extended-key-usage constraints.

6. Checking revocation status where required and feasible.

7. Rejecting weak algorithms, malformed structures, and unacceptable policy constraints.

Trust anchors are local policy decisions, not universal facts. An enterprise may operate a private CA for internal services, whereas browsers and operating systems maintain public trust stores. Certificate revocation is difficult in disconnected or privacy-sensitive environments. Certificate Revocation Lists (CRLs) can be large and stale; Online Certificate Status Protocol (OCSP) introduces availability and privacy considerations. Short-lived certificates reduce the dependence on real-time revocation but require reliable automated renewal.

Common PKI failures include failing to verify hostnames, accepting expired certificates, disabling validation to resolve an operational problem, overbroad trust stores, and storing CA private keys without hardware-backed protection. Certificate transparency improves public visibility of issued certificates but does not replace endpoint validation or key protection.

7. TLS and Secure Protocol Design

Transport Layer Security (TLS) protects application traffic against eavesdropping, modification, and endpoint impersonation when correctly configured. A modern TLS connection typically performs the following functions:

• Negotiates a protocol version and cryptographic parameters.
• Establishes fresh keying material, commonly through ephemeral Diffie–Hellman methods.
• Authenticates the server using a certificate and proof of possession of the private key.
• Optionally authenticates the client with a certificate.
• Derives traffic keys using a key-derivation function.
• Protects records with authenticated encryption and sequence-number controls.

Ephemeral key exchange supports forward secrecy: compromise of a server’s long-term certificate key should not normally decrypt previously recorded sessions. TLS security still depends on certificate validation, endpoint authentication, secure session resumption, correct protocol configuration, and protection of session keys.

Protocol design should define message formats, state transitions, failure behavior, algorithm negotiation, replay resistance, and downgrade resistance. Cryptographic operations must be bound to the correct identity and transcript. An implementation that verifies a signature but fails to bind it to the negotiated session may remain vulnerable. Error messages should not reveal unnecessary information, but operational logging must still support incident investigation without recording secrets.

Developers should use mature TLS libraries and standard protocol profiles rather than implementing TLS or cryptographic primitives. Deprecated protocols, weak cipher suites, static keys, unauthenticated key exchange, and certificate-validation bypasses should be prohibited by policy and tested through automated configuration assessment.

8. Secrets and Key Management Lifecycle

Key management is a lifecycle rather than a storage task. A defensible lifecycle includes:

1. Requirement and classification: identify data, threat model, required assurance, retention, and compliance obligations.

2. Generation: create keys with an approved CSPRNG or managed cryptographic service.

3. Registration and metadata: record owner, purpose, algorithm, creation time, rotation policy, dependencies, and permitted uses.

4. Distribution: deliver keys through authenticated, encrypted, and access-controlled channels.

5. Use: enforce least privilege, separation of duties, algorithm constraints, and audit logging.

6. Rotation or rekeying: replace keys according to risk, cryptoperiod, usage volume, personnel change, or algorithm guidance.

7. Backup and recovery: protect recovery copies with independent controls and test restoration.

8. Suspension and revocation: rapidly disable compromised or unauthorized keys.

9. Archival: preserve keys only when necessary for legal or business decryption requirements.

10. Destruction: securely erase keys and verify that active copies, caches, backups, and replicas are addressed.

A cryptoperiod is the period during which a key is authorized for use. It is determined by algorithm strength, data sensitivity, exposure, usage volume, compromise probability, and operational capability. Rotation alone does not repair a compromise if old keys remain accessible or if attackers already possess plaintext or decrypted backups.

Secrets-management systems should provide access control, audit trails, automated delivery, versioning, expiry, and integration with workload identity. Examples include hardware security modules (HSMs), cloud key-management services, vault systems, and platform secret stores. Secrets should not be embedded in source code, container images, machine-learning prompts, tickets, or unencrypted configuration files. Dynamic, short-lived credentials are preferable to permanent shared passwords.

Envelope encryption separates a data-encryption key (DEK) from a key-encryption key (KEK). Data is encrypted with the DEK, while the KEK protects the DEK. This permits efficient data encryption and centralized control of key-wrapping operations. Access policies must distinguish the ability to use a key from the ability to export, rotate, delete, or administer it.

9. Applied Case: Protecting a Multi-Cloud Health Platform

This is an illustrative case. A healthcare provider operates a patient portal across two cloud providers and an on-premises analytics platform. The initial architecture stores database passwords in deployment scripts, uses one long-lived TLS private key across environments, and encrypts backups with a key shared by database administrators and application developers.

Problem. A leaked repository token exposes deployment files. Although no evidence shows that patient records were read, the organization cannot determine which secrets were accessed. The common TLS key also prevents reliable attribution between environments, and backup access is broader than necessary.

Analysis. The risk is not merely weak encryption. It includes excessive privilege, poor identity separation, missing inventory, inadequate auditability, and inability to rotate keys without outage. The organization classifies patient records as highly sensitive and identifies regulatory obligations concerning access control, breach response, retention, and audit evidence.

Approach. The provider establishes workload identities for each service, moves credentials into a managed secrets platform, and replaces static credentials with short-lived tokens. Each environment receives separate certificates and keys. Database records and backups use envelope encryption with DEKs protected by environment-specific KEKs in HSM-backed services. Administrative access requires multi-factor authentication and separation of duties. Key metadata records owners, purpose, expiry, and dependencies. Automated certificate renewal and secret rotation are tested in staging before production deployment. Centralized logs record key use, access denials, rotation events, and administrative actions without recording secret values.

The organization performs a staged response to the leaked token: revoke it, search logs, rotate dependent credentials, inspect repositories and build artifacts, and assess whether data access occurred. It also defines emergency recovery procedures, including controlled key escrow for legally required decryption, with dual authorization.

Outcome. The architecture reduces blast radius, improves attribution, and permits rotation without replacing every application simultaneously. It does not eliminate risk: compromised workloads can still misuse authorized keys, and availability depends on the secrets platform. Continuous monitoring, least privilege, incident exercises, and backup recovery tests remain necessary.

Learning points. Key management must be designed with identity, deployment, logging, recovery, and governance. Encryption at rest is insufficient when administrators share unrestricted keys or when compromise cannot be detected.

10. Governance, Ethics, and Professional Practice

Cryptographic controls affect privacy, lawful access, safety, and organizational accountability. Key escrow and exceptional access may support regulated recovery but create additional attack surfaces and concentration of authority. Backdoors and deliberately weakened encryption undermine users who cannot distinguish legitimate access from hostile exploitation. Decisions should be based on documented threat models, proportionality, independent review, and transparent accountability.

Organizations should maintain cryptographic inventories, approved algorithms, ownership records, exception processes, incident procedures, and supplier requirements. Compliance should not be confused with security: a certificate or audit report does not prove that private keys are protected or that applications validate identities correctly. Privacy principles require data minimization, purpose limitation, controlled retention, and careful handling of metadata such as certificate and access logs.

Artificial intelligence systems introduce additional secret-management concerns. Prompts, training data, model logs, plugins, and automated agents may expose credentials or personal data. AI-generated code must not be trusted to select algorithms, validate certificates, or handle keys without expert review and security testing. Conversely, anomaly detection can help identify unusual key use, provided monitoring respects privacy and does not become an uncontrolled source of sensitive data.

11. Post-Quantum Readiness

Large-scale quantum computers could undermine widely used public-key systems based on integer factoring and discrete logarithms through Shor’s algorithm. Grover’s algorithm can reduce the effective security of idealized symmetric search, although the practical impact depends on resources and implementation. Symmetric cryptography and hash functions are generally more resilient than RSA and conventional ECC, but security margins and key sizes require careful assessment.

The principal near-term concern is “harvest now, decrypt later”: adversaries may record encrypted traffic today for future decryption. Organizations should therefore inventory where RSA, Diffie–Hellman, and ECC are used; identify long-lived sensitive data; classify cryptographic dependencies; and track standards and vendor support.

Post-quantum cryptography (PQC) uses mathematical problems believed resistant to known quantum attacks. Migration challenges include larger public keys or signatures, performance changes, protocol incompatibilities, constrained devices, and the need to update certificates and hardware. Hybrid key establishment can provide transitional resilience by combining a conventional mechanism with a post-quantum mechanism, provided the composition is standardized and correctly implemented. Organizations should avoid unreviewed proprietary hybrids.

A practical readiness program includes cryptographic discovery, data-retention analysis, vendor engagement, crypto-agility requirements, test environments, and staged migration. Crypto-agility means that algorithms, parameters, certificates, and key-management components can be changed without redesigning the entire application. It is an architectural capability, not permission to change algorithms casually in production.

Best-Practice Checklist

• Prefer standardized, peer-reviewed algorithms and modern AEAD modes.
• Use mature libraries and secure platform randomness.
• Never reuse nonces where the algorithm forbids reuse.
• Separate encryption, authentication, signing, and key-encryption purposes.
• Validate certificate chains, names, dates, usages, and trust anchors.
• Use ephemeral key exchange where forward secrecy is required.
• Keep private keys and secrets out of code, images, logs, and tickets.
• Apply least privilege and separate key administration from data administration.
• Automate rotation, expiry, revocation, inventory, and renewal.
• Test backup recovery, compromise response, and key destruction.
• Record cryptographic dependencies and plan for PQC migration.
• Treat cryptography as part of system architecture and governance, not as a final configuration step.

Chapter Summary

Applied cryptography combines mathematical primitives with protocols, identity systems, implementation controls, and lifecycle governance. Symmetric encryption efficiently protects data, while asymmetric cryptography enables scalable key establishment and public verification. AEAD should generally replace encryption-only designs. Hashes provide fixed-length integrity-related representations but do not provide secrecy; MACs authenticate messages to parties sharing a secret; digital signatures enable public verification but require trustworthy identity binding and private-key protection.

Secure randomness, nonce discipline, certificate validation, and forward-secret protocol design are essential operational requirements. PKI establishes controlled relationships between identities and public keys, while TLS uses certificates, authenticated key exchange, key derivation, and protected records to secure network communication. Effective key management covers generation, distribution, use, rotation, backup, revocation, archival, and destruction. Secrets-management platforms, envelope encryption, workload identity, auditing, and separation of duties reduce blast radius.

Cryptographic governance must address privacy, lawful access, recovery, compliance, and ethical risks. Finally, organizations should inventory cryptographic dependencies, protect long-lived data, and develop crypto-agility and post-quantum migration plans before quantum threats become an operational emergency.

Key Terms

Cryptography: The study and practice of protecting information using mathematical techniques.

Symmetric encryption: Encryption using a shared secret key.

Asymmetric cryptography: Cryptography using related public and private keys.

AEAD: Authenticated encryption with associated data.

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

Hash function: A function mapping arbitrary input to a fixed-length digest.

MAC: A keyed mechanism providing message integrity and shared-key authentication.

Digital signature: A private-key-generated value that can be publicly verified.

CSPRNG: A cryptographically secure pseudorandom number generator.

PKI: The framework for managing certificates, keys, trust, and identity binding.

Certificate authority: An entity that signs and issues digital certificates.

Trust anchor: A locally trusted certificate or public key from which validation begins.

Forward secrecy: Protection of past sessions from later compromise of long-term keys.

Cryptoperiod: The authorized period of use for a cryptographic key.

HSM: Hardware security module that protects and performs operations with cryptographic keys.

Envelope encryption: Encrypting data with a DEK and protecting that DEK with a KEK.

Secrets management: Controlled storage, delivery, rotation, and auditing of sensitive credentials.

Crypto-agility: The ability to change cryptographic mechanisms with limited system disruption.

Post-quantum cryptography: Cryptography designed to resist attacks from capable quantum computers.

Review Questions

Short Answer Questions

1. Why is AEAD generally preferred over encryption without authentication?

2. Distinguish a MAC from a digital signature.

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

4. Why can nonce reuse be dangerous in authenticated encryption?

5. What is forward secrecy?

Long Answer Questions

1. Compare symmetric and asymmetric cryptography in terms of performance, key distribution, scalability, and common applications.

2. Explain the lifecycle of a cryptographic key from generation through destruction.

3. Describe TLS authentication and key establishment, including the role of certificates and ephemeral key exchange.

4. Analyze the main causes of PKI failure and propose controls to reduce them.

5. Explain why post-quantum readiness requires cryptographic inventory and crypto-agility rather than simply purchasing a new algorithm.

Analytical / Application Questions

1. A company uses one AES-GCM key and one fixed nonce for every message. Analyze the risks and design a safer scheme.

2. An organization discovers a private TLS key in a public repository. Develop an incident-response and replacement plan, including investigation, revocation, rotation, and monitoring.

3. Design a key-management architecture for a multi-cloud application handling sensitive customer records. Justify your choices concerning workload identity, envelope encryption, HSMs, rotation, recovery, and auditability.

Multiple Choice Questions with Answers

Question 1

Which mechanism provides confidentiality and integrity together for network data?

A. Plain SHA-256 hashing

B. Authenticated encryption with associated data

C. A certificate authority

D. A digital signature without encryption

Correct Answer: B. Authenticated encryption with associated data

Question 2

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

A. The certificate chain becomes longer

B. The key automatically rotates

C. Confidentiality and authentication can be seriously compromised

D. Only transmission speed is reduced

Correct Answer: C. Confidentiality and authentication can be seriously compromised

Question 3

Which statement correctly distinguishes a MAC from a digital signature?

A. A MAC uses a shared secret, while a signature uses a private key and can be publicly verified

B. A MAC always provides confidentiality, while a signature never provides integrity

C. A MAC requires a certificate authority, while a signature cannot use certificates

D. A MAC is asymmetric, while a signature is symmetric

Correct Answer: A. A MAC uses a shared secret, while a signature uses a private key and can be publicly verified

Question 4

For 1,000 users with one unique pairwise symmetric key per unordered pair, how many keys are required?

A. 1,000

B. 2,000

C. 499,500

D. 1,000,000

Correct Answer: C. 499,500

Question 5

Which component normally establishes trust in an X.509 certificate chain?

A. A trust anchor configured in the validating system

B. The ciphertext plaintext ratio

C. The database password

D. The TLS session counter alone

Correct Answer: A. A trust anchor configured in the validating system

Question 6

What is the main purpose of ephemeral Diffie–Hellman in TLS?

A. To compress certificates

B. To provide forward secrecy when correctly implemented

C. To replace hostname validation

D. To store passwords reversibly

Correct Answer: B. To provide forward secrecy when correctly implemented

Question 7

Which is the most appropriate method for storing user passwords?

A. Reversible AES encryption with a shared application password

B. Plaintext storage with restricted database permissions

C. A password-hashing or key-derivation function with unique salts

D. A digital signature verified with the user’s public key

Correct Answer: C. A password-hashing or key-derivation function with unique salts

Question 8

What does envelope encryption normally do?

A. Encrypts data with a DEK and protects the DEK with a KEK

B. Uses a certificate as the plaintext data

C. Replaces all access control with hashing

D. Stores the encryption key in the same source file as the data

Correct Answer: A. Encrypts data with a DEK and protects the DEK with a KEK

Question 9

Which event should normally trigger immediate key suspension or revocation?

A. A successful authorized key use

B. A suspected compromise of the private key

C. Routine certificate validation

D. A completed backup test

Correct Answer: B. A suspected compromise of the private key

Question 10

Why are RSA and conventional elliptic-curve systems central concerns in post-quantum planning?

A. They cannot encrypt files larger than one block

B. Known quantum algorithms threaten their underlying hard problems

C. They do not use public keys

D. They are only used for password hashing

Correct Answer: B. Known quantum algorithms threaten their underlying hard problems