Cryptographic Foundations

Introduction

Blockchain systems do not achieve trust by removing cryptography; they use cryptography to make particular claims verifiable. Hash functions help establish data integrity and organize records. Public-key cryptography supports controlled ownership and authentication. Digital signatures demonstrate that a holder of a private key authorized a message. Merkle trees allow large collections of transactions to be summarized efficiently. Commitments enable a party to bind itself to information without immediately revealing it. Address-generation procedures convert public information into identifiers suitable for blockchain applications.

Cryptography does not, however, prove that information is true, that a private key is controlled by a particular legal person, or that a user will never lose access. It provides security properties under stated assumptions. Sound blockchain engineering therefore requires both cryptographic knowledge and careful key management, protocol design, governance, and operational controls.

Learning Objectives

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

• explain the security goals of confidentiality, integrity, authenticity and non-repudiation;
• distinguish cryptographic hash functions from encryption and digital signatures;
• describe public-key cryptography and elliptic-curve key generation;
• verify the logic and limitations of digital signatures;
• construct and audit a Merkle tree and a Merkle proof;
• explain commitment schemes and address derivation;
• identify implementation, governance, quantum, privacy and key-management limitations.

1. Security Goals and Threat Models

A cryptographic system should begin with a threat model: who may attack, what they can observe or alter, which secrets they may obtain, and what resources they possess. A public blockchain generally assumes that an adversary can read network traffic, submit arbitrary transactions, replay old data, run nodes, and attempt to forge signatures. It does not assume that all nodes are honest.

The principal security goals are:

These goals are distinct. A hash can detect a change but cannot identify the person who made the original data. A signature can authenticate a transaction but normally does not hide its contents. Public blockchains commonly prioritize integrity and verifiability over confidentiality.

2. Cryptographic Hash Functions

A cryptographic hash function maps an input of arbitrary length to a fixed-length output:

Here, m is the message, H is the hash function, and h is the digest. For a hash with an n-bit output, the digest has n bits regardless of message length.

A suitable cryptographic hash function has these properties:

• Determinism: the same input always produces the same digest.
• Preimage resistance: given h, finding any m such that H(m) = h is computationally infeasible.
• Second-preimage resistance: given m₁, finding a different m₂ with the same digest is computationally infeasible.
• Collision resistance: finding any two distinct messages with the same digest is computationally infeasible.
• Avalanche effect: a small input change generally causes a substantially different digest.

For an ideal n-bit hash, a generic preimage attack requires approximately 2ⁿ trials, while a generic collision attack requires approximately 2^n/2 trials because of the birthday effect. These are security estimates, not guarantees; weaknesses in a particular algorithm or implementation can reduce security.

Hashes in blockchain systems

Hashes are used for transaction identifiers, block links, Merkle-tree nodes, proof-of-work puzzles in some networks, and content-addressed storage. If a block header contains the previous block's digest, changing an old block changes its digest and breaks the subsequent link. This creates tamper evidence, but it does not by itself prevent rewriting; consensus and economic or operational controls determine whether an altered history is accepted.

Hashing is not encryption. A hash is not intended to be reversible, and it does not use a decryption key. Hashing a low-entropy secret, such as a short password, may still permit guessing. Password systems therefore use a salted, deliberately expensive password-hashing or key-derivation function rather than a fast general-purpose hash.

3. Public-Key Cryptography

Public-key cryptography uses a mathematically related key pair: a private key and a public key. The private key must remain secret; the public key may be distributed. Depending on the scheme, the pair supports encryption/decryption, key agreement, signatures, or combinations of these functions.

For blockchain ownership, the most important use is signatures. A key-generation algorithm selects a private key d from an allowed secret-key space and computes a public key Q:

In elliptic-curve systems, G is a specified base point and dG means repeated elliptic-curve scalar multiplication, not ordinary multiplication. The operation is easy to perform in the forward direction but designed to make recovering d from Q computationally infeasible under the elliptic-curve discrete-logarithm assumption. The exact permitted range of d, curve parameters, point encoding and signature algorithm are protocol-specific.

A private key is not an identity. It is evidence that whoever controls the key can produce valid cryptographic operations. Linking a key to a person or organization requires an external process such as identity verification, custody records, certificates or governance rules.

Symmetric and asymmetric cryptography compared

4. Digital Signatures

A digital signature binds a message to a private key. Conceptually, signing and verification are represented as:

