Cryptography and Data Protection

Introduction and Context

Cryptography is the disciplined use of mathematical techniques to protect information and communications. In cyber security, it supports confidentiality, integrity, authentication, non-repudiation and accountability. These objectives are often summarized through the CIA triad—confidentiality, integrity and availability—although cryptography primarily contributes to the first two and supports authentication and trust.

Modern organisations rarely protect data with one mechanism. A typical system may encrypt a database, protect a network connection with TLS, authenticate users with certificates or tokens, hash passwords, and use digital signatures to verify software updates. Effective protection therefore depends not only on selecting an algorithm but also on managing keys, identities, policies, devices and lifecycle processes.

Cryptography does not eliminate risk. Poor key storage, weak passwords, incorrect configuration, compromised endpoints and fraudulent certificates can defeat strong algorithms. This chapter develops the concepts needed to select suitable techniques for data at rest, data in transit and data in use.

Learning Objectives

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

• distinguish encryption, hashing, encoding and tokenisation;
• explain symmetric and asymmetric cryptography and identify suitable uses for each;
• describe authenticated encryption, digital signatures and certificates;
• explain the role of public-key infrastructure (PKI);
• apply sound principles for key generation, storage, rotation, backup and revocation;
• select controls for protecting data at rest, in transit and in use;
• evaluate practical, ethical and governance limitations of cryptographic controls.

1. Security Services and Cryptographic Terminology

Plaintext is readable input. Ciphertext is the transformed output produced by encryption. Encryption transforms plaintext into ciphertext using an algorithm and a key; decryption reverses the transformation for an authorised recipient. A cryptographic algorithm may be public. Security should normally depend on keeping the key secret, not on hiding the algorithm.

Encoding changes data into another representation for compatibility, such as Base64. It provides no confidentiality because anyone can decode it. Hashing maps input to a fixed-length digest. A secure cryptographic hash is designed to make it computationally infeasible to recover the input, find a different input with the same digest, or deliberately find any collision. Hashing is not reversible encryption.

Salting adds a unique random value to a password before password hashing. A salt is not required to be secret; its purpose is to prevent identical passwords from producing identical stored values and to defeat precomputed tables. Passwords should use dedicated password-hashing or password-based key-derivation functions such as Argon2id, scrypt, bcrypt or PBKDF2, configured with an appropriate cost.

A nonce is a number used once in a particular cryptographic context. An initialization vector (IV) is an input that helps randomise some modes of operation. Their requirements vary by algorithm: some must be unpredictable, while others must merely never repeat with the same key. Reusing a nonce where an algorithm prohibits reuse can expose plaintext or authentication keys.

Entropy describes unpredictability. Cryptographic keys, salts and nonces should be generated by a cryptographically secure random-number generator (CSPRNG), not by timestamps, ordinary pseudo-random functions or user-chosen patterns.

2. Symmetric Encryption

Symmetric cryptography uses the same secret key, or closely related secret keys, for encryption and decryption. Its main strengths are speed and suitability for large volumes of data. AES and ChaCha20 are widely used modern primitives. AES commonly uses 128-, 192- or 256-bit keys; the appropriate choice depends on policy, performance and compatibility.

A block cipher processes fixed-size blocks. It must be used with a secure mode of operation. Electronic Codebook (ECB) mode should generally not be used for structured data because equal plaintext blocks produce equal ciphertext blocks, revealing patterns. CBC can provide confidentiality when correctly configured with a unique, unpredictable IV, but confidentiality alone does not detect tampering. Modern applications should normally prefer authenticated encryption.

Authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305, provides confidentiality and integrity. It encrypts plaintext while producing an authentication tag. Associated data—for example, a message header—can remain visible but is authenticated so that unauthorised modification is detected. The encryption key and nonce must be used according to the algorithm’s rules; in particular, nonce reuse in GCM is dangerous.

Conceptually, an AEAD operation can be represented as:

Here, K is the secret key, N is the nonce, P is plaintext, A is associated data, C is ciphertext and T is the authentication tag. Decryption succeeds only when the tag verifies. This notation describes the interface rather than a universal internal formula; exact processing depends on the algorithm.

