Data Protection and Applied Cryptography

Introduction

Web and application security depends on protecting information throughout its lifecycle. Data may be exposed while travelling between systems, stored in databases or files, processed in application memory, or copied into logs, backups and analytical platforms. Cryptography provides essential mechanisms for confidentiality, integrity, authentication, accountability and privacy, but it is not a complete security strategy. A strong algorithm can be undermined by poor key management, insecure certificate validation, weak randomness, unsafe logging or inappropriate access controls.

This chapter develops a practical and conceptual foundation for applying cryptography in web applications. It examines TLS, encryption at rest and in use, hashing, message authentication, digital signatures, certificates, key management, secrets management, tokenisation and privacy-aware data handling. It also analyses common cryptographic failures and presents a structured approach to designing defensible protection controls.

Learning objectives

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

• distinguish confidentiality, integrity, authentication, non-repudiation and privacy;
• select appropriate cryptographic primitives for common application requirements;
• explain how TLS protects data in transit;
• compare authenticated encryption, hashing, MACs and digital signatures;
• design basic key, certificate and secrets-management processes;
• distinguish encryption from tokenisation and anonymisation;
• identify cryptographic implementation failures and propose mitigations;
• evaluate data-protection decisions against risk, privacy and governance requirements.

1. Security properties and the data lifecycle

The traditional confidentiality–integrity–availability model remains useful, but cryptographic controls mainly contribute to confidentiality and integrity. Authentication establishes the identity of an entity, while authorisation determines what that entity may do. Accountability links actions to identities and records; non-repudiation is a stronger legal and technical claim that an action can be attributed to a signer, although cryptography alone cannot settle every legal dispute.

Data should be classified according to its sensitivity and followed through four states:

1. In transit: moving across a network, such as a browser request to an API.
2. At rest: stored in databases, object stores, disks, backups or queues.
3. In use: being processed in application memory, queries or analytics.
4. In disposal: being deleted, expired or rendered unrecoverable.

Protection should be proportional to impact. Payment credentials, identity documents and authentication secrets generally require stronger controls than public product information. Classification should also consider regulatory obligations, retention periods, data-subject rights, business value and the consequences of unauthorised disclosure or alteration.

Cryptography does not replace secure design. An encrypted database may still be compromised through an application endpoint that returns excessive records. TLS may protect a connection while an application stores sensitive values in plaintext logs. A password hash may be strong while the password-reset process is vulnerable. Effective protection therefore combines cryptography with identity management, least privilege, secure coding, monitoring, resilient backups and sound governance.

2. Cryptographic building blocks

2.1 Symmetric encryption

Symmetric encryption uses the same secret key for encryption and decryption. For a plaintext message P, key K and ciphertext C, the conceptual relationship is:

The symbols represent algorithms rather than arithmetic operations. Correct decryption requires the same key, compatible algorithm parameters and, for modern modes, the correct nonce or initialization value. Symmetric encryption is efficient and is therefore used for bulk data, including web traffic, database fields and files.

Modern applications should normally use authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305. AEAD provides confidentiality and an authentication tag that detects unauthorised modification. Associated data, such as a record identifier or protocol version, can be authenticated without being encrypted.

A nonce is normally required for each encryption operation. In AES-GCM, nonce reuse with the same key is dangerous and can seriously compromise confidentiality and authentication. Nonces need not always be secret, but they must satisfy the algorithm’s uniqueness requirements. A practical design stores the nonce with the ciphertext and protects the key separately.

ECB mode should not be used for ordinary application data because identical plaintext blocks produce visible patterns. CBC and CTR modes require careful handling: encryption alone does not authenticate ciphertext, and misuse can enable modification or padding-oracle attacks. AEAD is generally preferable because it combines encryption and integrity protection in one reviewed construction.

2.2 Asymmetric cryptography

Asymmetric cryptography uses a mathematically related public-key and private-key pair. The public key may be distributed; the private key must remain controlled by its owner. Public-key operations support key establishment, signatures and identity verification, but are usually slower than symmetric encryption.

