Cryptographic Foundations

Introduction

Blockchain systems rely on cryptography to provide integrity, authentication, ownership, and efficient verification without requiring every participant to trust a central administrator. Cryptography does not make a blockchain automatically secure. Rather, it supplies carefully designed mechanisms that allow a distributed network to detect alteration, prove control of assets, authenticate messages, and summarize large collections of data.

This chapter introduces the cryptographic foundations most commonly used in blockchain systems: cryptographic hash functions, public-key cryptography, digital signatures, Merkle trees, blockchain addresses, and key management. The emphasis is on concepts and professional application rather than advanced mathematics.

Learning Objectives

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

1. Explain the purpose and security properties of cryptographic hash functions.
2. Distinguish symmetric encryption, public-key cryptography, and digital signatures.
3. Describe how digital signatures authenticate blockchain transactions.
4. Construct and interpret a simple Merkle tree.
5. Explain the relationship between private keys, public keys, and addresses.
6. Identify common key-management risks and recommend suitable controls.
7. Evaluate practical and governance implications of cryptographic design choices.

1. Cryptography in Blockchain Systems

Cryptography is the study and application of techniques for protecting information and communications. In blockchain networks, its main purposes include:

• Integrity: detecting whether data has been changed.
• Authentication: establishing that a message was produced by a particular key holder.
• Non-repudiation: providing evidence that a valid key was used to authorize a message, although legal non-repudiation depends on wider evidence and law.
• Ownership control: allowing the holder of a private key to authorize transactions involving associated assets.
• Efficient verification: enabling a participant to verify a claim without downloading or inspecting all underlying data.

A blockchain normally does not store private keys. A private key is kept by a user or a key-management system. The blockchain stores public information, such as public keys, addresses, signatures, transaction data, and hashes.

Cryptographic protection depends on assumptions. For example, a signature scheme is secure only if the private key remains secret, the algorithm is correctly implemented, random values are generated properly where required, and the underlying mathematical problem remains computationally difficult.

2. Cryptographic Hash Functions

A cryptographic hash function maps an input of arbitrary length to a fixed-length output called a hash, digest, or message digest. In abstract form:

Here, m is the input message, H is the hash function, and h is the fixed-length digest. The output length is determined by the algorithm, not by the size of the input.

For example, SHA-256 produces a 256-bit digest. A digest of 256 bits can be represented as 64 hexadecimal characters because each hexadecimal character represents 4 bits. The digest is not an encrypted version of the input and normally cannot be reversed to recover the original message.

2.1 Important Properties

A suitable cryptographic hash function has the following properties:

• Determinism: the same input always produces the same output.
• Efficient computation: the digest can be calculated quickly for a legitimate input.
• Preimage resistance: given a digest, it should be computationally infeasible to find an input that produces it.
• Second-preimage resistance: given an input, it should be computationally infeasible to find a different input with the same digest.
• Collision resistance: it should be computationally infeasible to find any two different inputs with the same digest.
• Avalanche effect: a small change in the input should produce a substantially different digest.

A hash function is not collision-proof in the mathematical sense. If the input space is larger than the finite output space, collisions must exist. Security means that finding a useful collision should be infeasible with available resources.

2.2 Hashes in Blockchains

Hashes are used in several ways:

1. Block linking: a block commonly contains a hash of the previous block. Changing an earlier block changes its hash and breaks the subsequent link.
2. Transaction identification: a transaction hash provides a compact identifier.
3. Merkle trees: transaction hashes are combined into a root hash.
4. Proof-of-work: some systems require miners to search for a block-header hash meeting a specified condition.
5. Data integrity: a hash can show whether a document or record has changed.

A hash alone does not prove who created data. Anyone can calculate a hash of a public message. Authentication requires a digital signature or another authenticated mechanism.

2.3 Hashing Is Not Encryption

Encryption is designed to be reversible by an authorized party using a key. Hashing is designed as a one-way integrity and identification mechanism. Confusing these functions leads to poor system design. For example, storing a password as a plain hash may still be unsafe if attackers can guess common passwords rapidly. Password systems should use a slow, memory-hard password-hashing scheme with a unique salt, rather than a fast general-purpose blockchain hash.

3. Symmetric and Public-Key Cryptography

3.1 Symmetric Cryptography

Symmetric cryptography uses the same secret key to encrypt and decrypt data. It is generally efficient and appropriate for protecting large volumes of confidential information. Its main challenge is key distribution: communicating the shared secret securely can be difficult when parties have not previously established trust.

