Applied Cryptography and Key Management

Introduction

Cryptography is the practical discipline of protecting information through mathematical techniques and carefully managed keys. In cybersecurity, cryptography is not limited to encrypting files. It supports authentication, integrity, confidentiality, non-repudiation, secure protocol negotiation, identity management and controlled access to data.

Modern systems use cryptography in transport security such as TLS, private networking through VPNs, secure email, full-disk encryption, password protection, software updates and machine-to-machine communication. In each case, the algorithm is only one part of the control. The security outcome also depends on how keys are generated, distributed, stored, used, rotated, recovered, revoked and destroyed.

A strong algorithm with poorly protected keys provides little security. Conversely, well-managed keys can allow an organisation to use standard, publicly reviewed cryptographic algorithms in a controlled and auditable way. This chapter therefore treats cryptography and key management as a combined security engineering problem.

Learning Objectives

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

1. Explain how cryptography supports TLS, VPNs, secure email, disk encryption and secure communications.
2. Distinguish confidentiality, integrity, authentication and non-repudiation controls.
3. Describe symmetric encryption, public-key cryptography, hashing, digital signatures and authenticated encryption.
4. Explain the lifecycle of cryptographic keys.
5. Select cryptographic controls according to data sensitivity, performance, operational and compliance requirements.
6. Identify common implementation failures and recommend practical improvements.

1. Cryptography as a Security Control

A cryptographic system normally consists of an algorithm, keys, protected data, associated parameters and an operational process. The security of the system depends on all of these elements. Kerckhoffs’s principle states that a cryptosystem should remain secure even when its design is public; secrecy should reside in the key, not in an undisclosed algorithm.

The principal security services are:

• Confidentiality: preventing unauthorised disclosure.
• Integrity: detecting unauthorised alteration.
• Authentication: establishing the identity of a communicating party or the origin of data.
• Non-repudiation: providing evidence that can support attribution, subject to legal and operational conditions.

Encryption transforms plaintext into ciphertext using a key. Decryption reverses the transformation for an authorised holder of the appropriate key. A modern system should normally provide integrity as well as confidentiality. Encryption without integrity can allow an attacker to modify messages without being detected.

Symmetric cryptography

Symmetric cryptography uses the same secret key, or closely related secret keys, for encryption and decryption. Advanced Encryption Standard (AES) is a widely deployed symmetric block cipher. Common authenticated-encryption modes include AES-GCM and ChaCha20-Poly1305. Authenticated encryption produces ciphertext and an authentication tag. The tag enables the recipient to detect tampering and usually causes decryption to fail if the ciphertext, associated data or nonce is invalid.

A nonce, sometimes called an initialization value, is not generally required to be secret, but its reuse conditions depend on the algorithm. For AES-GCM, nonce reuse with the same key is dangerous and can undermine confidentiality and integrity. Implementations must therefore use a reliable nonce-generation and uniqueness strategy.

Symmetric cryptography is computationally efficient and is suitable for bulk data. Its principal challenge is key distribution: communicating parties must obtain the secret key without exposing it.

Public-key cryptography

Public-key cryptography uses a public key and a private key. The public key may be distributed openly, whereas the private key must remain protected. Public-key systems support key establishment, authentication and digital signatures, but are normally slower than symmetric encryption for large amounts of data.

In a digital-signature system, a signer uses a private key to create a signature and a verifier uses the corresponding public key to verify it. Signatures normally operate on a cryptographic digest rather than directly on a large message. RSA, elliptic-curve algorithms and post-quantum schemes are examples of public-key families, although exact algorithm and parameter choices must follow current organisational standards.

Hash functions

A cryptographic hash function maps input data of arbitrary length to a fixed-length digest. A secure hash should make it computationally infeasible to find an input producing a chosen digest, to find two different inputs with the same digest, or to recover the input from the digest. Hashes are used in integrity checks, digital signatures, password-verification schemes and key derivation.

