2. Cryptographic Foundations

Introduction and Context

Blockchain systems are often described as databases without a central administrator. That description is incomplete. A blockchain can operate among mutually distrustful participants because it combines distributed protocols with cryptographic mechanisms that provide integrity, authentication, authorization, and evidence of prior actions. Cryptography does not by itself create consensus or trust; rather, it supplies the mathematical tools on which these higher-level mechanisms depend.

A transaction recorded on a blockchain must be identifiable, resistant to alteration, and attributable to an authorized actor. Blocks must be linked so that changing an earlier record becomes detectable. Participants must be able to prove control of an account without disclosing a secret signing key. These requirements are addressed through cryptographic hash functions, Merkle structures, digital signatures, public-key infrastructures, commitments, and disciplined key management.

This chapter develops these foundations and examines their assumptions and failure modes. Particular attention is given to the difference between a cryptographic primitive and the system in which it is used. A secure hash function cannot compensate for poor key storage; a valid signature does not prove that the signed statement is truthful; and an immutable ledger may preserve fraudulent or unlawful data just as effectively as legitimate data. The chapter also considers quantum computing, which threatens some public-key systems while leaving other primitives comparatively more resilient.

Learning Objectives

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

1. Explain the security properties and construction of cryptographic hash functions.

2. Describe how Merkle trees and related authenticated data structures support efficient verification.

3. Distinguish digital signatures, encryption, authentication, and authorization.

4. Evaluate public-key infrastructure and certificate-based trust models.

5. Explain commitment schemes and their applications in blockchain protocols.

6. Design sound principles for cryptographic key generation, storage, rotation, recovery, and revocation.

7. Analyse common attacks, implementation failures, and cryptographic assumptions.

8. Assess the likely effects of quantum computing on blockchain cryptography.

Cryptography as a Set of Security Assumptions

Cryptographic security is generally computational rather than absolute. A scheme is considered secure when a stated adversary cannot defeat it within realistic computational resources. This security claim depends on assumptions about algorithms, key sizes, randomness, implementation correctness, and the adversary’s capabilities.

A useful distinction is between confidentiality, integrity, authenticity, and non-repudiation. Confidentiality prevents unauthorized disclosure. Integrity allows a recipient to detect alteration. Authenticity provides confidence about the origin of a message. Non-repudiation is a legal and evidentiary concept that may be supported by signatures but cannot be guaranteed by mathematics alone, because a private key may have been compromised or used by an automated process.

Blockchain applications commonly emphasize integrity and authenticity rather than confidentiality. Public ledgers are deliberately transparent, while private information is normally kept off-chain or protected using encryption, access controls, and privacy-preserving protocols. A hash of personal information may still be personal data if it can be linked to an identifiable individual; hashing is not automatically anonymization.

Hash Functions: Digital Fingerprints with Precise Limits

A cryptographic hash function maps an input of arbitrary length to a fixed-length output, usually called a digest. For a function H, a message m produces H(m). A secure hash function is deterministic: identical inputs produce identical outputs. It is also efficiently computable, but finding a meaningful relationship between inputs and outputs should be computationally difficult.