In a typical hybrid system, asymmetric cryptography authenticates parties and establishes a shared secret, while symmetric cryptography protects the actual data stream. This is the basic design used by TLS. Public-key algorithms include RSA and elliptic-curve systems, but security depends on approved parameters, secure implementations and appropriate protocol use. Applications should use current, well-maintained libraries rather than implementing these algorithms themselves.

2.3 Hash functions

A cryptographic hash maps input of arbitrary length to a fixed-length digest:

Here, M is the message, H is the hash function and h is the digest. A secure hash should make it computationally infeasible to find a preimage, a second input with the same digest as a given input, or two different inputs with the same digest. Hashes are one-way integrity fingerprints, not encryption: the original message is not recovered from the digest.

SHA-256 and SHA-3 are examples of general-purpose hash functions. MD5 and SHA-1 should not be selected for collision-sensitive security functions. A hash alone does not prove who created a message because anyone can calculate it. To authenticate a message, use a MAC or digital signature.

Passwords require a different approach. They should be processed with a deliberately slow, memory-hard password-hashing function such as Argon2id, or an appropriate bcrypt or scrypt configuration. Each password requires a unique, randomly generated salt. A salt is not a secret; it prevents identical passwords from producing identical stored values and frustrates precomputed tables. Password hashing parameters should be reviewed as hardware changes. A server-side pepper may provide an additional layer, but it must be protected separately from the password database.

2.4 Message authentication codes

A MAC combines a message and a shared secret:

The recipient recomputes the tag t using the shared key K and compares it using a constant-time operation. HMAC is a widely used construction based on a cryptographic hash. A MAC provides integrity and authentication to parties that share the secret, but it does not provide public verifiability: either party possessing the key could have generated the tag.

2.5 Digital signatures

A digital signature is generated with a private key and verified with the corresponding public key:

SK is the private key, PK is the public key and s is the signature. Signatures provide integrity and public-key authentication when the public key is reliably bound to an identity. They are used for software signing, certificates, signed tokens and transaction approval. A signature does not automatically provide confidentiality; encryption is required for that purpose.

3. TLS and protection in transit

Transport Layer Security protects application communication against eavesdropping, tampering and impersonation when correctly configured. HTTPS is HTTP carried over TLS. A simplified TLS connection has the following stages:

1. The client and server negotiate supported protocol versions and cryptographic parameters.
2. The server presents a certificate containing a public key and identity information.
3. The client validates the certificate chain, name, validity period, usage constraints and trust anchor.
4. The parties perform a key-establishment exchange, normally using ephemeral parameters.
5. Both derive symmetric traffic keys and verify the handshake transcript.
6. Application data is exchanged using authenticated encryption.

The certificate authority (CA) system does not make a server inherently trustworthy. It provides a mechanism for a client to verify that a trusted authority has attested to a public key’s association with a domain or organisation. Certificate validation must include hostname matching, chain validation, expiry checks, key-usage constraints and revocation or status mechanisms where applicable. Disabling certificate validation to “fix” an error creates a serious impersonation vulnerability.

Modern deployments should prefer TLS 1.3 where supported and disable obsolete protocol versions and weak cipher suites according to current organisational standards. Secure configurations also include HTTP Strict Transport Security (HSTS), secure cookie attributes, correct redirect handling and protection against mixed content. TLS should be used between internal services as well as from users to the public edge when internal traffic carries sensitive data. This is often called service-to-service or mutual TLS when both sides authenticate with certificates.

TLS protects data in transit between authenticated endpoints. It does not protect data after an endpoint decrypts it, nor does it prevent an authorised application from disclosing data. Endpoint security, access control and application-layer authorisation remain necessary.

4. Encryption at rest and in use

4.1 Storage encryption patterns

Full-disk encryption protects data if a device or disk is stolen, particularly when the system is powered off. It may not protect data from a running operating system or a compromised application. Database or volume encryption protects storage media but often exposes plaintext to the database engine and authorised queries.