where m is the message, d is the private key, Q is the corresponding public key, and σ is the signature. Real schemes usually hash the message internally and apply carefully specified encoding rules. A verifier must use the exact protocol-defined serialization; two visually identical transactions can have different byte representations and therefore different signatures.

A valid signature normally establishes that the signature corresponds to the stated message and public key, assuming the algorithm and key are secure. It does not establish that the transaction is wise, legal, factually accurate or produced voluntarily. It also does not prove that the private key was not stolen. In legal contexts, non-repudiation depends on evidence, custody, applicable law and organizational controls, not on mathematics alone.

Transaction verification sequence

1. Parse the transaction according to the protocol.
2. Check structural rules and required fields.
3. Reconstruct the exact signed message.
4. Derive or obtain the relevant public key.
5. Verify the signature.
6. Check authorization conditions, such as sufficient balance, correct nonce and script rules.
7. Apply consensus and state-transition rules.

A signature is therefore one condition in transaction validity, not the entire validity test.

Signature risks

Private-key compromise permits unauthorized signing. Key loss can make assets inaccessible. Weak random-number generation can expose secrets in some signature schemes. Signature malleability, ambiguous encodings, replay across chains or domains, and failure to bind signatures to a specific transaction context can create protocol vulnerabilities. Modern systems address these risks with deterministic or carefully generated nonces, canonical encodings, domain separation, chain identifiers, hardware protection and multisignature or threshold controls.

5. Merkle Trees

A Merkle tree is a binary hash tree that commits to a collection of leaves. If the leaves are transaction encodings T₁, T₂, ..., T_n, leaf hashes may be computed as:

Internal nodes are formed by hashing the ordered concatenation of two child hashes:

Here, || means unambiguous byte concatenation. The top value is the Merkle root. A protocol must specify leaf prefixes, node prefixes, ordering, treatment of an odd number of leaves, and whether duplicate-last-node behavior is allowed. These details are security-relevant.

Figure: A Merkle tree aggregates transaction leaves into one root.

Merkle proofs

To prove that T₂ is included, a claimant supplies its leaf hash, the hash of its sibling L₁, the sibling branch hash H(L₃ || L₄), and the left/right positions. The verifier recomputes the path to the root. For n leaves in a balanced tree, the proof contains approximately log₂ n sibling hashes, so proof size grows logarithmically rather than linearly. A Merkle proof demonstrates inclusion under a known root; it does not by itself prove that the root belongs to the canonical chain or that the transaction is valid.

6. Commitments

A commitment scheme allows one party to choose a value, publish a commitment, and reveal the value later. It has two central properties:

• Hiding: the commitment does not reveal the value before opening.
• Binding: after committing, the committer cannot successfully open the commitment as two different values.

A simple computational commitment is:

where m is the message and r is a long, unpredictable random nonce. To open the commitment, the committer reveals m and r; the verifier checks the hash. The random nonce is essential when messages come from a small guessable set. Without it, an observer could hash every possible value and identify the commitment.

Commitments support sealed bids, commit–reveal randomness, private voting designs, state channels and privacy-preserving protocols. A hash commitment is not automatically information-theoretically hiding; its hiding strength depends on the secrecy and entropy of r and on the security of H. More advanced commitments, including elliptic-curve and zero-knowledge constructions, may provide different efficiency and composability properties.

7. Address Generation

A blockchain address is usually an encoded representation of a payment identifier, script, public-key hash or other authorization condition. It is not necessarily a public key and should not be assumed to identify a person.

A generic address-generation pipeline is:

1. Generate a cryptographically secure private key.
2. Derive the corresponding public key using the protocol's key algorithm.
3. Apply the specified hash or script construction.
4. Add a version, network or type indicator where required.
5. Encode the resulting bytes using the protocol's address format.
6. Validate the address, including its checksum, before use.

The exact pipeline varies among blockchains. Some use a hash of a public key; others encode scripts, witness programs or account identifiers. A checksum detects many transcription errors but does not make an address secret, prove ownership, or guarantee that funds are recoverable. Reusing addresses can reduce privacy and may expose relationships between transactions. Users should verify network and address type, avoid manually retyping long strings, and retain backups of the underlying signing keys or recovery material.

8. Worked Example: A Small Merkle Proof

Assume a toy hash function produces short labels, not secure cryptographic values. Let the leaf values be:

• L₁ = A, L₂ = B, L₃ = C, L₄ = D;
• P₁ = H(A || B);
• P₂ = H(C || D);
• R = H(P₁ || P₂).