A hash is not encryption. It is not reversible and does not by itself authenticate the source of data. For password storage, a fast general-purpose hash is unsuitable because attackers can test large numbers of guesses. Passwords should be processed with a password-hashing or key-derivation function such as Argon2id, scrypt or PBKDF2, with a unique salt and an appropriately selected work factor.

2. Key Management as a Lifecycle

Key management includes the policies, people, processes, hardware and software used to control cryptographic keys. A useful lifecycle model is:

1. Planning and classification
2. Generation
3. Distribution and registration
4. Storage and use
5. Rotation and renewal
6. Backup and recovery
7. Revocation and suspension
8. Archival and destruction

The lifecycle should be documented for each key type. A short-lived TLS session key has different requirements from a long-term certificate authority key or an archival decryption key.

Key generation

Keys must be generated using approved algorithms and a cryptographically secure random number generator. Predictable random values can make apparently strong algorithms vulnerable. Generation should occur in a controlled environment, preferably within a hardware security module (HSM), trusted platform module (TPM) or another protected cryptographic boundary where appropriate.

Key length is not the only measure of strength. Security depends on the algorithm, implementation, randomness, attack model, expected lifetime and exposure. Organisations should use current standards rather than independently inventing key sizes or algorithms.

Distribution and establishment

Keys can be distributed through certificates, key-agreement protocols, enterprise key-management services, hardware devices or carefully controlled manual procedures. Public keys are commonly distributed through certificates that bind a key to an identity. A certificate authority (CA) signs certificates, and relying parties validate the certification path and relevant policy constraints.

A key-agreement protocol allows two parties to establish a shared secret over an observable network. In a properly designed ephemeral Diffie–Hellman exchange, each session uses temporary private values. This can provide forward secrecy: compromise of a long-term authentication key does not automatically reveal previously recorded session traffic.

Storage and use

Private and symmetric keys should be protected according to their sensitivity. Options include HSMs, TPMs, encrypted key stores, operating-system keystores and cloud key-management services. A key should not be embedded in source code, committed to a repository, placed in a public configuration file or transmitted through ordinary email.

Access should follow least privilege and separation of duties. Applications should receive only the operations they require, such as “decrypt this object” rather than unrestricted export of the key. Key-use events should be logged, monitored and associated with a service identity. Logs must not expose plaintext keys or sensitive plaintext data.

Rotation and renewal

Rotation replaces a key during its operational life. Reasons include time limits, suspected exposure, personnel changes, cryptoperiod expiry, algorithm migration and reduction of accumulated ciphertext exposure. Rotation requires more than generating a new key: dependent systems, certificates, access policies, backups and recovery procedures must also be updated.

A common design uses key versioning. New data is encrypted under the current version, while older versions remain available for authorised decryption until re-encryption or retention expiry. This supports continuity but increases the need for accurate inventory and lifecycle records.

Recovery and backup

Key recovery is necessary when encrypted data must remain available after device failure, employee departure or loss of an encryption token. Recovery mechanisms must not become an easy path for unauthorised access. Strong controls include split knowledge, dual authorisation, offline backups, geographic separation, tamper evidence and tested restoration procedures.

Backups of encryption keys require particular care. If data is backed up but its key is lost, the data may be permanently inaccessible. If both data and key backups are stolen together, confidentiality may be lost. Recovery planning must therefore address availability and confidentiality simultaneously.

Revocation and destruction

Revocation marks a key or certificate as no longer trusted before its planned expiry. Causes include compromise, loss, misuse, a change of identity or termination of a service. Certificate revocation may use certificate revocation lists or online status protocols, depending on the environment. Applications must actually check status information; merely issuing revocations is insufficient.

Destruction should eliminate all usable copies, including copies in HSM backups, snapshots, caches, removable media and disaster-recovery systems, subject to legal retention requirements. Cryptographic erasure can be achieved by securely destroying the encryption key that protects data, but this is reliable only when all copies of the key are identified and destroyed.

