3. Cryptography, Digital Identity and Data Integrity

Introduction and Context

Blockchain systems are often described as trust technologies, but their operation depends on carefully designed cryptographic mechanisms. A blockchain does not make data truthful merely by recording it. Rather, cryptography helps participants determine whether data has been altered, whether a transaction was authorized by the holder of a particular key, and whether a recorded history has been changed after publication.

This chapter examines the relationship between cryptography and blockchain architecture. It explains hash functions, Merkle trees, public-key cryptography, digital signatures, addresses, wallets, key management, and decentralized identity. These concepts are especially important for data science professionals because blockchain data is valuable only when its provenance, integrity, authorship, and access conditions can be evaluated.

Cryptographic assurance is not identical to institutional or factual truth. A valid signature proves control of a private key, not that the signer made a wise decision or that the underlying claim is true. Similarly, a hash proves that data matches a particular digital representation, not that the data is accurate. Understanding this distinction is essential when blockchain records are used in finance, supply chains, health, public administration, and analytics.

Learning Objectives

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

1. Explain the purpose and properties of cryptographic hash functions.

2. Describe how Merkle trees support efficient verification of blockchain data.

3. Distinguish symmetric encryption, public-key cryptography, and digital signatures.

4. Explain the relationship among private keys, public keys, addresses, and wallets.

5. Evaluate key-management methods and identify common operational risks.

6. Apply decentralized identity concepts to practical organizational scenarios.

7. Analyse the contribution and limitations of cryptography to data integrity, governance, and trust.

Cryptographic Foundations of Blockchain

Cryptography is the study and application of techniques for protecting information and enabling secure communication. In blockchain systems, its main functions include integrity protection, authentication, authorization, confidentiality in selected applications, and non-repudiation-like evidence. The last concept must be used carefully: digital signatures provide evidence that a private key was used, but legal non-repudiation depends on identity controls, law, and institutional processes as well.

Hash functions

A cryptographic hash function accepts an input of arbitrary length and produces a fixed-length output called a hash, digest, or message digest. If a file, transaction, or block is represented by data x, its digest can be written as:

h = H(x)

A secure hash function is expected to have several properties:

• Determinism: the same input always produces the same output.
• Efficiency: the digest can be computed practically for large inputs.
• Preimage resistance: given a digest, it should be computationally infeasible to find an input producing it.
• Second-preimage resistance: given one input, it should be infeasible to find a different input with the same digest.
• Collision resistance: it should be infeasible to find any two different inputs with the same digest.
• Avalanche effect: a small input change should produce a substantially different digest.

Hashing is not encryption. Encryption is designed to be reversible by an authorized party using a key; hashing is normally a one-way transformation. A hash also does not conceal the original data if the possible inputs are few. For example, hashing a small set of predictable identification numbers without a salt may permit dictionary attacks.

Blockchain protocols use hashes to identify transactions and blocks, link one block to its predecessor, commit to data, and support efficient membership proofs. If a transaction is changed, its hash changes. If that transaction is included in a Merkle tree, the root normally changes as well, creating a detectable inconsistency with the published block header.

Hash pointers and chained records

A hash pointer combines a reference to a previous data object with its hash. A block header commonly contains the hash of the previous block, so each block commits to the preceding history. Altering an earlier block would require recomputing its digest and the dependent links. In consensus systems, this computational or economic burden contributes to tamper resistance, but it does not make alteration mathematically impossible. Security also depends on the consensus mechanism, network assumptions, and the distribution of validating power.

Merkle trees

A Merkle tree is a hierarchical structure used to summarize a collection of transactions. Individual transaction hashes form the leaves. Pairs of hashes are combined and hashed repeatedly until one value, the Merkle root, remains.

For leaves h1 and h2, a parent may be calculated as:

p1 = H(h1 || h2)

where || denotes concatenation. The process continues until the root is obtained. The block header can store the root rather than every transaction. A verifier can then confirm that a transaction belongs to the committed set by checking a Merkle proof: the transaction hash plus the relevant sibling hashes and their left-right ordering.