Symmetric encryption creates a key-distribution problem. If many parties need private pairwise communication, each relationship may require a distinct secret. Public-key techniques are therefore often used to authenticate parties and establish a temporary symmetric session key, after which symmetric encryption protects the data efficiently.

3. Public-Key Cryptography

Asymmetric cryptography uses a mathematically related key pair: a public key that may be distributed and a private key that must be protected. A message encrypted with a recipient’s public key can normally be decrypted only with the corresponding private key. A signature created with a private key can be checked using the public key.

Public-key systems solve aspects of key distribution but are slower and require stronger identity controls than symmetric encryption. RSA, elliptic-curve cryptography (ECC) and modern elliptic-curve or finite-field schemes are examples of public-key technologies. Implementations should use current, reviewed libraries and approved parameter sets rather than inventing algorithms or selecting obsolete parameters.

Key agreement, such as ephemeral Diffie–Hellman, allows two parties to derive a shared secret without sending that secret directly. Key agreement alone does not authenticate the parties; an attacker could perform separate exchanges with each side. Certificates, signatures or another trusted authentication mechanism are required to prevent a man-in-the-middle attack.

A common hybrid design is therefore:

Figure: A hybrid design uses public-key methods for trust or key establishment and symmetric authenticated encryption for bulk data.

4. Hashing, Integrity and Password Protection

A hash digest can act as a compact fingerprint of data. When a trusted digest is available, a recipient can hash a downloaded file and compare the result. This detects accidental or unauthorised modification only if the reference digest itself is trustworthy. An attacker who can replace both the file and its digest is not stopped; a digital signature or authenticated distribution channel is needed.

Hash functions are also components of digital signatures, message authentication codes and key-derivation functions. A keyed-hash message authentication code (HMAC) combines a secret key with a hash function to provide integrity and authentication to parties sharing that key. HMAC does not provide non-repudiation because both parties possess the same secret.

Password storage requires special treatment. A system should store a password-derived verifier, not plaintext or a fast general-purpose hash such as unsalted SHA-256. Each record should have a unique salt, and the work factor should be selected through testing so that legitimate authentication is acceptable while large-scale guessing is expensive. Strong password hashing does not protect a device already compromised during login.

5. Digital Signatures and Certificates

A digital signature binds a message or software object to a signing private key. A typical process hashes the object and signs the digest. The verifier uses the public key to check that the signature corresponds to the received object. Signatures provide integrity and evidence of possession of a private key. They do not automatically provide confidentiality.

Non-repudiation is a legal and organisational claim, not merely a mathematical property. A signature may support accountability, but its evidential strength depends on private-key protection, identity proofing, signing policy, audit records, legal rules and whether the signer could reasonably deny control of the key.

A public-key certificate is a digitally signed statement that associates a public key with an identity or subject and includes validity information, issuer information, key-usage constraints and a serial number. In common X.509 systems, a certificate authority (CA) signs the certificate. A browser or operating system trusts a configured root CA and evaluates a chain through intermediate certificates to the subject certificate.

Certificate validation includes checking the signature chain, validity period, intended purpose, subject name, key usage and revocation status where applicable. Trusting a certificate does not mean trusting every action by its subject. Certificate compromise, domain mis-issuance, weak validation and private-key theft remain important risks.

6. Public-Key Infrastructure

PKI is the combination of technology, people, procedures and policies used to create, issue, distribute, validate, renew and revoke certificates. Its components commonly include:

• a root CA, whose trust anchor is distributed through controlled trust stores;
• intermediate CAs, which reduce direct exposure of the root private key;
• a registration authority (RA), which verifies identity or approval information;
• certificate repositories and validation services;
• certificate policies, operational procedures and audit controls.

A root CA should normally be highly protected and used sparingly. Intermediate CAs can issue operational certificates, while the root remains offline or otherwise strongly restricted. Organisations must define who may request certificates, how identity is verified, which names and purposes are permitted, and how incidents are handled.

Revocation may be communicated through certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OCSP). Revocation systems have operational limitations, including caching, availability and incomplete checking. Short-lived certificates and automated renewal can reduce the period of exposure, but automation itself must be secured.

7. Key Management: The Operational Foundation

Cryptographic strength is limited by the protection of keys. A key-management lifecycle includes generation, registration, distribution, storage, use, rotation, archival, recovery, revocation and destruction.