3. Cryptography in Major Security Technologies

TLS and secure web communication

Transport Layer Security protects many web, API, email and service-to-service connections. A simplified TLS process is:

1. The client and server negotiate supported protocol parameters.
2. The server presents an identity certificate.
3. The client validates the certificate chain, name, validity period and policy constraints.
4. The parties perform authenticated key establishment.
5. They derive symmetric traffic keys.
6. Application data is protected using authenticated encryption.

TLS therefore combines public-key cryptography for authentication and key establishment with symmetric cryptography for efficient data protection. The certificate does not encrypt all application traffic; it helps establish trust in the endpoint identity. The resulting session keys protect the data.

Good practice includes disabling obsolete protocol versions and weak cipher suites, validating certificates correctly, protecting private keys, enabling forward secrecy where supported, monitoring certificate expiry and testing both external and internal services.

TLS protects data in transit between endpoints. It does not protect data after it reaches a compromised server, nor does it necessarily protect traffic from a malicious endpoint that has valid credentials.

VPNs and network tunnels

A virtual private network creates an authenticated and encrypted connection across an untrusted network. IPsec commonly uses Internet Key Exchange to authenticate peers and establish security associations. Modern VPNs use authenticated encryption, replay protection and controlled rekeying.

VPN design requires attention to endpoint identity, routing, split tunnelling, access scope, device posture, logging and availability. A VPN should not automatically grant broad access to every internal system. Network segmentation and least privilege remain necessary because an authenticated VPN user or device may still be compromised.

Site-to-site VPNs typically connect networks, while remote-access VPNs connect individual users or devices. Strong authentication, device certificates or phishing-resistant authentication can reduce the risk of stolen passwords.

Secure email

Secure email technologies can protect message content, attachments, integrity and sender identity. OpenPGP and S/MIME use public-key cryptography, certificates or trusted key records, and symmetric encryption for message content. A typical hybrid design generates a random content-encryption key, encrypts the message with that key, and encrypts or wraps the content key for each recipient.

Email security has practical limitations. Metadata such as sender, recipient, subject or timing may remain visible. Key discovery and verification can be difficult, users may lose private keys, and forwarding or mailing-list processing can disrupt signatures. Organisations should define whether the requirement is confidentiality, sender authentication, message integrity or all three.

Disk and storage encryption

Full-disk encryption protects data when a device is lost, stolen or decommissioned. It normally uses a volume-encryption key protected by a key-encryption key, which may be linked to a TPM, passphrase, recovery key or enterprise management service. File-level or database-level encryption can provide more selective protection and may remain useful when the operating system is running.

Disk encryption does not protect data from an attacker who has authenticated to an unlocked system. It also does not automatically protect backups, cloud snapshots, memory, application logs or data sent to another system. A complete control therefore combines encryption with endpoint security, access control, secure boot, backup protection and incident response.

Secure messaging and application protocols

Secure messaging systems often use end-to-end encryption, meaning that message content is encrypted so that only intended endpoints can decrypt it. Good designs use authenticated identities, forward secrecy and mechanisms for detecting key changes. Group messaging introduces additional complexity because membership changes require careful key updates.

Application developers should use established libraries and protocols rather than implement cryptographic primitives. They must also protect keys in memory, avoid logging secrets, authenticate associated data, handle failures safely and ensure that encryption is applied to the correct objects.

4. Selecting Controls for Organisational Requirements

Cryptographic choices should follow a documented risk assessment. Relevant factors include:

• Sensitivity and classification of the data.
• Legal, regulatory and contractual obligations.
• Required confidentiality and retention period.
• Performance, latency, battery and bandwidth constraints.
• Availability and recovery requirements.
• Interoperability and vendor support.
• Threats from outsiders, insiders and compromised endpoints.
• Migration and future algorithm requirements.