Application-level or field-level encryption can reduce exposure by encrypting selected values before storage. It is useful for high-impact fields, but introduces operational complexity. Search, sorting, equality queries, indexing, backups and key rotation become more difficult. Deterministic encryption may support equality queries but reveals when values are equal; this leakage must be accepted only after risk analysis. Randomised encryption provides stronger semantic confidentiality but generally prevents direct equality searching.

Envelope encryption separates data encryption keys (DEKs) from key-encryption keys (KEKs). The application generates a DEK to encrypt data, then encrypts the DEK under a KEK held by a key-management service. The encrypted DEK is stored with the ciphertext, while the KEK remains centrally controlled. This supports scalable key rotation: a KEK can be changed by rewrapping DEKs without re-encrypting every data object, subject to the design and threat model.

4.2 Backups, replicas and logs

Backups and replicas are part of the data estate, not exceptions. They require encryption, access control, retention management, secure transfer and restoration testing. Logs should avoid secrets, access tokens, full payment-card values and unnecessary personal data. Redaction must occur before data reaches central logging because later cleanup may be incomplete.

4.3 Data in use

Data in use is usually visible to the process that must operate on it. Controls include process isolation, least-privilege database accounts, memory protection, secure enclaves where justified, confidential-computing technologies and minimisation. Fully homomorphic encryption and secure multi-party computation can support limited computation without exposing plaintext to particular parties, but they remain specialised because of performance, complexity and implementation constraints. They should not be presented as universal replacements for conventional application security.

5. Key, certificate and secrets management

Cryptographic security is frequently defeated by key-management failures rather than broken algorithms. A key-management lifecycle should include generation, distribution, storage, use, rotation, backup, revocation, recovery and destruction.

Keys should be generated with an approved cryptographically secure random number generator. They should be stored in a hardware security module, cloud key-management service or carefully controlled secrets system according to risk. Access should be authenticated, authorised, logged and separated by environment. Production keys should not be shared with development teams or embedded in source code, mobile applications, container images or client-side JavaScript.

Rotation must be planned rather than improvised. Systems should support overlapping validity periods so old and new keys can coexist during migration. Rotation does not repair data already exposed, and it does not necessarily require re-encrypting data when envelope encryption permits key rewrapping. Revocation is required when a key or certificate is compromised, misused or no longer trusted.

Secrets include API keys, database passwords, signing keys, OAuth client secrets, private certificates and encryption keys. A secrets-management service should provide controlled retrieval, auditing, versioning, expiry and emergency revocation. Applications should receive only the secrets required for their function and should fail safely if retrieval is unavailable. Secrets must not be placed in URLs, source-control history or error messages.

Certificates need inventory and renewal monitoring. Automated renewal is desirable, but automation must include validation, alerting and recovery. An expired certificate can cause an outage; a stolen private key can enable impersonation even when the certificate itself remains valid.

6. Tokenisation, pseudonymisation and privacy-aware handling

Tokenisation replaces a sensitive value with a token whose meaning is not derived from the original value. A protected token vault or controlled mapping is required to reverse the process. Tokenisation can reduce the number of systems handling payment-card data, but it is not automatically anonymisation: the mapping or surrounding data may permit re-identification.

Pseudonymisation replaces identifiers with codes while retaining a separate means of linking records to individuals. It reduces exposure and supports analytics, but pseudonymised data can remain personal data under privacy law. Anonymisation aims to make re-identification infeasible using reasonably likely means; it is difficult to guarantee, especially when datasets can be combined.

Privacy-aware handling follows several principles:

• collect only data necessary for a specified purpose;
• define retention and deletion rules;
• restrict access according to role and purpose;
• separate identifiers from analytical attributes where practical;
• document processing, sharing and international transfers;
• provide transparency and support applicable data-subject rights;
• assess re-identification and linkage risks;
• test whether masking and redaction actually prevent disclosure.

Masking is often a display technique rather than a security boundary. Showing only the last four digits of a card number may be appropriate in a user interface, but the underlying system still requires access control and protected storage. Differential privacy can reduce disclosure in aggregate reporting by adding carefully calibrated statistical noise, but it involves a privacy–utility trade-off and requires expertise in privacy budgets and repeated-query risks.