Symmetric encryption is not normally the primary mechanism for authorizing public blockchain transactions. Blockchains need a way for anyone to verify authorization without knowing a shared secret. That requirement leads to public-key cryptography.

3.2 Public-Key Cryptography

Public-key cryptography uses a mathematically related key pair:

• The private key is secret and used to create signatures or, in some systems, decrypt information.
• The public key may be shared and is used to verify signatures or, in some systems, encrypt information.

The relationship can be represented as:

Here, sk is the private or secret key, pk is the public key, and KeyGen is a secure key-generation process. The exact mathematical relationship depends on the cryptographic scheme.

Blockchain systems commonly use elliptic-curve signature schemes. The security does not come from hiding the public key. It comes from the computational difficulty of deriving the private key from the public key and from forging a valid signature without the private key.

Public-key cryptography has two distinct uses:

Many blockchains primarily use public-key cryptography for signatures rather than for encrypting transaction data. Transactions are often intentionally transparent.

4. Digital Signatures

A digital signature is a cryptographic value attached to a message. It allows a verifier to test whether the message was authorized by the holder of a corresponding private key and whether the message has been altered.

A simplified signature process is:

Verification is represented as:

Here, m is the message, sk is the private key, pk is the public key, and σ is the signature. A valid result means that the signature is mathematically consistent with the message and public key, subject to the scheme's assumptions.

In practice, the signing algorithm often signs a hash or a carefully encoded representation of the transaction rather than an unlimited raw message. The exact encoding is crucial. If two systems interpret the same apparent transaction differently, an attacker may exploit the ambiguity.

4.1 Transaction Authorization

Suppose Alice wants to transfer a digital asset to Bob. A simplified process is:

1. Alice's wallet constructs a transaction containing the recipient, amount, fee, and relevant network data.
2. The transaction is serialized according to the protocol's rules.
3. Alice's wallet uses her private key to create a signature.
4. The transaction and signature are broadcast.
5. Network nodes derive or receive the relevant public key and verify the signature.
6. If the transaction satisfies protocol rules, it may be included in a block.

The signature does not physically move an object from Alice's computer to Bob's computer. Instead, it authorizes a state transition recorded by the blockchain. The protocol determines whether Alice's key is authorized to spend the relevant output or control the relevant account.

4.2 What Signatures Do and Do Not Provide

Digital signatures provide message integrity and cryptographic authentication. They do not automatically provide:

• confidentiality;
• recovery if a private key is lost;
• protection against a user signing a malicious transaction;
• proof that a real-world person, rather than a compromised device, approved the transaction;
• guaranteed legal non-repudiation in every jurisdiction.

A user can sign a transaction that transfers assets to an attacker. If the signature is valid and the protocol accepts the transaction, cryptography may not provide a practical reversal mechanism.

4.3 Signature Malleability and Randomness

Signature schemes must be implemented according to their standards. Some schemes require secure nonces or random values during signing. Reusing or predictably generating such values can reveal the private key. Modern implementations often use deterministic signing procedures or carefully tested secure randomness.

Signature malleability occurs when a valid signature can be modified into another valid representation without changing the transaction's intended meaning. Protocols must define transaction identifiers and signature encoding rules carefully to prevent confusion or exploitation.

5. Merkle Trees

A Merkle tree is a hash-based data structure that summarizes many records with one root hash. It is usually a binary tree. The leaves are hashes of individual records, and each parent is formed by hashing the concatenation of its two child hashes.

For two child digests h_L and h_R, a parent may be calculated as:

Here, ∥ means concatenation. The precise encoding and treatment of odd numbers of leaves are protocol-specific and must not be assumed universally.

5.1 Worked Example

Assume four transactions produce leaf hashes h₁, h₂, h₃, and h₄. The tree is calculated as follows:

The root commits to the ordered set of transactions under the protocol's rules. If one transaction changes, its leaf hash changes, then its parent hash changes, and finally the root changes.

A Merkle proof allows a verifier to establish that a particular transaction belongs to the committed set without receiving every transaction. For a four-leaf tree, the verifier needs the target leaf, its sibling at the first level, and the relevant sibling at the second level, together with left/right position information. The verifier recomputes the path to the root and compares it with the published root.

The proof size grows approximately with the logarithm of the number of leaves. For n leaves in a balanced binary tree, the path generally contains about log₂(n) sibling hashes, although exact details depend on the tree construction.

Figure: A binary Merkle tree summarizes four transaction hashes in one root hash.

5.2 Merkle Trees and Lightweight Verification