Generation: use approved algorithms and a CSPRNG. Define key purpose, owner, algorithm, strength, creation date and expiry. Never derive production keys from predictable values.

Storage: protect keys with access controls, encryption and separation of duties. Hardware security modules (HSMs), trusted platform modules (TPMs), cloud key-management services and operating-system keystores can reduce exposure. A key-encryption key may protect a data-encryption key, but the wrapping key also requires protection.

Access: apply least privilege. Services should access only the keys required for their function. Administrative access should be authenticated strongly, logged and reviewed. Key use should be auditable without logging the secret itself.

Rotation and expiry: rotation limits the amount of data exposed by a compromised key and supports algorithm or policy changes. Rotation must include a migration plan: old data may need re-encryption, and old keys may need controlled read-only availability until migration is complete.

Backup and recovery: encrypted backups are useful only if recovery keys are available and tested. Key backups should be protected separately, with controlled escrow or split knowledge where appropriate. Losing a key can make data permanently unrecoverable.

Destruction: keys should be securely destroyed when no longer required, subject to legal retention and recovery obligations. Deleting a database record may not destroy copies in snapshots, caches or backups.

A useful governance record is a key inventory containing owner, purpose, location, algorithm, lifecycle state, dependencies, access roles and recovery arrangements. Separation of duties reduces the risk that one person can create, approve and use a sensitive key without oversight.

8. Protecting Data at Rest, in Transit and in Use

Data at Rest

Data at rest includes files, databases, backups, removable media, virtual-machine disks and mobile-device storage. Full-disk encryption protects lost or stolen media when the device is powered off, but it may not protect data after an attacker gains access to a running, unlocked system. File- or field-level encryption can provide finer control for sensitive records, while database encryption and tokenisation can reduce exposure to administrators or application breaches.

Controls should include classification, least-privilege access, encrypted backups, secure deletion policies, key separation and monitoring. Tokenisation replaces a sensitive value with a surrogate token; the mapping is kept in a controlled vault. Unlike encryption, tokenisation is not necessarily based on reversible mathematical transformation, and its security depends heavily on the token vault and process design.

Data in Transit

Data in transit moves across networks, including internal networks and service-to-service links. TLS provides an authenticated, encrypted channel when correctly configured. Secure deployment requires certificate validation, modern protocol versions, appropriate cipher suites, private-key protection, endpoint authentication where needed, and protection against downgrade and misconfiguration. VPNs can protect network paths but do not replace application authentication or endpoint security.

Encryption in transit does not protect data before encryption or after decryption. Logging systems, proxies and monitoring tools must therefore be designed so that plaintext is not unnecessarily copied.

Data in Use

Data in use is being processed in memory, registers, caches or applications. Conventional encryption normally requires plaintext during legitimate processing. Controls include application isolation, least privilege, secure enclaves or confidential-computing technologies, memory protections, process integrity, access monitoring and minimisation of sensitive data. These technologies can reduce exposure but may introduce performance, compatibility, side-channel and vendor-trust concerns.

A sound selection decision considers confidentiality requirements, integrity and authenticity needs, performance, availability, recovery, regulatory duties, key ownership, interoperability and threat model. Encryption should not be selected solely because it is fashionable; it should address a defined risk.

9. Applied Case: Protecting a Health-Appointment Platform

Background. An illustrative healthcare provider operates a web application containing patient identifiers, appointment details and billing information. The service uses a cloud database, mobile clients and an analytics platform.

Problem. An assessment finds that database backups are unencrypted, TLS certificate renewal is manual, developers share a database password, and exported analytics files contain unnecessary identifiers. The organisation has confidentiality and integrity obligations and must preserve service availability.

Analysis. The threat model includes stolen backup media, interception on hostile networks, credential theft, excessive internal access and accidental disclosure through analytics. Full-disk encryption alone would not address application-level exports or stolen database credentials. Hashing patient records would also be inappropriate where authorised systems must retrieve the original values.