Three properties are particularly important. Preimage resistance means that, given a digest y, it should be infeasible to find any m such that H(m) = y. Second-preimage resistance means that, given a message m, it should be infeasible to find a different message m' with the same digest. Collision resistance means that it should be infeasible to find any two distinct messages m and m' for which H(m) = H(m'). Collision resistance is formally a different and generally stronger requirement than merely hiding a message.

The birthday bound explains why an n-bit hash does not provide n bits of collision security. An attacker searching approximately 2^(n/2) inputs has a substantial probability of finding a collision. Thus, a 256-bit hash is commonly associated with approximately 128-bit collision resistance, assuming no better attack is known. Preimage security is typically closer to 256 bits for the same function.

Hash functions are used in block identifiers, transaction identifiers, proof-of-work puzzles, address derivation, signature pre-processing, and content-addressed storage. In a blockchain, a block header normally includes the hash of a previous block. If an earlier block is modified, its digest changes and the link to the next block becomes invalid. This creates tamper evidence, not an absolute impossibility of alteration. An attacker with sufficient control over consensus resources, or with access to a mutable administrative mechanism, may still rewrite history.

Hashing must not be confused with encryption. Encryption is designed to be reversible by an authorized key holder; a cryptographic hash is intended to be one-way. Hashing a low-entropy password without a salt and a password-strengthening function is unsafe because an attacker can test likely passwords rapidly. For passwords, specialized functions such as Argon2, scrypt, or bcrypt are more appropriate than a general-purpose blockchain hash.

A secure implementation must also avoid obsolete or inappropriate algorithms. MD5 and SHA-1 have important collision weaknesses and should not be selected for new integrity-critical systems. The choice of SHA-256, SHA-3, or another approved function should be guided by the protocol specification, security requirements, interoperability, and long-term migration plans.

Merkle Structures and Authenticated Data

A Merkle tree is a hierarchical commitment to a collection of data. Leaf nodes contain hashes of transactions or records. Internal nodes contain the hash of the concatenation, or another precisely specified combination, of their child hashes. The root hash summarizes the entire set. In a binary tree with leaves L1 and L2, an internal node may be H(L1 || L2), where || denotes concatenation.

The root is stored in a block header or another trusted record. To prove that a transaction belongs to the committed collection, a claimant supplies the transaction and a Merkle path consisting of the sibling hashes needed to reconstruct the root. Verification requires only logarithmic communication and computation relative to the number of leaves. This is substantially more efficient than transmitting the complete transaction set.

Merkle proofs provide inclusion evidence, not necessarily exclusion evidence. A proof that transaction X is included demonstrates consistency with a particular root, provided the root itself is trusted. Proving that X is absent requires additional structures, such as a sorted Merkle tree, a sparse Merkle tree, or a proof system with non-membership support.

Practical designs must define leaf ordering, duplicate handling, domain separation, serialization, and odd-node treatment. Ambiguity can permit second-preimage-style attacks or cause different implementations to calculate different roots. Domain separation—using distinct prefixes or encodings for leaves and internal nodes—helps prevent structural confusion. A Merkle root also commits to the data representation, so canonical encoding is essential.

Merkle trees are used in simplified payment verification, distributed storage, state commitments, transparency logs, rollups, and authenticated databases. Sparse Merkle trees are especially useful when the logical key space is large and proofs of both membership and non-membership are required. Vector commitments and polynomial commitments extend the same general idea: commit compactly to a large object while enabling verifiable queries.

Digital Signatures and the Logic of Authorization

A digital signature scheme consists of key generation, signing, and verification. Key generation creates a private key and a corresponding public key. The signer uses the private key to produce a signature over a message; a verifier uses the public key to determine whether the signature is valid for that message and key.

A signature normally provides message integrity and evidence that the holder of the private key authorized the signed data. It does not encrypt the message. Anyone possessing the public key may verify it, and anyone who can read the ledger may often read the signed transaction. It also does not establish that the transaction was wise, lawful, or based on accurate information.

Blockchain transaction formats typically bind the signature to more than a payment amount. They may include the destination, asset, fee, account nonce, chain identifier, and other context. This prevents replay across chains or repeated use of an earlier transaction. The exact encoding must be unambiguous and resistant to malleability. If two different byte sequences can be interpreted as the same transaction, signatures and transaction identifiers may behave unexpectedly.

Common signature families include elliptic-curve schemes such as ECDSA and EdDSA, as well as RSA in broader public-key infrastructure. ECDSA security depends on the difficulty of the elliptic-curve discrete logarithm problem and on correct generation of a unique, unpredictable signing nonce. Reuse or bias in that nonce can reveal the private key. Deterministic nonce generation reduces dependence on weak randomness but does not eliminate all implementation risks.

Multisignature arrangements require several designated keys to authorize an operation, such as two of three trustees approving a transfer. Threshold signatures can provide similar policy semantics while presenting a single signature to the outside system. These mechanisms reduce dependence on one individual key but introduce coordination, recovery, and participant-management challenges.

Public-Key Infrastructure and Trust Models

Public-key cryptography answers the question of how a key pair can support authentication, but a system must still determine whether a public key belongs to the claimed entity. Public-key infrastructure (PKI) addresses this through certificates, certificate authorities, registration procedures, policies, and revocation mechanisms.

A digital certificate binds an identity or subject name to a public key and is signed by a certificate authority. A verifier checks the certificate chain, validity period, intended key usage, signature algorithms, and revocation status. Trust may be hierarchical, with a root authority issuing or authorizing intermediate authorities, or distributed through cross-certification and trust stores.

Many blockchains do not use traditional X.509 PKI for ordinary user transactions. Instead, addresses are derived from public keys, and control is demonstrated by a valid signature. This is a form of self-certifying identity: possession of the corresponding private key is central, but the real-world identity behind the key may remain unknown. Enterprise and permissioned networks frequently add organizational certificates to regulate membership and transaction rights.

The distinction between authentication and authorization is important. A certificate may authenticate a device or organization, while a smart-contract policy decides whether that authenticated party may invoke a particular function. Certificate compromise, weak identity vetting, incorrect trust-store configuration, and failure to revoke compromised credentials are common PKI risks.

Commitments: Hiding and Binding Information

A commitment scheme allows one party to commit to a value without revealing it immediately, while preventing that party from changing the value later. It has two central properties. Hiding means that the commitment should not reveal the committed value before the reveal phase. Binding means that the committer should not be able to open the same commitment as two different values.

A simple hash commitment is C = H(m || r), where m is the message and r is a random, sufficiently long nonce. The committer publishes C and later reveals m and r. The verifier recomputes the hash. The random nonce is essential when m has a small or guessable domain; without it, an observer may enumerate possible values and identify the commitment.

Commitments support sealed-bid auctions, voting protocols, randomness generation, state channels, payment channels, and privacy-preserving transaction designs. A commitment can establish that a choice existed at a particular time without disclosing the choice. More advanced commitments, including Pedersen commitments, can provide useful algebraic properties and computational hiding under discrete-logarithm assumptions.

Commitments do not automatically provide identity, availability, or truth. A participant may commit to an invalid value, fail to reveal it, or reveal it after a deadline. Protocols therefore need well-defined phases, deposits or penalties, timeout rules, and verification procedures.

Key Management as a Systems Discipline

The private key is often the most consequential secret in a blockchain system. A sound cryptographic algorithm cannot protect an account if its private key is copied, guessed, exposed in logs, or destroyed without recovery planning. Key management covers the full lifecycle: generation, distribution, storage, use, backup, rotation, revocation, recovery, and destruction.

Keys should be generated using approved cryptographic random-number generators, preferably within hardware security modules (HSMs), secure elements, or carefully designed wallet devices. Seed phrases are human-readable representations of wallet entropy and must be treated as high-value secrets. Photographing, emailing, or entering a seed into an untrusted website defeats the security model.

Hot wallets keep signing capability connected to online systems and are convenient but exposed to malware and remote compromise. Cold storage separates keys from routine network access and reduces exposure, although it creates operational risks involving physical security, backup, availability, and authorized recovery. Hardware wallets can isolate signing operations, but users must verify transaction details on a trusted display and protect device recovery material.

Organizational custody should use separation of duties, least privilege, dual control, transaction limits, allowlists, approval workflows, and comprehensive audit records. Key shards or distributed key-generation techniques may reduce the risk of a single backup becoming sufficient for theft. They also require carefully tested recovery procedures and governance for participant loss.

Rotation is not always straightforward in blockchain systems because an address may be publicly associated with a history of transactions. Systems should distinguish signing-key rotation, address migration, certificate renewal, and emergency revocation. Smart contracts and account systems need explicit mechanisms for changing authorized keys; otherwise, compromise may be irreversible.

Threats and Failure Modes

Cryptographic attacks may target the mathematics, the protocol, or the implementation. Brute-force attacks exploit inadequate key lengths. Collision attacks target hash commitments. Replay attacks reuse a valid transaction in an unintended context. Chosen-message attacks test whether a signature scheme remains secure when an adversary can obtain signatures on selected messages.

Implementation failures are often more realistic than attacks on the underlying mathematics. Weak randomness, nonce reuse, side-channel leakage, faulty serialization, incorrect signature verification, and insecure dependency updates can compromise a system. Timing, power consumption, electromagnetic emissions, and memory-access patterns may reveal secret-dependent behavior. Constant-time implementations and defensive coding are therefore important for high-value cryptographic operations.

Key compromise, insider abuse, phishing, supply-chain attacks, and malicious wallet software are operational threats. A public blockchain also creates privacy risks: transaction graphs, timing information, and reused addresses can reveal relationships even when names are absent. Metadata may be more revealing than the encrypted or hashed payload.

Cryptographic agility is the capacity to replace algorithms, parameters, and key types without redesigning the entire system. Protocols that hard-code one algorithm or one address format may become difficult to upgrade. Governance must define who can approve changes, how users migrate, how old signatures are treated, and how historical evidence remains verifiable.

Quantum Risk and Post-Quantum Planning

A sufficiently capable fault-tolerant quantum computer would threaten widely deployed public-key systems based on integer factorization and discrete logarithms through Shor’s algorithm. This includes RSA, finite-field Diffie–Hellman, and elliptic-curve signature systems. An attacker might derive a private key from a public key, especially where the public key has already been exposed on-chain.

Grover’s algorithm offers a quadratic speedup for generic search, reducing the effective security of an n-bit symmetric key or hash preimage problem to roughly n/2 bits under simplified assumptions. Increasing symmetric key and hash-output sizes can therefore provide a substantial defense margin. Quantum effects on collision search are more nuanced, but larger digest sizes remain prudent for long-lived commitments.

Post-quantum cryptography seeks security against quantum-capable adversaries using problems such as structured lattices, error-correcting codes, hash-based signatures, and other constructions. Migration is difficult in blockchain systems because signatures affect transaction size, fees, address formats, validation costs, hardware support, and consensus rules. A sensible strategy is inventorying all cryptographic dependencies, identifying long-lived secrets and exposed public keys, selecting upgrade paths, and supporting algorithm agility before an emergency occurs.

The harvest-now, decrypt-later threat primarily affects confidential data that an adversary can record today and decrypt in the future. Public blockchains also face a future forgery threat if exposed public keys become computationally vulnerable. Organizations should avoid placing sensitive personal data directly on immutable ledgers and should plan migration for accounts using vulnerable signature schemes.

Applied Case: Securing a Consortium Supply-Chain Ledger

Background

A consortium of manufacturers, logistics providers, and retailers establishes a permissioned blockchain to record custody events for high-value medical equipment. Each event includes an asset identifier, location, timestamp, responsible organization, and a reference to supporting documents stored off-chain.

Situation and Problem

The consortium initially proposes storing scanned documents on-chain and allowing each warehouse employee to use a shared signing key. An internal review identifies three problems: the ledger would replicate sensitive information unnecessarily, individual accountability would be impossible, and compromise of the shared key could authorize fraudulent custody transfers.

Analysis

The design requires integrity, organizational authentication, authorization, privacy, and recoverability. Hashing documents and storing only their content identifiers can demonstrate that an off-chain document has not changed, but access controls must protect the document itself. A consortium PKI can authenticate member organizations and devices, while role-based authorization can restrict which operations each role may perform. Individual signatures are needed for accountability, and a key-recovery procedure is needed for employee departure or device loss.

Approach and Solution

The consortium adopts canonical event encoding and stores a hash of each document in the ledger. A Merkle tree periodically commits to batches of custody events, allowing auditors to verify selected records efficiently. Each employee receives an organizational identity certificate and a device-bound signing key generated in a protected environment. The ledger records the employee identity, organization, event type, asset identifier, nonce, and timestamp within the signed payload.

High-risk actions, such as changing the registered owner or releasing equipment for export, require approval from two authorized roles. Certificate authorities maintain a trust hierarchy, and compromised credentials are revoked through a defined process. Key backups are encrypted and split under organizational control. Smart-contract rules reject stale nonces, unauthorized transitions, malformed encodings, and events that violate the asset’s state machine.

Outcome

Auditors can verify document integrity without receiving the documents, and custody events are attributable to individual authorized users. The system still depends on accurate physical scanning, reliable identity administration, and timely revocation. The blockchain proves what was recorded and signed; it does not prove that a warehouse employee entered a truthful location or that the equipment was physically present.

Learning Points

The case illustrates that cryptographic design is inseparable from operational governance. Hashes protect references, signatures support accountability, PKI manages membership, threshold approval limits unilateral abuse, and key management determines whether these controls work in practice. It also demonstrates the importance of minimizing sensitive on-chain data and specifying canonical formats before deployment.

Governance, Ethics, and Professional Practice

Cryptographic controls distribute power. Whoever controls a signing key may control assets, records, or organizational actions. Consequently, key custody must be governed through documented responsibilities, conflict-of-interest controls, incident reporting, and independent review. Recovery mechanisms should not quietly create an administrator capable of bypassing all authorization rules.

Immutability creates ethical and regulatory tensions. Personal data, unlawful content, inaccurate records, and records subject to correction may conflict with data-protection, retention, and right-to-erasure requirements. Data minimization, off-chain storage, encryption, redactable architectures where legally appropriate, and carefully designed identifiers are preferable to placing raw personal information on a public ledger.

Professionals should communicate assumptions honestly. A “military-grade” label is not a security analysis. Claims should identify the algorithm, parameter size, threat model, implementation boundaries, audit evidence, and recovery assumptions. Cryptographic standards, certificate policies, and incident procedures should be reviewed as living governance documents rather than treated as permanent technical facts.

Best-Practice Design Principles

A blockchain cryptographic design should begin with a threat model and a clear statement of what must be protected. Use standardized, reviewed primitives rather than inventing algorithms. Separate hashing, encryption, signing, and key derivation according to their purposes. Specify canonical serialization, domain separation, replay protection, and algorithm identifiers.

Generate keys with strong randomness and protect them throughout their lifecycle. Prefer hardware-backed or threshold controls for high-value assets. Apply least privilege, separation of duties, approval thresholds, monitoring, and tested recovery. Keep sensitive data off-chain unless there is a compelling and reviewed reason to replicate it.

Test both normal and adversarial cases: malformed signatures, duplicate transactions, key loss, clock differences, certificate expiry, revoked identities, serialization ambiguities, and attempted replay. Conduct independent code review and security testing. Finally, design for cryptographic agility and begin post-quantum migration planning before vulnerable algorithms become an emergency liability.

Current Developments and Emerging Directions

Modern blockchain systems increasingly combine Merkle commitments with succinct proofs, rollups, verifiable databases, and light-client protocols. These approaches reduce the amount of data a verifier must download while preserving evidence about computation or state. Polynomial commitments and zero-knowledge proof systems can demonstrate that a computation was performed correctly without revealing all inputs, although they introduce new assumptions, implementation complexity, and performance costs.

Threshold signatures, multiparty computation, remote attestation, confidential hardware, and post-quantum signature research are also shaping enterprise custody and decentralized applications. Their adoption should be evaluated through measurable requirements—verification cost, proof size, failure recovery, trust assumptions, and upgrade mechanisms—rather than through novelty alone.

Chapter Summary

Cryptographic foundations enable blockchain integrity and authorization but do not replace sound governance or trustworthy operations. Hash functions provide fixed-length integrity commitments with preimage, second-preimage, and collision-resistance properties. Merkle trees commit efficiently to collections and enable logarithmic verification proofs, subject to canonical encoding and trusted roots. Digital signatures authenticate authorization, while PKI binds public keys to identities in managed environments. Commitment schemes support delayed disclosure through hiding and binding properties.

Key management is a lifecycle discipline involving generation, storage, use, recovery, rotation, and revocation. Threats frequently arise from weak randomness, nonce reuse, serialization errors, side channels, compromised devices, and poor operational controls. Quantum computing threatens many current public-key schemes and requires algorithm agility and migration planning. Effective blockchain security therefore depends on aligning mathematical assumptions, protocol design, implementation quality, organizational controls, privacy obligations, and governance.

Key Terms

Cryptographic hash function: A deterministic function that maps arbitrary-length input to a fixed-length digest and is designed to resist specified attacks.

Preimage resistance: The difficulty of finding an input that produces a given hash output.

Second-preimage resistance: The difficulty of finding a different input with the same hash as a specified input.

Collision resistance: The difficulty of finding any two distinct inputs with the same hash output.

Merkle tree: A hash-based tree that commits to a collection through a single root hash.

Merkle proof: A set of sibling hashes used to verify membership in a Merkle tree.

Digital signature: A private-key-generated value that can be verified with a corresponding public key.

Replay attack: Reuse of a valid message or transaction in an unintended context.

Public-key infrastructure: Certificates, authorities, policies, and procedures that manage public-key trust.

Certificate authority: An entity that signs certificates binding public keys to identities or subjects.

Commitment: A cryptographic value that fixes a statement while optionally hiding it until later revelation.

Hiding: The property that a commitment does not reveal its underlying value before opening.

Binding: The property that a commitment cannot feasibly be opened to two different values.

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

Key management: The controlled lifecycle of cryptographic keys from generation through destruction.

Threshold signature: A signature arrangement requiring a specified number of participants to authorize an action.

Cryptographic agility: The ability to replace cryptographic algorithms or parameters without fundamental redesign.

Post-quantum cryptography: Cryptography designed to resist adversaries equipped with sufficiently capable quantum computers.

Domain separation: Use of distinct encodings or prefixes to prevent confusion between cryptographic contexts.

Review Questions

Short Answer Questions

1. Distinguish preimage resistance from collision resistance.

2. What information does a Merkle proof provide?

3. Why is a digital signature not the same as encryption?

4. State the hiding and binding properties of a commitment scheme.

5. Why is key management considered a lifecycle discipline?

Long Answer Questions

1. Explain how hashes and previous-block references contribute to blockchain tamper evidence, including the limits of this protection.

2. Describe the construction, verification, and practical design issues of a Merkle tree.

3. Compare self-certifying blockchain identities with certificate-based PKI.

4. Discuss the principal operational and implementation threats to digital-signature systems.

5. Explain quantum risks to elliptic-curve cryptography and outline a migration strategy.

Analytical / Application Questions

1. A system stores unsalted SHA-256 hashes of four-digit PINs. Analyse the weakness and recommend a suitable design.

2. Design a custody-control policy for a blockchain treasury using multisignature or threshold authorization, including recovery and revocation.

3. A public ledger contains hashes of identifiable medical records. Evaluate whether this design protects privacy and propose alternatives.

22. Multiple Choice Questions with Answers

Question 1

Which property makes it difficult to find two different messages with the same hash digest?

A. Preimage resistance

B. Collision resistance

C. Forward secrecy

D. Key indistinguishability

Correct Answer: B. Collision resistance

Question 2

What does a Merkle proof normally establish?

A. That a transaction is included under a particular trusted root

B. That a private key has never been copied

C. That a transaction is legally valid

D. That a transaction is absent from a ledger

Correct Answer: A. That a transaction is included under a particular trusted root

Question 3

Why must a commitment to a low-entropy value include a random nonce?

A. To make the hash reversible

B. To allow anyone to change the value later

C. To prevent simple enumeration of possible values

D. To eliminate the need for verification

Correct Answer: C. To prevent simple enumeration of possible values

Question 4

A digital signature primarily provides evidence of which combination?

A. Confidentiality and compression

B. Integrity and authorization by the private-key holder

C. Anonymity and data deletion

D. Availability and physical presence

Correct Answer: B. Integrity and authorization by the private-key holder

Question 5

What is a major danger of reusing an ECDSA signing nonce?

A. It can reveal the private key

B. It makes the public key secret

C. It prevents hash collisions

D. It automatically revokes the certificate

Correct Answer: A. It can reveal the private key

Question 6

What is the principal purpose of a certificate authority in PKI?

A. To store every user’s private key

B. To bind a public key to an identity through a signed certificate

C. To encrypt all blockchain transactions

D. To generate consensus blocks

Correct Answer: B. To bind a public key to an identity through a signed certificate

Question 7

Which control most directly reduces the risk that one compromised employee key can authorize a high-value transfer?

A. Using a shorter hash digest

B. Publishing the private key

C. Requiring threshold or multisignature approval

D. Removing transaction nonces

Correct Answer: C. Requiring threshold or multisignature approval

Question 8

Why is hashing personal information not automatically equivalent to anonymization?

A. Hashes are always reversible

B. The hash may still be linkable to an identifiable person

C. Hashes provide confidentiality by definition

D. Personal information cannot be encoded

Correct Answer: B. The hash may still be linkable to an identifiable person

Question 9

Which current public-key technology is most directly threatened by Shor’s algorithm?

A. Elliptic-curve signatures

B. Password hashing with memory cost

C. Merkle-tree ordering

D. Randomized document encoding

Correct Answer: A. Elliptic-curve signatures

Question 10

What is cryptographic agility intended to support?

A. Replacing algorithms or parameters without redesigning the entire system

B. Allowing signatures to be altered after publication

C. Making all ledger data confidential

D. Removing the need for key recovery

Correct Answer: A. Replacing algorithms or parameters without redesigning the entire system