A Merkle proof is efficient because verification requires a number of hashes approximately proportional to the logarithm of the number of transactions, rather than retrieving the complete transaction set. This supports light clients and resource-constrained devices. However, a proof establishes inclusion in a committed data structure; it does not by itself prove that the transaction was valid under every business or legal rule.

Merkle trees also illustrate an important analytical distinction. A root commits to a collection and its arrangement, but it does not disclose the underlying records. Nevertheless, if transaction contents are predictable or publicly available elsewhere, hashes may be linkable to those contents. Hashing therefore supports integrity, not automatic privacy.

Public-Key Cryptography and Digital Signatures

Symmetric cryptography uses one shared secret key for encryption and decryption. It is efficient for high-volume confidential communication, but securely distributing the shared key is difficult when participants have no prior relationship. Public-key cryptography uses a mathematically related key pair: a private key that must remain secret and a public key that may be shared.

In a simplified signature model, a signer uses a private key to generate a signature over a message or its hash. A verifier uses the corresponding public key to test whether the signature is valid. The process can be represented as:

signature = Sign(private key, message)

valid = Verify(public key, message, signature)

A valid signature generally demonstrates three things: the message has not changed since signing, the signature corresponds to the relevant public key, and the signer controlled the associated private key at the time of signing. It does not prove that the private key was not stolen, that the signer understood the transaction, or that the data itself is factually correct.

Blockchain transactions are commonly authorized through digital signatures. A user constructs a transaction, signs it locally, and broadcasts it. Network nodes verify the signature against the public key or an address-derived representation before accepting the transaction under protocol rules. The private key is therefore an authorization instrument. Possession or control of it may provide the ability to transfer digital assets or invoke smart-contract functions.

Public-key cryptography can also support encryption. A sender may encrypt data using a recipient’s public key, while the recipient decrypts it using a private key. Many blockchain systems do not encrypt all transaction data because network validation requires broad visibility. Confidentiality must therefore be designed separately through channels, encryption layers, permissioned access, zero-knowledge techniques, or off-chain storage.

From Keys to Addresses and Wallets

A private key is a secret value generated with sufficient randomness. A public key is derived from it through a cryptographic operation. An address is usually a shorter, encoded identifier derived from a public key or a related script. The exact construction varies across blockchain platforms. An address should not be assumed to be a universal identity; it is generally an identifier for receiving assets or specifying authorization conditions.

This distinction matters because addresses may be generated in large numbers, may be used pseudonymously, and may not directly reveal a legal person. Transaction patterns, exchange records, network metadata, and external datasets can nevertheless make addresses linkable to individuals or organizations. Pseudonymity is therefore different from anonymity.

A wallet is best understood as a key-management system, not as a container holding coins. The assets are represented by records or state maintained by the blockchain network; the wallet stores, derives, protects, and uses credentials that authorize actions. Wallets may be:

• Custodial, where a service controls keys on behalf of users.
• Non-custodial, where users control their own keys.
• Hot, meaning connected to network-accessible software or devices.
• Cold, meaning kept offline or otherwise isolated from routine online use.
• Hardware-based, using a dedicated device to protect signing operations.
• Multisignature, requiring several keys or approvals for authorization.

Hierarchical deterministic wallets derive many addresses from a single master secret and a structured derivation process. A recovery phrase may encode or represent the wallet’s root secret. Its compromise can expose many derived accounts, while its loss may make recovery impossible unless a sound backup or recovery arrangement exists.

Key Management as a Governance Problem

Cryptographic algorithms can be strong while an organization remains insecure because of poor key management. Key management includes generation, storage, use, backup, rotation, revocation, recovery, destruction, and audit. It is simultaneously a technical, operational, legal, and governance concern.

Important controls include generating keys with a trustworthy source of randomness; restricting access according to role; separating duties; using hardware security modules or protected hardware where appropriate; requiring multiple approvals for high-value transactions; maintaining tamper-evident audit logs; and testing recovery procedures. Backups must be protected as carefully as active keys. An encrypted backup with a lost decryption secret is not a practical recovery plan.