Approach. The provider classifies fields and minimises analytics data. It encrypts database storage and backups, uses field-level encryption for particularly sensitive values, and stores data-encryption keys through a managed KMS backed by an HSM. The application uses separate service identities and short-lived credentials. TLS protects every external and service-to-service connection, with automated certificate issuance and renewal. Passwords are stored using a dedicated password-hashing function with unique salts. Software releases are digitally signed, and audit logs record key use without recording secret values. A tested recovery process protects encrypted backups and controls key restoration.

Outcome. The design reduces exposure from lost media and network interception, limits the impact of one compromised service identity, and improves operational reliability. It does not make the system immune to a compromised application server: authorised processes can still access plaintext. Continuous patching, access review, incident response and privacy governance remain necessary.

Learning points. Data minimisation complements encryption; key management is as important as algorithm choice; automated renewal reduces avoidable certificate failures; and controls must be tested against realistic failure and compromise scenarios.

10. Limitations, Ethics and Contemporary Developments

Cryptography can protect privacy, but it can also be used by criminals and can complicate lawful investigation. Organisations should establish transparent policies, lawful access procedures and proportional retention practices rather than creating indiscriminate weaknesses. Deliberate backdoors undermine security because they create another target and cannot reliably be limited to intended users.

Regulatory obligations may require appropriate technical and organisational safeguards, breach reporting, retention controls, data minimisation and demonstrable accountability. Requirements vary by jurisdiction and sector; technical teams should work with legal, privacy and risk professionals.

Emerging concerns include quantum computing, which threatens some widely deployed public-key assumptions. Post-quantum cryptography seeks algorithms believed to resist relevant quantum attacks, while hybrid migration strategies may combine classical and post-quantum mechanisms during transition. Organisations should inventory cryptographic dependencies, identify long-lived confidential data, monitor standards and avoid unverified products.

Artificial intelligence systems also require cryptographic protection. Training data, model artefacts, API traffic and audit records may require encryption, signatures and access controls. Signed provenance metadata can help establish where an artefact came from, but a signature does not prove that the content is truthful or unbiased. Privacy-enhancing techniques such as secure multiparty computation, homomorphic encryption and differential privacy can reduce exposure in specialised cases, but they involve computational, accuracy and implementation trade-offs.

Best-Practice Checklist

1. Define the threat model and classify data before selecting controls.
2. Prefer reviewed, standard algorithms and maintained libraries.
3. Use AEAD for application-level encrypted data unless a justified alternative is required.
4. Never invent cryptographic algorithms or reuse nonces against algorithm requirements.
5. Use dedicated password-hashing functions with unique salts.
6. Protect private keys with least privilege, strong authentication and auditable systems.
7. Automate certificate issuance, renewal and monitoring where safely possible.
8. Separate keys by environment, tenant, purpose and appropriate lifecycle boundary.
9. Test backup restoration, key recovery, revocation and incident procedures.
10. Treat encryption as one control within defence in depth, not as a substitute for secure systems and governance.

Chapter Summary

Cryptography protects information through encryption, hashing, authentication and digital signatures. Symmetric encryption is efficient for bulk data, while public-key cryptography supports key establishment and identity binding. AEAD combines confidentiality with tamper detection, whereas hashes provide integrity evidence but not secrecy. Passwords require salted, deliberately expensive password-hashing functions.

Digital signatures demonstrate control of a private key and support integrity and authentication. Certificates bind public keys to subjects through a CA hierarchy, and PKI supplies the processes needed to issue, validate, renew and revoke those certificates. Key management—including secure generation, storage, access, rotation, recovery and destruction—is the operational foundation of cryptographic security.

Data at rest may require disk, database, field-level encryption or tokenisation; data in transit commonly requires correctly configured TLS; and data in use needs process, memory and workload protections. Selection must reflect the threat model, lifecycle, availability, legal duties and human factors. Strong algorithms cannot compensate for poor implementation, lost keys, excessive privileges or weak governance.

Key Terms

Cryptography: The practice of protecting information using mathematical techniques.

Plaintext: Readable or unencrypted data.

Ciphertext: Data produced by encryption.

Symmetric encryption: Encryption using a shared secret key.

Asymmetric cryptography: Cryptography using related public and private keys.

AEAD: Authenticated encryption with associated data, providing confidentiality and integrity.

Hash function: A function that produces a fixed-length digest from input data.

Salt: A unique value added to a password before password hashing.

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