A node that knows a trusted block header containing the Merkle root can verify inclusion using a Merkle proof. This supports lightweight clients, although a proof of inclusion does not by itself prove that the transaction is valid, confirmed, unspent, or final. Those additional claims require appropriate protocol evidence and assumptions.

Merkle trees also expose an important limitation: a root hash commits to data but does not make the data available. A verifier needs the transaction and the proof, and must trust the source or network for availability.

6. Keys, Addresses, and Wallets

6.1 Private Keys and Public Keys

A private key is sensitive control information. Whoever can use it may be able to authorize transactions, depending on the blockchain's rules. A public key is derived from the private key and can be shared for verification.

The private key is not a password in the ordinary sense. It is usually a randomly generated numerical value or secret byte sequence with a defined format. It should be generated using a cryptographically secure random-number generator.

6.2 Addresses

A blockchain address is generally an encoded identifier derived from a public key or script. It is not necessarily the public key itself. Address construction may involve hashing, version information, network identifiers, checksums, and a human-readable encoding.

A simplified conceptual relationship is:

This is a conceptual model, not a universal formula. Different blockchain protocols use different address algorithms and encodings. An address can help reduce transcription errors through checksums, but a valid-looking address may still belong to the wrong recipient.

Users should verify the complete destination through a trusted interface. Malware can replace a copied address with an attacker-controlled address while leaving the format apparently valid.

6.3 Wallets

A wallet is primarily a key-management and transaction-signing system, not a container that literally stores coins. The blockchain records balances, outputs, or state associated with addresses or accounts. The wallet stores or controls the credentials needed to authorize transactions and displays blockchain data to the user.

Wallet categories include:

• Custodial wallets: a service controls the keys on behalf of users.
• Non-custodial wallets: the user controls the keys.
• Hot wallets: keys are kept on an internet-connected device.
• Cold wallets: keys are kept offline or in a highly isolated environment.
• Hardware wallets: dedicated devices perform or protect signing operations.
• Multisignature wallets: spending requires signatures from multiple keys.

These categories can overlap. For example, a non-custodial wallet may use a hardware device and multisignature policy.

7. Key Management as a Professional Control

Cryptography cannot compensate for poor key management. Key management includes the entire lifecycle of keys: generation, storage, use, backup, rotation where supported, recovery, revocation or replacement, and destruction.

7.1 Common Risks

• private keys stored in plaintext on an internet-connected computer;
• seed phrases photographed, emailed, or stored in cloud notes;
• weak or reused passwords protecting wallet backups;
• malware changing transaction destinations;
• loss of a device without a tested recovery process;
• exposure of a backup that was assumed to be private;
• unclear authority over organizational wallets;
• signing transactions without independently checking their meaning;
• failure to plan for employee departure, death, or incapacity.

7.2 Recommended Controls

For individuals, good practice includes using a reputable wallet, enabling device security, verifying addresses on a trusted display, keeping recovery material offline, and testing recovery with a small amount before relying on a backup.

For organizations, controls should include documented approval policies, separation of duties, transaction limits, multisignature authorization, hardware security modules or hardware wallets where suitable, secure backups in separate locations, audit logs, incident-response procedures, and periodic recovery exercises.

A recovery phrase is often a human-readable representation of wallet secret material. Anyone who obtains it may gain control of the associated keys. It should never be entered into an unsolicited website or shared with support staff. Legitimate support personnel should not need it.

7.3 Custodial and Non-Custodial Trade-Offs

Custodial services may provide account recovery, professional security, and operational convenience, but they introduce counterparty, regulatory, insolvency, and concentration risks. Non-custodial control reduces dependence on an intermediary but transfers responsibility for key protection and recovery to the user. The appropriate model depends on risk, expertise, legal requirements, transaction volume, and the value at stake.

8. Applied Case: A Small Business Payment Wallet

This is an illustrative case.

Background

A small import business accepts blockchain-based payments from international customers. Initially, one employee keeps the wallet seed phrase in an encrypted file on a laptop. Payments are sent from a single hot wallet, and the employee alone approves transactions.

Problem

The business faces three risks: the laptop may be compromised, the employee may make an address-transcription error, and the company may lose access if the employee leaves. The owner also cannot demonstrate that payments were approved according to company policy.

Analysis

The problem is not a failure of hashing or signature mathematics. It is a governance and key-management weakness. A valid signature from the employee's key could authorize an incorrect or fraudulent payment. Encryption of the file reduces some exposure but does not provide separation of duties or reliable business continuity.

Approach and Solution

The business adopts a policy requiring two of three authorized signers for payments above a defined threshold. Signing keys are held on separate hardware devices by the owner, finance manager, and an external director. A smaller operational wallet is maintained for routine payments with a strict balance limit. Recipient addresses are independently verified through a second communication channel, and payment approvals are recorded.