Organizations should distinguish between key compromise and key loss. Compromise may require rapid revocation, asset transfer, credential replacement, or incident response. Loss may make authorized recovery impossible. In public blockchain environments, administrators often cannot simply reset a private key through a central help desk. This changes the operational meaning of responsibility and requires explicit procedures before deployment.

Multisignature arrangements reduce dependence on one individual or device. For example, an organization may require any three of five authorized signers to approve a treasury transfer. This improves resilience and accountability, although it introduces coordination complexity, signer-availability risks, and the need to manage policy changes.

Decentralized Identity

Traditional digital identity systems commonly rely on an identity provider that registers users, authenticates them, and issues credentials. Decentralized identity seeks to give individuals or organizations greater control over identifiers and verifiable credentials while reducing unnecessary dependence on a single intermediary.

A decentralized identity ecosystem commonly includes:

• a decentralized identifier (DID), which is a persistent identifier designed to be controlled without necessarily depending on a central registration authority;
• a DID document or equivalent metadata describing verification methods and service endpoints;
• an issuer, which creates a credential;
• a holder, who stores and presents the credential; and
• a verifier, who checks its authenticity and relevant claims.

A verifiable credential may state that a person has a qualification, that an organization holds a licence, or that a device belongs to a certified product line. The issuer signs the credential. The holder presents it to a verifier, who checks the issuer’s key, the credential’s integrity, its validity period, and possibly its revocation status.

The principle of selective disclosure is important. A verifier needing to establish that a customer is over a legal age should not necessarily receive the customer’s complete birth date or identity record. Zero-knowledge proofs and privacy-preserving credential designs can allow a claim to be verified without revealing all underlying information. These approaches reduce data exposure but add complexity and do not eliminate the need for trustworthy issuers and sound governance.

Decentralized identity does not mean that identity becomes ownerless or automatically trustworthy. Questions remain about who issues credentials, how keys are recovered, how fraudulent issuers are recognized, how credentials are revoked, and how disputes are resolved. Identity is a socio-technical institution, not merely a cryptographic object.

Data Integrity, Provenance and Oracle Dependence

Data integrity has at least three dimensions: the data has not been altered, the data came from the claimed source, and the data was valid when collected or recorded. Blockchain cryptography strongly supports the first dimension and can support the second when signatures and trusted credentials are used. It cannot independently guarantee that a sensor was calibrated, that a human entered correct information, or that an oracle supplied truthful external data.

A supply-chain record, for example, may be signed and immutably recorded while containing a false temperature reading. The blockchain preserves the submitted claim; it does not automatically validate the physical event. Effective systems combine cryptographic controls with sensor security, process controls, independent audits, access governance, and exception handling.

For data science, provenance metadata can be valuable. Hashes can identify the exact version of a dataset, model, or feature extract used in an analysis. Signed manifests can record who approved a dataset, when it was published, and which transformation pipeline generated a result. Such mechanisms can improve reproducibility and auditability, but they should not be confused with statistical validity or freedom from bias.

Applied Case: Verifiable Credentials for Professional Certification

Background

The following is an illustrative case. A professional education consortium wants employers to verify postgraduate certificates without relying on manual emails, paper documents, or a single central verification portal.

Situation and problem

Paper certificates are easily altered, while centralized portals create operational dependency and may expose more personal information than necessary. Graduates also need to present credentials to multiple employers and institutions. The consortium requires a system that supports authenticity, privacy, revocation, and continuity if one participating institution changes its technology platform.

Analysis

The consortium identifies four relevant trust questions. First, did an approved institution issue the credential? Second, has the credential been modified? Third, is it still valid? Fourth, can an employer verify the relevant claim without receiving unnecessary personal data? Hashing can protect the integrity of a credential representation, while digital signatures can bind the credential to an issuer’s key. A DID or equivalent identifier can provide a discoverable verification method. A revocation mechanism is still required because a valid signature does not mean that the credential remains current.