7. Common cryptographic failures

Hard-coded and exposed secrets

Keys in repositories, configuration files or client code are readily copied. Remediation includes secret scanning, immediate revocation, secure injection and historical repository cleanup. Scanning alone is insufficient if exposed credentials remain valid.

Weak or obsolete algorithms

MD5, SHA-1 for collision-sensitive purposes, DES, unauthorised custom algorithms and obsolete TLS versions create avoidable risk. Use approved libraries and current organisational standards.

Encryption without integrity

Encrypting data with a mode that does not authenticate it allows manipulation. Use AEAD or a carefully reviewed encrypt-then-authenticate design.

Nonce and randomness errors

Nonce reuse in algorithms such as AES-GCM, predictable session identifiers and weak random-number generation can destroy security. Use library-generated nonces and operating-system cryptographic randomness, and understand each algorithm’s uniqueness requirements.

Password misuse

Plaintext passwords, reversible encryption, unsalted hashes and fast general-purpose hashes are inappropriate. Use adaptive password hashing, rate limiting, multifactor authentication and secure recovery processes.

Certificate-validation bypass

Accepting any certificate, ignoring hostname errors or trusting user-supplied certificates defeats TLS authentication. Validation failures must be treated as security events or configuration defects.

Incorrect signature assumptions

A signature validates the signed bytes, not necessarily the meaning of a business transaction. Canonicalisation, algorithm selection, key ownership, timestamping and authorisation must be addressed. A signed token is not automatically safe if its claims are trusted without checking issuer, audience, expiry and intended use.

Cryptographic side channels

Timing differences, error messages, cache behaviour and power consumption can reveal information. Constant-time comparisons, uniform error handling, hardened libraries and threat-specific testing reduce exposure. Side-channel controls are especially important for private-key operations and authentication checks.

8. Applied case: a healthcare appointment platform

The following is an illustrative case. A healthcare provider operates a web portal where patients book appointments, clinicians view records and an analytics team studies service demand. The original platform uses HTTPS externally, stores records in a relational database and sends application logs to a central service.

Problem

A security review finds that database backups are accessible to several operations accounts, API tokens appear in debug logs, certificates are renewed manually, and patient identifiers are used directly in analytics datasets. The database is encrypted at the storage-volume level, but the application account can query all clinical fields. Passwords are stored using a fast hash without a documented work factor.

Analysis

The platform has partial protection in transit and at rest, but excessive privilege and poor lifecycle controls create significant exposure. Volume encryption limits the impact of stolen media but does not prevent a compromised application or privileged database user from reading plaintext. Logs and analytics create secondary copies. Manual certificate renewal increases outage risk, while weak password hashing increases the value of a stolen credential database.

Approach

The organisation adopts a data inventory and classification scheme. External and internal service connections use validated TLS, with mutual TLS for selected service-to-service paths. Patient passwords are migrated to Argon2id using unique salts and an approved cost profile; migration occurs after successful login or through a controlled reset process. Database access is divided by service function, and sensitive clinical fields receive application-level protection using envelope encryption. DEKs are managed through a key-management service, while access is audited.

Tokens and identifiers are removed from logs through structured logging and pre-ingestion redaction. Analytics receives pseudonymised records with a separately governed linkage service. Backups are encrypted with restricted keys, retention is documented and restoration is tested. Certificate inventory and automated renewal are introduced, with alerts for failed renewal. Incident procedures include key revocation, credential rotation and evidence preservation.

Outcome

The redesign reduces the number of systems handling direct identifiers, limits the blast radius of a single service compromise and improves detection of misuse. It does not eliminate risk: authorised clinical users can still access sensitive information, application memory can contain plaintext during processing and analytics may still permit inference. Continuous access review, secure development, privacy assessment and monitoring remain necessary.

Learning points