Encrypted backups of recovery material are stored in physically separate secure locations. The company conducts a controlled recovery test and documents procedures for employee replacement, suspected compromise, and emergency payment suspension where the protocol permits it.

Outcome

The business reduces the chance that one compromised device or dishonest insider can transfer all funds. It also improves auditability and continuity. The arrangement does not eliminate risk: collusion between signers, social engineering, incorrect policy configuration, and protocol-specific vulnerabilities remain possible.

Learning Points

1. Private-key control is equivalent to transaction-authorizing power in many blockchain systems.
2. Multisignature controls can align technical authorization with organizational governance.
3. Address verification is a human and interface-security problem as well as a cryptographic problem.
4. Recovery must be tested, not merely documented.
5. Security controls should reflect the value and operational importance of the assets.

9. Limitations, Ethics, and Governance

Cryptographic systems create technical evidence, but they do not determine whether an action is lawful, ethical, or socially desirable. A blockchain may immutably record a fraudulent or harmful transaction. Privacy is also limited: pseudonymous addresses can often be linked through transaction analysis, exchange records, network data, or external information.

Organizations should consider data-protection obligations before placing personal data or identifying information directly on an immutable ledger. Hashing personal data does not automatically make it anonymous. If the original information is guessable, an attacker may hash likely values and compare the results.

Key recovery creates a governance trade-off. A recovery mechanism may protect users from loss but introduce trusted parties or additional attack surfaces. Conversely, refusing all recovery may preserve autonomy while making accidental loss irreversible.

Quantum computing is a contemporary concern because sufficiently capable quantum computers could weaken some widely used public-key schemes. Hash functions are affected differently and generally require increased security parameters rather than the same type of replacement. Post-quantum cryptography is therefore an active area of standardization and migration planning. Organizations should avoid claiming that any current system is permanently secure against all future computational developments.

10. Best Practices Checklist

• Use standardized, publicly reviewed cryptographic algorithms.
• Never invent a proprietary hash, signature scheme, or key format.
• Use secure random-number generation for keys and protocol-required nonces.
• Keep private keys and recovery material confidential.
• Verify transaction encoding, destination, amount, fee, and network before signing.
• Separate routine operational funds from long-term holdings.
• Use multisignature or equivalent approval controls for organizational assets.
• Maintain secure, geographically separated backups.
• Test recovery procedures periodically.
• Document who is authorized to sign and how authority changes.
• Treat software updates, hardware devices, and signing interfaces as part of the security boundary.
• Remember that a valid signature proves key use, not necessarily informed human consent.

Chapter Summary

Cryptographic foundations enable blockchains to provide integrity, authorization, and efficient verification in an environment where participants may not share a central administrator. Cryptographic hash functions map arbitrary inputs to fixed-length digests and support block linking, transaction identification, proof-of-work, and Merkle trees. A hash is not encryption and does not authenticate its input.

Public-key cryptography uses related private and public keys. In blockchain systems, the private key is used to create a digital signature, while the public key is used to verify it. A valid signature can show that a transaction was authorized by the corresponding key and that the signed message has not changed, but it does not guarantee confidentiality, user understanding, or recovery from key loss.

Merkle trees combine transaction hashes into a root hash. Merkle proofs allow efficient verification that a record belongs to a committed set, although inclusion is not the same as validity, availability, or finality. Addresses are protocol-specific encodings derived from public keys or scripts, while wallets manage keys and create signatures rather than literally storing blockchain assets.

The practical security of a blockchain depends heavily on key management, interface design, organizational controls, and governance. Hardware protection, secure backups, address verification, multisignature policies, separation of duties, and tested recovery procedures are essential professional practices.

Key Terms

Cryptography: Techniques for protecting information and communications.

Cryptographic hash function: A function that maps arbitrary input to a fixed-length digest with security properties such as collision resistance.

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

Collision: A pair of different inputs that produce the same hash output.

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

Public-key cryptography: Cryptography based on mathematically related public and private keys.

Private key: Secret key material used, among other purposes, to authorize transactions by creating signatures.

Public key: Shareable key material used to verify signatures or perform other protocol-defined operations.

Digital signature: A cryptographic value that authenticates a message and detects alteration.

Signature verification: The process of testing a signature against a message and public key.

Serialization: The precise encoding of data into a byte sequence for hashing or signing.

Merkle tree: A hash-based tree that summarizes a collection of records in a root hash.

Merkle root: The top hash of a Merkle tree.