A practical decision is to use authenticated encryption for ordinary data confidentiality and integrity, digital signatures where independent verification or origin evidence is required, hashing for integrity or indexing, and password-hashing functions for password verification. Public-key operations should generally establish identities or keys rather than encrypting large files directly.

5. Worked Application: Protecting a Healthcare Web Service

Consider an illustrative case involving a healthcare provider that operates a patient portal. The portal processes appointment information, clinical documents and payment data. The organisation has three requirements: protect data while travelling over public networks, limit the impact of a stolen laptop, and retain selected records for seven years.

The analysis begins by classifying the data. Clinical and payment information require strong confidentiality and integrity controls. The service also needs reliable availability because patients must access appointments and clinicians require timely information.

The proposed design uses TLS for browser and API connections. The service obtains certificates from a trusted CA, stores private keys in a managed key service, monitors expiry and restricts administrative access. Session traffic uses authenticated encryption and ephemeral key establishment where supported. Internal services also authenticate each other rather than trusting the network location alone.

Laptops use full-disk encryption with keys protected by a TPM and enterprise recovery procedures. The device-management platform records encryption status and prevents access by devices that fail required security checks. Backups are encrypted separately, and backup keys are subject to controlled recovery and audit.

Clinical documents are encrypted using envelope encryption. A randomly generated data-encryption key protects each document. A key-encryption key in the enterprise key-management service protects the data key. This allows controlled rotation of the key-encryption key without requiring every document to be immediately re-encrypted. Access requests are authorised using user role, treatment relationship and audit policy.

Signing keys for software releases are held in an HSM with multi-person approval. If a signing key is suspected of compromise, the organisation revokes the associated certificate, stops accepting affected releases, issues a replacement and investigates all signed artefacts.

The design is tested through certificate-expiry exercises, laptop-recovery tests, restoration of encrypted backups and simulated key compromise. The main lesson is that encryption alone is not the architecture. Identity, access control, monitoring, recovery, retention and incident response determine whether cryptography delivers practical security.

6. Common Failures and Limitations

Several recurring failures weaken otherwise sound systems:

• Reusing a nonce where the algorithm requires uniqueness.
• Using obsolete algorithms or unsupported protocol versions.
• Storing keys with the data they protect.
• Hard-coding secrets in application code.
• Failing to validate certificates or host names.
• Encrypting data but leaving plaintext in logs or temporary files.
• Losing keys because recovery was never tested.
• Rotating keys without preserving access to legitimately retained data.
• Treating a VPN as a replacement for authorisation and segmentation.
• Assuming encryption prevents compromise of an unlocked endpoint.
• Using custom cryptographic algorithms or unaudited implementations.

Cryptography also has limits. It cannot correct inaccurate identity records, malicious authorised users, insecure endpoints, poor access governance or unlawful processing. It can create operational risks when keys are lost, services cannot decrypt essential records, or legacy systems cannot interoperate with modern algorithms.

7. Governance, Ethics and Compliance

A cryptographic programme should define ownership, approved algorithms, key classifications, cryptoperiods, access roles, incident procedures, evidence requirements and exceptions. Policies should identify who may create, approve, use, recover, rotate and destroy each category of key.

Compliance requirements vary by jurisdiction and sector. Organisations may need to address privacy law, payment-card requirements, health-data obligations, records-retention rules and recognised standards such as NIST guidance, ISO/IEC 27001 controls or applicable national cryptographic requirements. Compliance does not guarantee security, but documented controls and evidence support accountability.

Key escrow and lawful-access arrangements create a difficult balance. Escrow may support business recovery, but additional copies increase the attack surface and may weaken confidentiality. Decisions should be transparent, proportionate, legally reviewed and subject to strong access controls.

Cryptographic failures can affect individuals directly. Exposure of health, financial or identity information may cause discrimination, fraud or loss of autonomy. Security professionals should therefore consider data minimisation, user expectations, accessibility, informed consent and the consequences of both surveillance and accidental disclosure.