Digital signature: A private-key-generated value that supports integrity and authentication.

Certificate: A signed binding between a public key and an identity or subject.

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

PKI: The people, policies, processes and technologies supporting certificate-based trust.

HMAC: A keyed hash used to authenticate and verify message integrity.

Key management: The lifecycle governance and protection of cryptographic keys.

HSM: A hardware security module designed to protect and use cryptographic keys.

Data at rest: Data stored on media or systems.

Data in transit: Data moving across a network or communication channel.

Data in use: Data currently being processed.

Tokenisation: Replacing sensitive data with a controlled surrogate value.

Review Questions

Short Answer Questions

1. Distinguish encryption, hashing and encoding.
2. Why should ECB mode generally not be used for structured data?
3. What is the purpose of a salt in password storage?
4. What information does a digital certificate associate?
5. State two responsibilities in the cryptographic key lifecycle.

Long Answer Questions

1. Explain how a hybrid cryptographic system combines public-key and symmetric cryptography.
2. Describe how a certificate chain is validated in a PKI.
3. Compare the controls required for protecting data at rest, in transit and in use.
4. Explain why key management can be more significant operationally than the choice between two strong algorithms.
5. Discuss the security and governance limitations of digital signatures and encryption.

Analytical / Application Questions

1. A company encrypts its laptops but stores unencrypted database backups in cloud storage. Analyse the gap and propose a layered protection design.
2. A web service uses TLS but accepts any server certificate presented by a client library. Identify the threat and recommend corrective measures.
3. An organisation wants to hash customer identity numbers so that authorised staff can retrieve the original numbers later. Evaluate whether hashing is suitable and recommend an alternative.

Multiple Choice Questions with Answers

Question 1

Which technique is primarily designed to provide confidentiality for bulk data?

A. Symmetric encryption

B. Cryptographic hashing

C. Base64 encoding

D. Digital signing

Correct Answer: A. Symmetric encryption

Question 2

What is the main purpose of authenticated encryption with associated data (AEAD)?

A. To compress plaintext before storage

B. To provide confidentiality and detect unauthorised modification

C. To replace all certificate authorities

D. To make passwords recoverable

Correct Answer: B. To provide confidentiality and detect unauthorised modification

Question 3

Which item must normally remain secret in public-key cryptography?

A. The public key

B. The certificate issuer name

C. The private key

D. The algorithm name

Correct Answer: C. The private key

Question 4

Why is a unique salt used when storing passwords?

A. To make the password reversible

B. To prevent identical passwords from having identical stored results

C. To replace the need for a password-hashing function

D. To authenticate a TLS certificate

Correct Answer: B. To prevent identical passwords from having identical stored results

Question 5

What does a digital signature primarily provide?

A. Confidentiality without keys

B. Integrity and evidence of control of a private key

C. Guaranteed availability

D. Physical protection of a server

Correct Answer: B. Integrity and evidence of control of a private key

Question 6

What is the role of a certificate authority in a PKI?

A. To issue and sign certificates binding keys to subjects

B. To store every user's plaintext password

C. To decrypt all network traffic

D. To generate database backups

Correct Answer: A. To issue and sign certificates binding keys to subjects

Question 7

Which control is most directly concerned with limiting the amount of data exposed if a key is compromised?

A. Key rotation

B. Base64 encoding

C. Increasing screen brightness

D. Disabling audit logs

Correct Answer: A. Key rotation

Question 8

Which statement about data in use is correct?

A. It is always protected by full-disk encryption

B. It is data currently being processed, often in memory

C. It refers only to archived paper records

D. It cannot contain plaintext

Correct Answer: B. It is data currently being processed, often in memory

Question 9

A hash comparison can reliably detect tampering only when what condition holds?

A. The attacker can replace both file and reference digest

B. The reference digest is trusted or authenticated

C. The file is encoded with Base64

D. The hash output is kept secret from the owner

Correct Answer: B. The reference digest is trusted or authenticated

Question 10

What is a major danger of reusing a nonce with an algorithm that requires nonce uniqueness?

A. It can expose plaintext or compromise security guarantees

B. It always increases confidentiality

C. It permanently deletes the key

D. It converts encryption into encoding

Correct Answer: A. It can expose plaintext or compromise security guarantees