To prove inclusion of leaf B, the prover sends B, sibling A on the left, sibling P₂ on the right, and the direction information. The verifier computes P₁ = H(A || B), then R = H(P₁ || P₂). If the result equals the trusted root R, the leaf is included in that committed tree. The example illustrates the method; the toy labels must not be used for real security.

9. Applied Case: University Credential Verification

Background. A university issues digital certificates to graduates. Employers need to verify certificates without relying on a continuously available central database.

Problem. Paper certificates can be altered, and a public ledger should not disclose students' personal data. The university also needs a revocation process.

Analysis. The certificate can be serialized in a canonical format and signed by the university's institutional private key. A digest or commitment can be anchored on a blockchain. The document itself can be delivered to the graduate, while the chain stores only a minimal commitment. An employer hashes the presented certificate, checks the university signature, compares the digest with the anchored value, and consults the university's revocation status.

Approach. The university uses hardware-backed key storage, role separation, an auditable key-rotation procedure, canonical serialization, certificate expiry and revocation identifiers. If many certificates are issued together, their hashes can be aggregated in a Merkle tree and only the root anchored on-chain. The employer receives a Merkle proof for a particular certificate.

Outcome. Altering a certificate changes its digest and invalidates either the signature or the commitment comparison. The design reduces on-chain personal data, but it does not prove that the university awarded the qualification fairly, prevent fraudulent identity claims by a presenter, or solve key compromise. Governance and identity verification remain necessary.

Learning points. Cryptography protects the relationship between an issuer, a document and a published commitment. It does not replace institutional authority, privacy policy, revocation governance or secure key custody.

10. Limitations, Ethics and Best Practice

Technical limitations

Cryptographic security is conditional on algorithm strength, correct implementation, secure randomness, parameter choices and private-key protection. Hash collisions, signature forgeries and discrete-log attacks may become practical if algorithms weaken or computing technology changes. Quantum algorithms could threaten widely used public-key systems if large-scale fault-tolerant quantum computers become available; hash functions generally experience a reduced effective security level against generic quantum search rather than the same type of total failure. Migration requires crypto-agility and careful address and signature design.

Privacy and governance

Public ledgers are often permanent and globally observable. Even hashed data may be linkable when the original values are guessable or when transaction patterns identify users. Data-minimization, off-chain storage, selective disclosure, zero-knowledge techniques and carefully designed retention policies are important. Immutability can conflict with correction, deletion and data-protection obligations. Organizations should conduct legal and privacy assessments before placing personal data or identifiers on-chain.

Professional practice

Use standardized, reviewed algorithms rather than inventing cryptographic primitives. Use a cryptographically secure random-number generator; protect keys with hardware or threshold custody where risk justifies it; separate test and production keys; define recovery and rotation procedures; use multisignature authorization for high-value operations; domain-separate signatures; canonicalize signed data; validate all encodings; and test failure and compromise scenarios. Address formats and checksums should be implemented with established libraries and independently reviewed.

AI tools can assist with code review, documentation, test generation and threat-model brainstorming, but generated cryptographic code must not be trusted without expert review, test vectors, dependency analysis and formal or independent verification where appropriate. A plausible-looking implementation can contain catastrophic randomness, serialization or validation errors.

Chapter Summary

Cryptographic foundations provide the mechanisms through which blockchain systems make data tampering detectable and authorization verifiable. Hash functions create fixed-size digests and support block links, identifiers and Merkle trees, but they are not encryption and do not establish truth. Public-key cryptography relates a secret private key to a public key; digital signatures authenticate messages under the assumption that the private key remains controlled. Merkle trees compress a collection into a root and permit logarithmic-size inclusion proofs, while commitments bind a party to hidden information until a later reveal. Addresses are protocol-specific encodings of authorization conditions, not identities.

These mechanisms have strict boundaries. They do not solve key loss, key theft, identity assurance, privacy, legal attribution, governance or consensus by themselves. Secure systems therefore combine sound cryptographic algorithms with canonical serialization, secure randomness, key custody, domain separation, privacy-aware design, operational governance and migration planning.

Key Terms

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

Digest: The fixed-length output of a hash function.

Preimage resistance: Difficulty of finding an input that produces a specified digest.

Collision resistance: Difficulty of finding two distinct inputs with the same digest.

Public key: The openly distributable component of an asymmetric key pair.

Private key: The secret value used to sign or perform other authorized operations.

Elliptic-curve scalar multiplication: The operation used to derive a public point from a private scalar and a base point.