1. Protection must follow data across primary and secondary copies.
2. Encryption is strongest when paired with least privilege and key separation.
3. Privacy engineering includes minimisation and governance, not only cryptography.
4. Operational processes such as renewal, rotation and recovery are security controls.
5. A realistic design states what encryption does not protect.

9. Professional practice and governance

Organisations should maintain a cryptographic policy identifying approved algorithms, minimum parameters, prohibited practices, ownership and exception processes. A cryptographic inventory should record where keys, certificates, algorithms and sensitive data are used. Threat modelling should identify who can access plaintext, where trust boundaries exist and what compromise of each key would expose.

Security teams should monitor standards and prepare for algorithm migration. Post-quantum cryptography is an important contemporary development because sufficiently capable quantum computers could threaten some widely used public-key algorithms. Organisations should inventory public-key use, prefer crypto-agile architectures and follow authoritative migration guidance. This does not justify replacing production algorithms with unreviewed experimental code.

Regulatory requirements vary by jurisdiction and sector, but common expectations include purpose limitation, access control, breach response, retention management, documented risk assessment and protection of personal data. Compliance is not equivalent to security. A compliant control may still be badly implemented, and a technically strong control may require additional documentation or lawful processing justification.

Best-practice checklist

• Use modern, maintained cryptographic libraries; do not implement primitives independently.
• Prefer AEAD for application encryption.
• Use TLS with strict certificate validation and current protocol settings.
• Generate keys and nonces with approved cryptographic randomness.
• Separate data keys from key-encryption keys where envelope encryption is appropriate.
• Store secrets outside source code and rotate or revoke them through controlled processes.
• Hash passwords with an adaptive password-hashing function and unique salts.
• Protect backups, replicas, logs and test data as part of the data estate.
• Minimise personal data and distinguish masking, tokenisation, pseudonymisation and anonymisation.
• Test failure modes, certificate renewal, restoration, key rotation and incident response.
• Record assumptions, residual risks and ownership for every cryptographic control.

Chapter Summary

Cryptography protects data through encryption, hashing, MACs, signatures and authenticated protocols, but its value depends on correct implementation and lifecycle management. Symmetric encryption efficiently protects bulk data; asymmetric cryptography supports key establishment and signatures; hashes provide integrity fingerprints; MACs authenticate messages between parties sharing a secret; and digital signatures provide publicly verifiable integrity and origin authentication. TLS protects network communication only when certificate validation and protocol configuration are correct.

Data at rest requires attention to disks, databases, backups, logs and replicas. Envelope encryption, key separation and controlled rotation improve manageability. Data in use remains visible to authorised processes, so least privilege, isolation and minimisation remain essential. Secrets and certificates require inventory, secure storage, renewal, revocation and monitoring. Tokenisation and pseudonymisation can reduce exposure but do not automatically produce anonymity. The most serious failures commonly arise from exposed keys, weak password storage, nonce reuse, obsolete algorithms, unauthenticated encryption and certificate-validation bypasses. Effective data protection therefore combines sound cryptographic choices with application security, privacy governance and disciplined operations.

Key Terms

AEAD: Authenticated encryption with associated data; encryption that also verifies integrity and selected unencrypted metadata.

Asymmetric cryptography: Cryptography using related public and private keys.

Certificate authority: An entity that issues certificates binding public keys to identities under defined trust rules.

Ciphertext: The protected output produced from plaintext by encryption.

Cryptographic hash: A one-way fixed-length digest produced from input data.

Data encryption key: A key used to encrypt data directly.

Digital signature: A private-key-generated value that supports public verification of integrity and origin.

Envelope encryption: Encrypting a data key with a separately managed key-encryption key.

Hash salt: A unique non-secret random value added to password processing.

Key-encryption key: A key used to protect or wrap another key.

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

Nonce: A value intended for one-time or unique use with a cryptographic operation.

Pseudonymisation: Replacing identifiers while retaining a controlled possibility of linkage.

Symmetric encryption: Encryption and decryption using the same secret key.

TLS: Transport Layer Security, a protocol for authenticated and encrypted communication.

Tokenisation: Replacing sensitive data with a controlled token that does not reveal the original value.