Approach and solution

Each institution receives an organizational signing key protected through controlled hardware and role-based procedures. After a student completes a programme, the institution issues a digitally signed credential to the student’s wallet. The credential contains the qualification, issuing institution, date, and a minimal set of identity attributes. A registry or distributed publication mechanism makes issuer verification information and revocation status available.

When applying for employment, the graduate presents the credential or a selective disclosure proof. The employer verifies the signature, checks the issuer’s status, validates the credential’s period of validity, and confirms that it has not been revoked. The employer does not need to store a complete copy if its legal and operational requirements can be met through a minimal verification record.

Outcome

The arrangement reduces dependence on manual verification and improves portability. It also makes key governance visible: institutions must secure signing keys, define credential correction procedures, and establish rules for revoked or disputed awards. Students retain responsibility for protecting wallet keys and recovery materials.

Learning points

The case demonstrates that cryptography supports, but does not replace, institutional governance. A signature establishes origin relative to a key; it does not establish that an institution was legitimate unless governance mechanisms identify legitimate issuers. Privacy requires deliberate minimization and selective disclosure. Finally, recovery and revocation must be designed at the beginning rather than added after deployment.

Risks, Limitations and Common Mistakes

A frequent mistake is treating immutability as proof of truth. Blockchain records may be permanent, but inaccurate input remains inaccurate. Another mistake is publishing personal data because it is technically possible. Permanent or widely replicated data can create privacy, legal, and reputational risks.

Key loss and theft are among the most serious operational risks. Phishing, malicious software, insider abuse, insecure backups, weak randomness, and exposed recovery phrases can all defeat otherwise strong cryptography. Smart contracts may also mishandle signatures through replay attacks, incorrect nonce management, poor domain separation, or flawed authorization logic.

Hash collisions are usually discussed abstractly, but implementation errors can be more immediate: ambiguous serialization, inconsistent character encoding, omitted fields, or hashing a representation different from the one users believe they approved. Systems should specify canonical formats and test them across implementations.

Address reuse can weaken privacy by making transactions easier to link. At the same time, excessive address generation can complicate accounting and compliance. Organizations must balance privacy, traceability, usability, and regulatory obligations.

Cryptographic algorithms and parameters may become unsuitable as computing capabilities and attack methods evolve. Migration planning, algorithm agility, long-term signatures, and post-quantum research are therefore relevant to systems expected to preserve evidence for many years.

Ethical, Regulatory and Professional Considerations

Identity and transaction data can reveal associations, financial behaviour, location, health information, and professional activity. Data minimization, purpose limitation, access control, retention policies, and privacy impact assessments should guide system design. Storing a hash on a public ledger does not guarantee that the associated information is anonymous; linkage and inference may remain possible.

Professionals must also consider accessibility and unequal technical capability. A self-custody model may empower some users while excluding those unable to manage complex recovery procedures. Custodial services may improve usability but introduce concentration of power and institutional failure risks. Governance should address complaint handling, recovery, fraud reporting, credential correction, and accountability.

In regulated settings, blockchain records must be assessed alongside evidence requirements, electronic-signature law, financial controls, data-protection obligations, and sector-specific rules. The legal effect of a cryptographic signature depends on jurisdiction and context. Technical design should therefore involve legal, compliance, security, and domain experts rather than treating cryptography as a substitute for governance.

Current Developments and Best Practices

Current work in the field includes decentralized identity standards, verifiable credentials, selective disclosure, zero-knowledge proofs, threshold signatures, secure multiparty computation, confidential computing, and post-quantum cryptography. These technologies aim to reduce data exposure, distribute trust, or prepare systems for changing threat models. Adoption should be based on clearly defined requirements rather than technological novelty.

A practical design discipline includes the following principles:

1. Define the trust and threat model before selecting a cryptographic mechanism.

2. Keep private keys off public networks and minimize their exposure during signing.

3. Use reviewed, standards-based cryptographic libraries rather than inventing algorithms.