8. Contemporary Developments

Cloud key-management services and HSM-backed platforms have made centralised key control more accessible, but responsibility is shared between provider and customer. Organisations must understand who controls keys, how administrative actions are logged, where keys are processed, and how migration or exit will occur.

Post-quantum cryptography is an emerging concern because sufficiently capable quantum computers could threaten some currently deployed public-key algorithms. A prudent organisation should inventory public-key use, identify long-lived confidential data, monitor standards development and plan migration. Cryptographic agility—the ability to replace algorithms and parameters without redesigning every application—is now an important architectural property.

Automation can improve certificate renewal, key rotation and compliance evidence. However, automation must include safeguards, approval boundaries, rollback procedures and monitoring. An automated system that distributes a faulty key or revokes a production certificate can cause a widespread outage.

Best-Practice Checklist

1. Use established, publicly reviewed algorithms and maintained libraries.
2. Prefer authenticated encryption for confidential data that may be modified in transit or storage.
3. Generate keys with approved cryptographically secure randomness.
4. Protect private and symmetric keys in appropriate hardware or managed stores.
5. Separate key-encryption keys from the data they protect.
6. Maintain a complete inventory of keys, certificates, owners, uses and expiry dates.
7. Define rotation, recovery, revocation and destruction procedures before deployment.
8. Test restoration and compromise response regularly.
9. Apply least privilege, separation of duties and tamper-evident logging.
10. Design for cryptographic agility and plan for post-quantum migration.

Chapter Summary

Cryptography provides confidentiality, integrity, authentication and support for non-repudiation, but these outcomes depend on sound key management. Symmetric encryption is efficient for bulk data, while public-key cryptography supports identity, signatures and key establishment. Hash functions support integrity and key derivation but are not encryption.

TLS combines certificates, authenticated key establishment and symmetric session protection. VPNs create authenticated encrypted tunnels but do not replace segmentation or authorisation. Secure email uses hybrid encryption and signatures, while disk encryption protects data primarily when devices are lost or powered off. Secure communication systems must also address endpoint security, metadata, recovery and identity verification.

Key management covers generation, distribution, storage, use, rotation, backup, recovery, revocation, archival and destruction. Control selection should reflect data sensitivity, threat exposure, performance, compliance, retention and availability. Effective cryptography is therefore an organisational capability involving technology, governance, people and tested operational processes.

Key Terms

Cryptography: The practice of protecting information using mathematical techniques.

Plaintext: Data in its intelligible, original form.

Ciphertext: Data transformed by encryption.

Symmetric encryption: Encryption using a shared secret key.

Public-key cryptography: Cryptography using related public and private keys.

Authenticated encryption: Encryption that also provides tamper detection.

Nonce: A value used once or under strict uniqueness conditions in a cryptographic operation.

Hash function: A function that maps input data to a fixed-length digest.

Digital signature: A private-key-generated value verified with a public key.

Certificate: A signed statement binding a public key to an identity or subject.

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

Forward secrecy: Protection preventing later compromise of long-term keys from revealing earlier sessions.

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

Data-encryption key: A key used to encrypt application or stored data.

HSM: Hardware security module designed to protect and perform operations with cryptographic keys.

Key rotation: Replacement of a key during or at the end of its operational period.

Revocation: Withdrawal of trust in a key or certificate before normal expiry.

Cryptographic erasure: Making data inaccessible by securely destroying all keys needed to decrypt it.

Cryptographic agility: The ability to replace algorithms or parameters with limited system disruption.

Review Questions

5 Short Answer Questions

1. What are the four principal security services supported by cryptography?
2. Why is authenticated encryption generally preferable to encryption without integrity protection?
3. What is the difference between a data-encryption key and a key-encryption key?
4. Why must private keys be protected differently from public keys?
5. State two limitations of full-disk encryption.