Digital signature: A cryptographic value that binds a message to a signing key.

Verification: The process of testing whether a signature is valid for a message and public key.

Non-repudiation: Evidence supporting attribution of a signature, subject to key custody and law.

Merkle tree: A hash tree that summarizes many leaves in a single root.

Merkle root: The top digest committing to the tree's leaves and structure.

Merkle proof: Sibling data and position information used to prove leaf inclusion.

Commitment: A value that binds a later-revealed message while initially concealing it.

Hiding: A commitment property preventing recovery of the committed value before opening.

Binding: A commitment property preventing two different valid openings.

Address: A protocol-defined encoded identifier for a payment or authorization condition.

Domain separation: Including context information so signatures or hashes cannot be misused across domains.

Key custody: Processes and controls for generating, storing, using, recovering and rotating keys.

Review Questions

Short Answer Questions

1. What is the difference between a hash function and encryption?
2. Why must a private key remain secret while a public key can be distributed?
3. What does a Merkle root commit to?
4. State the hiding and binding properties of a commitment.
5. Why is an address not necessarily an identity?

Long Answer Questions

1. Explain how hash functions, block links and consensus work together to provide tamper evidence in a blockchain.
2. Describe the complete lifecycle of a digital signature from key generation through transaction verification.
3. Explain Merkle-tree construction and show why an inclusion proof is logarithmic in the number of leaves.
4. Compare symmetric cryptography, public-key cryptography, hashing and digital signatures by purpose and limitation.
5. Discuss why cryptographic non-repudiation depends on governance and key custody as well as mathematics.

Analytical / Application Questions

1. Design a credential-verification system using signatures, commitments and Merkle proofs while minimizing personal data on-chain. Identify two residual risks.
2. An organization discovers that an employee's signing key may have been copied. Analyze the immediate technical and governance actions required and explain why simply changing the address may be insufficient.
3. A developer proposes storing users' names as unsalted hashes on a public blockchain. Evaluate the privacy risks and recommend a safer design.

Multiple Choice Questions with Answers

Question 1

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

A. Collision resistance

B. Confidentiality

C. Key escrow

D. Address encoding

Correct Answer: A. Collision resistance

Question 2

In a digital-signature system, which item must normally remain secret?

A. The transaction format

B. The public key

C. The private key

D. The verification algorithm

Correct Answer: C. The private key

Question 3

What does a Merkle proof primarily demonstrate?

A. That a user owns a private key

B. That a transaction is included under a specified Merkle root

C. That a block is legally valid

D. That transaction contents are confidential

Correct Answer: B. That a transaction is included under a specified Merkle root

Question 4

For an ideal 256-bit hash, the approximate generic collision-work estimate is:

A. 2^64 trials

B. 2^128 trials

C. 2^256 trials

D. 256 trials

Correct Answer: B. 2^128 trials

Question 5

In the commitment C = H(m || r), what is the main purpose of r?

A. To make the message publicly readable

B. To provide randomness that helps hide a guessable message

C. To replace the hash function

D. To serve as the public key

Correct Answer: B. To provide randomness that helps hide a guessable message

Question 6

Which statement about a blockchain address is most accurate?

A. It is always a person's legal identity

B. It is always identical to a public key

C. It is a protocol-specific encoding of an authorization condition or identifier

D. It is a password used to decrypt blocks

Correct Answer: C. It is a protocol-specific encoding of an authorization condition or identifier

Question 7

If a balanced Merkle tree has n leaves, the number of sibling hashes in a typical inclusion proof grows approximately as:

A. n^2

B. n

C. log₂ n

D. 2^n

Correct Answer: C. log₂ n

Question 8

What does a valid digital signature not prove by itself?

A. That the signature corresponds to the stated message and public key

B. That the private key was used to produce the signature

C. That the transaction is factually true or legally appropriate

D. That an authorized-key condition may be satisfied

Correct Answer: C. That the transaction is factually true or legally appropriate

Question 9

Which practice best reduces cross-context signature misuse?

A. Removing all transaction metadata

B. Domain separation and explicit chain or application identifiers

C. Reusing one address indefinitely

D. Publishing private keys for auditability

Correct Answer: B. Domain separation and explicit chain or application identifiers

Question 10

Why is hashing a short, guessable value without a random salt inadequate for privacy?

A. The hash output has variable length

B. An observer can hash likely values and compare the results

C. Hashes always reveal the private key

D. The blockchain cannot store fixed-length data

Correct Answer: B. An observer can hash likely values and compare the results