Trust anchor: A pre-established trusted certificate or public key used to validate a certificate chain.

Key rotation: Replacing an active cryptographic key according to a controlled lifecycle process.

Review Questions

Short Answer Questions

1. What are the principal differences between encryption, hashing and digital signatures?
2. Why must a TLS client validate a server certificate rather than merely receive it?
3. What is the purpose of a salt in password hashing?
4. Explain the role of a data-encryption key and a key-encryption key in envelope encryption.
5. Why is tokenisation not necessarily anonymisation?

Long Answer Questions

1. Explain the TLS handshake and discuss what TLS protects and does not protect.
2. Compare symmetric encryption, MACs and digital signatures in terms of keys, confidentiality, integrity and authentication.
3. Design a key-management lifecycle for a multi-service web application.
4. Discuss the advantages and limitations of field-level encryption compared with database or disk encryption.
5. Analyse how privacy principles should influence the collection, storage, logging and analytics of personal data.

Analytical / Application Questions

1. An application encrypts customer records with AES-GCM but reuses the same nonce for every record under one key. Identify the security problem and propose a safer design.
2. A development team disables certificate validation because an internal service uses a self-signed certificate. Evaluate the risk and recommend two secure alternatives.
3. A breach exposes a database containing salted password hashes, API tokens in logs and encrypted backups. Prioritise the incident-response actions and justify the order.

Multiple Choice Questions with Answers

Question 1

Which mechanism provides confidentiality and integrity together for application data?

A. A cryptographic hash

B. Authenticated encryption with associated data

C. A digital signature alone

D. A plaintext checksum

Correct Answer: B. Authenticated encryption with associated data

Question 2

What is the primary purpose of a password salt?

A. To make the password reversible

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

C. To prevent identical passwords from producing identical stored values

D. To authenticate a TLS certificate

Correct Answer: C. To prevent identical passwords from producing identical stored values

Question 3

Which key normally performs bulk data encryption in a hybrid cryptographic system?

A. A symmetric data-encryption key

B. A certificate authority key only

C. A public verification key only

D. A password salt

Correct Answer: A. A symmetric data-encryption key

Question 4

What does a digital signature primarily provide?

A. Confidentiality without any key

B. Integrity and publicly verifiable origin authentication

C. Guaranteed availability

D. Anonymisation of the signed data

Correct Answer: B. Integrity and publicly verifiable origin authentication

Question 5

Which TLS validation failure most directly permits server impersonation?

A. The client rejects an expired certificate

B. The client checks the hostname

C. The client accepts any certificate without validation

D. The server uses authenticated encryption

Correct Answer: C. The client accepts any certificate without validation

Question 6

Why is nonce reuse especially dangerous in AES-GCM?

A. It makes certificates expire immediately

B. It can compromise confidentiality and authentication

C. It converts ciphertext into a password hash

D. It prevents all forms of key rotation

Correct Answer: B. It can compromise confidentiality and authentication

Question 7

What is the main function of a key-encryption key in envelope encryption?

A. To display masked values to users

B. To hash passwords directly

C. To encrypt or wrap a data-encryption key

D. To replace certificate validation

Correct Answer: C. To encrypt or wrap a data-encryption key

Question 8

Which statement about a cryptographic hash is correct?

A. It is designed to be easily decrypted

B. It provides confidentiality by itself

C. It produces a fixed-length digest from input data

D. It proves which person created the input

Correct Answer: C. It produces a fixed-length digest from input data

Question 9

Which practice best protects application secrets?

A. Embedding them in client-side JavaScript

B. Committing them to source control

C. Storing them in a controlled secrets-management system

D. Including them in URLs for convenience

Correct Answer: C. Storing them in a controlled secrets-management system

Question 10

Which statement best describes pseudonymisation?

A. It guarantees that re-identification is impossible

B. It replaces identifiers while retaining a controlled means of linkage

C. It is identical to full-disk encryption

D. It removes the need for access control

Correct Answer: B. It replaces identifiers while retaining a controlled means of linkage