5 Long Answer Questions

1. Explain the TLS process and distinguish the roles of certificates, public-key cryptography and symmetric session keys.
2. Describe the complete cryptographic key lifecycle from generation through destruction.
3. Compare the uses and limitations of symmetric cryptography, public-key cryptography, hashing and digital signatures.
4. Explain how a VPN provides protection and why it does not replace access control or network segmentation.
5. Discuss the governance and recovery requirements for an organisation that encrypts long-retention records.

3 Analytical / Application Questions

1. A company stores customer records in a cloud platform and has experienced leaked application secrets. Design a key-management improvement covering generation, storage, access, rotation and monitoring.
2. A laptop containing encrypted health records is stolen while powered off. Analyse which controls protect the records and identify circumstances in which the records could still be exposed.
3. An organisation must select controls for public web traffic, database storage, software releases and employee passwords. Recommend an appropriate cryptographic control for each use and justify the choices using confidentiality, integrity, authentication, performance and recovery requirements.

Multiple Choice Questions with Answers

Question 1

Which cryptographic control is most appropriate for protecting bulk application data while also detecting tampering?

A. Authenticated symmetric encryption

B. A digital signature alone

C. A certificate revocation list

D. A password salt alone

Correct Answer: A. Authenticated symmetric encryption

Question 2

What is the primary purpose of a certificate in a typical TLS connection?

A. To compress application data

B. To bind a public key to an identified subject

C. To replace all symmetric encryption

D. To store a user's password

Correct Answer: B. To bind a public key to an identified subject

Question 3

Which key is normally used to protect a data-encryption key in envelope encryption?

A. A nonce

B. A hash digest

C. A key-encryption key

D. A certificate serial number

Correct Answer: C. A key-encryption key

Question 4

Why is nonce reuse particularly dangerous with AES-GCM under the same key?

A. It makes certificates expire immediately

B. It can undermine confidentiality and integrity

C. It prevents public keys from being distributed

D. It converts ciphertext into plaintext automatically

Correct Answer: B. It can undermine confidentiality and integrity

Question 5

Which statement best describes forward secrecy?

A. A session remains available after a server failure

B. A public key can never be revoked

C. Later compromise of a long-term key does not automatically reveal earlier sessions

D. All encrypted data can be decrypted without a key

Correct Answer: C. Later compromise of a long-term key does not automatically reveal earlier sessions

Question 6

What is the main purpose of a password-hashing function such as Argon2id?

A. To make password guessing more expensive

B. To provide certificate status information

C. To encrypt an entire hard disk directly

D. To generate a public web certificate

Correct Answer: A. To make password guessing more expensive

Question 7

Which action is most appropriate when a private signing key is suspected to be compromised?

A. Ignore the event until the scheduled rotation date

B. Publish the private key for transparency

C. Revoke or disable the affected trust, investigate, and issue a replacement

D. Rename the key file without changing the key

Correct Answer: C. Revoke or disable the affected trust, investigate, and issue a replacement

Question 8

What is a principal limitation of full-disk encryption?

A. It cannot protect a device that is lost

B. It normally does not protect data after an authorised user unlocks the system

C. It cannot use symmetric cryptography

D. It prevents all backup operations

Correct Answer: B. It normally does not protect data after an authorised user unlocks the system

Question 9

Which practice best supports key recovery without giving one person unrestricted control?

A. Keeping one unencrypted copy on a shared drive

B. Using split knowledge and dual authorisation

C. Embedding the recovery key in source code

D. Sending the recovery key through ordinary email

Correct Answer: B. Using split knowledge and dual authorisation

Question 10

What does cryptographic agility enable an organisation to do?

A. Replace algorithms or parameters with limited system redesign

B. Recover plaintext without authorisation

C. Avoid maintaining a key inventory

D. Make every cryptographic key public

Correct Answer: A. Replace algorithms or parameters with limited system redesign