Merkle proof: Evidence, usually a set of sibling hashes, used to verify membership in a Merkle tree.

Address: A protocol-specific encoded identifier associated with a public key, script, or account.

Wallet: A system for managing keys, viewing blockchain state, and signing transactions.

Multisignature: A policy requiring signatures from multiple keys before authorization.

Custodial wallet: A wallet service in which another party controls the private keys.

Non-custodial wallet: A wallet in which the user controls the private keys.

Key management: The processes governing key generation, storage, use, backup, recovery, and destruction.

Review Questions

Short Answer Questions

1. What is the difference between a cryptographic hash and encryption?
2. What roles do private and public keys play in a digital-signature system?
3. Why does changing one transaction usually change a Merkle root?
4. Why is a blockchain address not necessarily the same thing as a public key?
5. State two risks associated with poor private-key management.

Long Answer Questions

1. Explain the properties of a cryptographic hash function and discuss three blockchain uses of hashes.
2. Describe the complete lifecycle of a digitally signed blockchain transaction, from construction to verification.
3. Explain how a Merkle proof permits efficient membership verification and identify its limitations.
4. Compare custodial, non-custodial, hot, cold, hardware, and multisignature wallets.
5. Develop a key-management policy for a small organization holding valuable blockchain assets.

Analytical / Application Questions

1. A company stores its only private key in a cloud document protected by one employee's password. Analyze the threats and propose a layered replacement design.
2. A user verifies that a transaction has a valid signature but later discovers that malware changed the recipient address before signing. Explain why the signature can still be valid and recommend controls.
3. A lightweight client receives a transaction, a Merkle proof, and a block header containing a root hash. What can it conclude, what can it not conclude, and what additional evidence may be required?

Multiple Choice Questions with Answers

Question 1

Which property means that finding an input for a specified hash output should be computationally infeasible?

A. Preimage resistance

B. Determinism

C. Confidentiality

D. Key rotation

Correct Answer: A. Preimage resistance

Question 2

In a typical blockchain digital-signature process, which key creates the signature?

A. The recipient's public key

B. The sender's private key

C. The block's Merkle root

D. A shared network password

Correct Answer: B. The sender's private key

Question 3

What is the primary purpose of a Merkle root?

A. To encrypt every transaction

B. To replace all private keys

C. To summarize a set of records with a hash commitment

D. To identify the physical location of a node

Correct Answer: C. To summarize a set of records with a hash commitment

Question 4

Which statement about a valid digital signature is correct?

A. It automatically makes the transaction confidential

B. It proves that the signer understood the transaction

C. It shows that the message is consistent with the signing key and has not been altered

D. It guarantees that the transaction can be reversed

Correct Answer: C. It shows that the message is consistent with the signing key and has not been altered

Question 5

A wallet is best described as:

A. A physical container in which blockchain coins are stored

B. A system that manages keys and signs transactions

C. A replacement for the blockchain ledger

D. A hashing algorithm

Correct Answer: B. A system that manages keys and signs transactions

Question 6

Which control most directly reduces the risk that one compromised organizational key can authorize a major transfer?

A. Using a longer blockchain address only

B. Using multisignature authorization

C. Publishing the private key

D. Removing transaction records

Correct Answer: B. Using multisignature authorization

Question 7

If one transaction in a Merkle tree changes, what normally happens?

A. Only the unchanged transaction hash changes

B. The affected leaf, its ancestor hashes, and the root change

C. The private keys of all users change

D. The tree becomes encrypted

Correct Answer: B. The affected leaf, its ancestor hashes, and the root change

Question 8

Which statement correctly distinguishes hashing from encryption?

A. Hashing is normally designed as a one-way integrity function, while encryption is designed to be reversible with a key

B. Hashing always requires a public and private key pair

C. Encryption cannot use keys

D. Hashing provides confidentiality by definition

Correct Answer: A. Hashing is normally designed as a one-way integrity function, while encryption is designed to be reversible with a key

Question 9

Why should a recovery phrase be kept confidential?

A. It is only a display label for an address

B. Anyone possessing it may be able to derive or control the associated wallet keys

C. It prevents nodes from calculating block hashes

D. It is needed to verify every public transaction

Correct Answer: B. Anyone possessing it may be able to derive or control the associated wallet keys

Question 10

What can a Merkle proof normally demonstrate when checked against a trusted Merkle root?

A. That a particular record is included in the committed tree

B. That the record was created by a legally identified person

C. That the associated private key has never been exposed

D. That the transaction is automatically final in every blockchain

Correct Answer: A. That a particular record is included in the committed tree