4. Separate identity claims, authorization credentials, and asset addresses.

5. Store minimal personal data on-chain and place sensitive data in controlled systems when appropriate.

6. Design backup, recovery, rotation, revocation, and incident response procedures in advance.

7. Use multisignature or threshold controls for critical organizational operations.

8. Test serialization, signature verification, access policies, and recovery under realistic failure conditions.

9. Record provenance and validation assumptions so that users understand what the blockchain does and does not guarantee.

10. Review cryptographic choices periodically for interoperability, legal compliance, and emerging threats.

Chapter Summary

Cryptography supplies the mechanisms through which blockchain systems protect integrity, authenticate actions, and link records into verifiable histories. Hash functions create fixed-length commitments and support block linking, transaction identification, and Merkle trees. Merkle roots summarize transaction sets and enable efficient inclusion proofs, but they do not establish the truth of the underlying data.

Public-key cryptography separates a secret private key from a shareable public key. Digital signatures demonstrate control of a private key and protect message integrity, while addresses provide identifiers for receiving assets or expressing authorization conditions. Wallets manage keys rather than physically storing blockchain assets. Consequently, key generation, backup, recovery, rotation, and revocation are central governance responsibilities.

Decentralized identity uses identifiers and verifiable credentials to support portable, privacy-aware claims. Its success depends on issuer legitimacy, key security, revocation, recovery, and dispute governance. Across all applications, blockchain preserves submitted records more effectively than it establishes factual truth. Sound systems therefore combine cryptography with trustworthy data collection, institutional controls, privacy engineering, and professional oversight.

Key Terms

Hash function: A one-way computational function that maps arbitrary input to a fixed-length digest.

Digest: The fixed-length output produced by a cryptographic hash function.

Collision resistance: The property that makes finding two different inputs with the same hash computationally infeasible.

Hash pointer: A reference to data that includes a cryptographic hash of that data or a preceding object.

Merkle tree: A hierarchical hash structure that summarizes a collection of data through a single root hash.

Merkle root: The top-level hash committing to the leaves and arrangement of a Merkle tree.

Merkle proof: Evidence allowing a verifier to confirm that an item belongs to a committed Merkle tree.

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

Private key: A secret cryptographic value used to sign, decrypt, or authorize operations.

Public key: A shareable cryptographic value used to verify signatures or encrypt for a recipient.

Digital signature: A cryptographic value generated with a private key that authenticates a message and protects its integrity.

Address: An encoded blockchain identifier derived from a key or authorization script.

Wallet: Software or hardware that manages keys and authorizes blockchain operations.

Custodial wallet: A wallet service in which a third party controls users’ private keys.

Multisignature: An authorization arrangement requiring multiple signatures or keys.

Decentralized identifier: A persistent identifier designed to be controlled without mandatory dependence on a central identity provider.

Verifiable credential: A digitally signed claim whose issuer and integrity can be checked.

Selective disclosure: The presentation of only the attributes necessary for a particular verification.

Data provenance: Information describing the origin, history, transformations, and custodianship of data.

Oracle: A mechanism that supplies external-world information to a blockchain system.

Review Questions

Short Answer Questions

1. What is the difference between hashing and encryption?

2. Why is a Merkle root useful in a blockchain block header?

3. What does a digital signature prove, and what does it not prove?

4. Why is a wallet not accurately described as a container of coins?

5. Define selective disclosure in decentralized identity.

Long Answer Questions

1. Explain the properties of a cryptographic hash function and discuss its uses in blockchain systems.

2. Describe the construction and verification of a Merkle proof, including its benefits and limitations.

3. Compare custodial, non-custodial, hot, cold, and multisignature wallet arrangements.

4. Discuss key management as a technical and organizational governance problem.

5. Explain how verifiable credentials can support decentralized identity while preserving privacy.

Analytical / Application Questions

1. A company stores signed temperature readings from a supply-chain sensor on a blockchain. Analyse which aspects of integrity the system can establish and which risks remain outside cryptographic protection.

2. An organization loses one of three private keys required for a three-of-five treasury wallet. Propose a recovery and governance response, considering both security and continuity.

3. Design a credential-verification workflow for a university that minimizes disclosure of student information while supporting issuer authentication and credential revocation.

22. Multiple Choice Questions with Answers

Question 1

A blockchain user changes one character in a transaction before broadcasting it. Which consequence is most directly expected?

A. The transaction hash changes, so a signature over the original transaction will normally fail verification.

B. The transaction remains valid because addresses are independent of transaction contents.

C. Only the Merkle root changes; the signature remains valid.

D. The private key is automatically regenerated.

Correct Answer: A. The transaction hash changes, so a signature over the original transaction will normally fail verification.

Question 2

What does a Merkle proof primarily allow a verifier to establish?

A. That the transaction was factually truthful.

B. That a transaction belongs to a committed set represented by a Merkle root.

C. That the transaction sender is a legally identified person.

D. That the entire blockchain is confidential.

Correct Answer: B. That a transaction belongs to a committed set represented by a Merkle root.

Question 3

Which statement best distinguishes a digital signature from encryption?

A. A signature normally supports authenticity and integrity, while encryption primarily supports confidentiality.

B. A signature always hides the message, while encryption identifies the sender.

C. Both mechanisms require the recipient to publish a private key.

D. Encryption cannot use public keys.

Correct Answer: A. A signature normally supports authenticity and integrity, while encryption primarily supports confidentiality.

Question 4

A valid transaction signature most directly demonstrates that:

A. The underlying business claim is true.

B. The signer controlled the relevant private key and signed the presented message.

C. The private key has never been compromised.

D. The signer is a government-verified individual.

Correct Answer: B. The signer controlled the relevant private key and signed the presented message.

Question 5

Why is an address not necessarily a real-world identity?

A. Addresses cannot be used to receive assets.

B. An address is generally an identifier derived from a key or authorization condition and may be pseudonymous.

C. Addresses contain the holder’s full legal history.

D. Addresses are always generated by regulators.

Correct Answer: B. An address is generally an identifier derived from a key or authorization condition and may be pseudonymous.

Question 6

Which control most directly reduces the risk that one employee can unilaterally transfer organizational assets?

A. Address reuse

B. A larger block size

C. Multisignature authorization

D. Publishing private keys on a public ledger

Correct Answer: C. Multisignature authorization

Question 7

A hash of a predictable list of identification numbers is published publicly. What is the main concern?

A. Hash functions cannot produce fixed-length outputs.

B. An attacker may test likely inputs and link hashes to the original values.

C. The hash automatically reveals the private key.

D. Merkle trees prevent all dictionary attacks.

Correct Answer: B. An attacker may test likely inputs and link hashes to the original values.

Question 8

In a verifiable-credential system, what is the verifier primarily checking?

A. Whether the holder memorized the recovery phrase.

B. Whether the issuer’s signature, credential contents, validity, and status are acceptable.

C. Whether the credential was stored on a mining machine.

D. Whether every personal attribute of the holder was disclosed.

Correct Answer: B. Whether the issuer’s signature, credential contents, validity, and status are acceptable.

Question 9

Which statement about blockchain data integrity is most accurate?

A. Immutability guarantees that all recorded data was true when entered.

B. Cryptography can help show that recorded data was not altered, but it cannot automatically validate the real-world event.

C. Digital signatures eliminate the need for trusted data sources.

D. A blockchain makes sensor calibration unnecessary.

Correct Answer: B. Cryptography can help show that recorded data was not altered, but it cannot automatically validate the real-world event.

Question 10

An organization wants an employee to prove that they possess a required qualification without revealing their complete identity record. Which approach is most appropriate?

A. Publish the employee’s private key.

B. Use selective disclosure or a privacy-preserving credential proof.

C. Reuse one public address for every employee.

D. Store the full identity record permanently on a public blockchain.

Correct Answer: B. Use selective disclosure or a privacy-preserving credential proof.