Identity, Privacy and Advanced Cryptographic Protocols

Introduction

Blockchain systems replace many traditional trust intermediaries with distributed consensus, cryptographic authentication and publicly verifiable state. This creates powerful possibilities for identity management and privacy, but it also exposes a fundamental tension: blockchains are designed to preserve and replicate information, while identity systems must support confidentiality, correction, revocation and context-specific disclosure.

A blockchain address is not, by itself, a complete digital identity. It is usually a public identifier controlled by a cryptographic key. A usable identity system must additionally answer questions such as: Who issued a claim? What evidence supports it? Who is entitled to see it? Can the holder disclose only the necessary attributes? Can a verifier detect fraud without learning unrelated personal information? What happens when a key is lost or a credential is revoked?

This chapter examines decentralized identity, verifiable credentials, selective disclosure and advanced privacy-preserving protocols. It also evaluates commitments, zero-knowledge proofs, ring signatures, confidential transactions, secure multiparty computation and threshold cryptography. The emphasis is on architectural reasoning: selecting the appropriate cryptographic mechanism, understanding its assumptions and recognizing its operational and governance limitations.

Learning Objectives

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

1. Distinguish blockchain accounts, decentralized identifiers and verifiable credentials.
2. Explain the issuer–holder–verifier model and the role of trust registries.
3. Evaluate selective disclosure and zero-knowledge proof systems.
4. Explain commitments, ring signatures and confidential transactions.
5. Compare secure multiparty computation with threshold cryptography.
6. Analyse privacy, key-management, governance and regulatory trade-offs.
7. Design a suitable identity and privacy architecture for an applied scenario.

1. Identity as a Cryptographic and Governance Problem

Traditional identity systems often rely on central databases. A government, bank or university maintains records and authenticates users. Decentralized identity does not necessarily eliminate institutions; instead, it changes how identifiers, claims and verification are managed. Trust can be distributed among issuers, holders, verifiers, registries and governance bodies.

Three distinctions are essential:

• Identifier: A value used to refer to an entity, such as a decentralized identifier (DID) or public key.
• Authentication: Evidence that a party controls a particular identifier or key.
• Authorization: A decision about what an authenticated party may do.
• Credential: A signed claim about a subject, such as a qualification or age range.

A public blockchain can provide tamper-evident publication of keys, service endpoints, revocation information or governance rules. It should generally not store raw personal data. Public, permanent replication is difficult to reconcile with data minimization and deletion rights.

The issuer–holder–verifier model

A common model contains three principal roles:

1. Issuer: Creates and digitally signs a credential.
2. Holder: Stores the credential and decides when to present evidence.
3. Verifier: Checks authenticity, validity, status and policy compliance.

A university may issue a digitally signed graduation credential to a student. The student may present it to an employer. The employer verifies the issuer’s signature and checks whether the credential remains valid. A blockchain may anchor the university’s public key or publish a status registry, but the detailed credential can remain in the holder’s wallet.

This model separates possession from verification. The verifier need not contact the issuer for every presentation, although governance may require status checks or issuer availability.

2. Decentralized Identifiers and Verifiable Credentials

A decentralized identifier is a persistent identifier designed to be controlled through cryptographic methods and resolved, directly or indirectly, to metadata such as verification methods and service endpoints. A DID document may contain public keys, authentication relationships and update information. Implementations differ: some use blockchains, while others use distributed ledgers, peer-to-peer systems or conventional web infrastructure.

A DID is not automatically anonymous. Reusing one identifier across employment, healthcare and purchasing can create a detailed correlation profile. Privacy-preserving systems therefore encourage pairwise or context-specific identifiers.

A verifiable credential is a structured claim whose authenticity and integrity can be checked cryptographically. A simplified credential contains:

Digital signatures provide integrity and issuer authentication, but they do not prove that the issuer’s claim is true. A valid signature means that the stated issuer signed the data; it does not establish that the issuer was competent, honest or authorized. Governance and institutional accountability remain necessary.

Credential lifecycle

A professional system must address issuance, storage, presentation, verification, renewal, suspension, revocation, recovery and retirement. Key loss is particularly important. If the holder loses a private key, a recovery process must restore access without permitting an attacker to impersonate the holder. Recovery may involve trusted contacts, institutional re-issuance, social recovery or threshold-controlled guardians.

Revocation is also subtle. A public revocation list can reveal that a person possesses or once possessed a credential. Privacy-preserving status mechanisms may use accumulators, short-lived credentials or privacy-preserving status lists. No approach completely removes the need for governance regarding who may revoke and how disputes are handled.

3. Selective Disclosure and Minimal Disclosure

The principle of data minimization states that a verifier should receive only the information necessary for a decision. For example, a retailer checking whether a customer is above a legal age may need a predicate such as “age ≥ 18,” not a date of birth, address and government identification number.

There are several levels of disclosure:

1. Whole-credential disclosure: The holder shares the complete signed object.
2. Field-level selective disclosure: The holder reveals selected signed attributes.
3. Predicate disclosure: The holder proves that an attribute satisfies a condition without revealing its exact value.
4. Anonymous or unlinkable presentation: The verifier learns that a valid credential exists without being able to link repeated presentations.

Selective disclosure may be implemented using specially designed signatures, commitments and zero-knowledge proofs. Simply hiding fields in a conventional signed JSON document is not always secure: if the signature covers the entire object, removing fields may invalidate the signature; if it does not, omitted fields may be altered.

Linkability and metadata

Cryptographic privacy can be defeated by operational metadata. Reusing the same DID, IP address, timing pattern, credential identifier or payment address can link otherwise private presentations. Privacy analysis must therefore include network, application and organizational layers, not just the proof algorithm.

4. Commitments

A commitment is a cryptographic mechanism that allows a party to commit to a value while keeping it hidden, with the ability to reveal the value later. It has two core properties:

• Hiding: The commitment does not reveal the committed value.
• Binding: After committing, the committer cannot convincingly open the commitment to a different value.

A common construction is the hash commitment:

Here, m is the message or value, r is a randomly generated nonce, ∥ denotes concatenation and H is a cryptographic hash function. The nonce must be generated with sufficient unpredictability. Without r, a low-entropy value such as “yes” or “18” may be guessed and tested.

A commitment is computationally hiding when guessing the value is infeasible under the hash and nonce assumptions. It is computationally binding when finding two different openings with the same commitment is infeasible. These properties depend on the construction and threat model; a hash commitment is not automatically perfectly hiding or perfectly binding.

An important algebraic commitment is the Pedersen commitment:

where g and h are independent generators of a suitable cyclic group, m is the committed message and r is a random blinding factor. Its hiding property is information-theoretic under the standard formulation, while binding relies on the difficulty of computing the discrete-logarithm relationship between g and h. Messages and exponents must be represented in the appropriate group or scalar field.

Commitments support sealed bids, voting, reserve proofs, confidential transactions and zero-knowledge statements. They hide values but do not, by themselves, prove that a committed value satisfies a condition. A proof system must be added for statements such as “the committed age is at least 18.”

5. Zero-Knowledge Proofs

A zero-knowledge proof allows a prover to demonstrate that a statement is true without revealing the witness or secret information that makes it true. A proof system is commonly described through three properties:

• Completeness: An honest prover can convince an honest verifier of a true statement.
• Soundness: A dishonest prover cannot usually convince the verifier of a false statement.
• Zero knowledge: The verifier learns no information beyond the truth of the statement, subject to the formal definition.

The statement is often represented as membership in a language, while the witness is secret. For example, the statement may be “I possess a valid credential issued by an approved university and the credential has not expired.” The witness may include the credential, signature randomness and undisclosed attributes.

Interactive and non-interactive proofs

Interactive proofs involve multiple exchanges between prover and verifier. Non-interactive proofs contain a single proof object. Many blockchain systems prefer non-interactive proofs because a smart contract or network participant can verify them later. The Fiat–Shamir transformation can convert certain public-coin interactive protocols into non-interactive ones by deriving a challenge from a cryptographic hash. Its security depends on the protocol and the assumptions used in the transformation.

SNARKs and STARKs

A succinct non-interactive argument of knowledge (SNARK) can provide small proofs and fast verification, but many systems require a setup ceremony. If toxic setup secrets are not properly destroyed, an attacker may forge proofs. Some SNARKs use universal or updatable setup procedures; others are transparent.

STARK-style systems generally use transparent setup and hash-based assumptions, but proofs are often larger. The appropriate choice depends on verifier cost, prover cost, trust assumptions, available libraries, circuit complexity and post-quantum considerations.

A zero-knowledge proof does not automatically provide anonymity. The statement, proof system, public inputs and transaction graph may still reveal identity or enable correlation. It also does not guarantee truthful input data: a proof that a credential says “income = 50,000” does not prove that the original issuer measured income correctly.

6. Ring Signatures and Anonymous Membership

A ring signature allows one member of a group to sign a message without revealing which member signed it. The verifier knows that some authorized member produced the signature, but cannot identify the individual signer, assuming the scheme’s security properties hold.

Ring signatures differ from group signatures. Group signatures typically include an authority capable of opening a signature to identify the signer. Ring signatures generally have no central opener. This improves deniability but complicates accountability, abuse investigation and revocation.

Applications include anonymous authorization, whistleblowing and privacy-oriented payments. A major risk is ambiguity about the anonymity set. A ring of ten keys offers a smaller potential anonymity set than a ring of ten thousand, and real-world behavior may reduce effective anonymity further. If only a few keys are likely to be active, statistical analysis may identify the signer.

A related concept is a linkable ring signature. It preserves signer anonymity while allowing the system to detect whether the same secret key has signed twice in a prohibited context, such as double-spending. Linkability must be designed carefully because the linkability tag itself can become a tracking identifier.

7. Confidential Transactions

A confidential transaction hides transaction amounts while allowing the network to verify that no money has been created improperly. Pedersen commitments are commonly used for amounts. If input commitments are C₁, C₂, …, C_n and output commitments are C'₁, C'₂, …, C'_m, a balance relation can be verified in a group without revealing the amounts:

This simplified relation assumes fees and other components are represented consistently. In practice, a transaction may satisfy:

The protocol must also prove that each committed amount is non-negative and within an allowed range. Otherwise, negative values could cancel positive values and create hidden inflation. Range proofs provide this assurance without revealing the amount.

Confidential transactions therefore combine commitments, balance proofs and range proofs. They may also use stealth addresses to prevent observers from linking payments to a recipient’s reusable public address.

Confidentiality is not absolute. Transaction timing, network traffic, wallet behavior, exchange records and regulated intermediaries may still reveal participants. Furthermore, auditors may legitimately require controlled disclosure. Systems should support lawful audit mechanisms without creating a universal decryption key that becomes a single point of catastrophic failure.

8. Secure Multiparty Computation

Secure multiparty computation (MPC) enables several parties to compute a function over their private inputs while revealing only the permitted output. For parties with private inputs [[MATH{x_1, x_2, …, x_n}]], the goal is to compute:

without exposing the individual inputs beyond what can be inferred from y.

MPC protocols differ in their adversary models:

• Semi-honest: Participants follow the protocol but try to learn extra information.
• Malicious: Participants may deviate arbitrarily; stronger checks are required.
• Abort or fairness assumptions: A participant may stop the protocol, potentially preventing completion.

MPC can support private credit scoring, collaborative analytics, private auctions and distributed key generation. Its costs include communication rounds, bandwidth, computation, preprocessing and robustness against unavailable or malicious participants. Leakage through the output must also be considered: a perfectly secure protocol can still reveal sensitive information if the function’s result is too detailed or queries can be repeated.

MPC is not the same as threshold cryptography, although the technologies overlap. MPC is a general method for computing functions on private inputs. Threshold cryptography specifically distributes control of a cryptographic key or signing/decryption operation among multiple parties.

9. Threshold Cryptography

In a [[MATH(t, n)]] threshold system, any at least t of n participants can perform an operation, while fewer than t cannot. A threshold signature scheme may produce one signature that verifies under a single public key, even though no participant holds the complete private key.

A common secret-sharing principle is that a secret can be represented by a polynomial of degree [[MATH(t − 1)]]. The secret is the constant term:

Here, p is a suitable prime modulus, a₀ is the secret and each participant receives a point [[MATH(i, f(i))]]. Any t valid points can interpolate the polynomial and recover the secret, while fewer points should reveal no information under the scheme’s assumptions. In operational systems, participants commonly perform the cryptographic operation jointly rather than reconstructing the secret in one location.

Threshold cryptography is useful for:

• institutional wallets requiring multiple approvals;
• validator or custody keys resilient to one server compromise;
• distributed certificate authorities;
• blockchain bridges and treasury management;
• key recovery and emergency governance.

It introduces coordination and availability risks. If too many participants are offline, authorized operations fail. If the governance group colludes, the threshold may be defeated. Participant replacement, resharing, auditability and secure distributed key generation are therefore essential.

10. Comparative Design Framework

A practical selection process should ask:

1. What must remain secret: identity, amount, attribute, key or computation input?
2. Who must be convinced, and what exactly must be proven?
3. Is accountability required, or is deniability a design objective?
4. What are the trust assumptions, setup assumptions and failure modes?
5. What metadata can cause correlation despite cryptographic protection?
6. How will keys be recovered, rotated, revoked and audited?
7. What legal duties require disclosure, retention or correction?

11. Applied Case: Privacy-Preserving Professional Licensing

This is an illustrative case. Consider a national engineering regulator that issues licenses to qualified professionals. Employers need to confirm that a candidate is licensed and that the license is current. They do not need the candidate’s home address, full examination history or date of birth.

Background and problem

The regulator’s existing online portal creates a central log of every employer query. A data breach would expose employment relationships and personal details. Paper certificates are easy to forge, and direct database access creates operational dependence on the regulator.

Analysis

The required statement is not “reveal the entire license.” It is: “This holder possesses a credential issued by the recognized regulator, the credential is within its validity period, and the professional category is civil engineering.” The verifier may also require a jurisdiction and a status check.

Approach

The regulator issues a verifiable credential containing the license category, jurisdiction, issue date, expiry date and a revocation reference. The holder stores it in a wallet. For each employer, the wallet uses a pairwise identifier. A presentation proof reveals the category and jurisdiction and proves that the expiry date is later than the current date. A zero-knowledge proof hides the exact birth date and unrelated claims. A privacy-preserving status mechanism permits verification of suspension without publishing a complete list of licensed individuals.

The regulator’s signing keys are protected using threshold cryptography. For example, a policy may require three of five authorized officers or services to approve key operations. The signing key is never stored as a complete plaintext secret on one server. Key rotation and emergency revocation are documented in governance procedures.

Outcome

Employers receive sufficient evidence for hiring decisions while learning less personal information. The regulator gains a more resilient issuance service, and blockchain anchoring can publish the regulator’s public key and status-system parameters without storing personal credentials on-chain.

Learning points

• The blockchain is a support layer, not necessarily the identity database.
• A valid signature does not replace institutional trust.
• Selective disclosure must be designed with unlinkability and metadata in mind.
• Revocation, recovery and governance are as important as the proof algorithm.
• Threshold protection reduces single-key compromise but does not eliminate collusion or operational failure.

12. Security, Ethical and Regulatory Considerations

Key management and recovery

The strongest proof system cannot compensate for a stolen signing key or compromised wallet. Systems should use hardware-backed protection where appropriate, secure key generation, rotation, least privilege, transaction limits and tested recovery procedures. Recovery should be auditable and should not silently transfer identity control to an administrator.

Immutability versus correction

Permanent ledgers conflict with the need to correct inaccurate personal data. A sound architecture stores references, hashes or revocation states rather than raw personal information. Even a hash can be personal data if it remains linkable to an individual. Privacy engineering must therefore assess the entire data lifecycle.

Consent and power asymmetry

A person may technically control a credential but have no practical choice if an employer or government requires disclosure. “User-controlled” does not automatically mean ethically voluntary. Interfaces should make disclosed fields, recipients, duration and purpose understandable. Coercive or excessive requests should be detectable through policy controls.

Cryptographic agility and quantum risk

Many deployed systems rely on discrete logarithms or integer factorization. Large-scale quantum computers could threaten widely used public-key systems through Shor’s algorithm, while Grover’s algorithm affects the security margin of symmetric primitives and hashes. Systems with long-lived credentials should support algorithm agility, migration plans and, where appropriate, post-quantum signatures and commitments. Migration must consider credential re-issuance, proof-system compatibility and archival verification.

AI and privacy protocols

AI systems may verify documents, detect fraud or infer attributes, but inference can create new privacy risks. A zero-knowledge proof that an input satisfies a condition does not make an AI model fair or its source data accurate. Organisations should separate cryptographic verification from automated decision-making, document model limitations and provide contestability for consequential decisions.

13. Best-Practice Design Principles

1. Minimize on-chain personal data. Put only what must be public and persistent on a ledger.
2. Separate identification from authorization. Knowing who controls an identifier does not determine every permitted action.
3. Prefer predicates to raw attributes. Prove “meets requirement” rather than revealing unnecessary values.
4. Use pairwise identifiers where correlation is harmful. Avoid a single universal identifier.
5. Make trust assumptions explicit. Document issuer authority, setup ceremonies, cryptographic assumptions and governance powers.
6. Design revocation and recovery before deployment. These are core functions, not later additions.
7. Protect against metadata leakage. Review network, timing, wallet and transaction patterns.
8. Use established standards and audited implementations. Avoid inventing cryptographic primitives or proof formats.
9. Test adversarially. Include malicious issuers, dishonest verifiers, colluding threshold parties, lost devices and unavailable services.
10. Provide controlled accountability. Where regulation requires investigation, define narrowly governed disclosure procedures rather than universal surveillance keys.

Chapter Summary

Decentralized identity combines cryptographic identifiers, signed claims, holder-controlled storage and verifier-side validation. Verifiable credentials establish integrity and issuer attribution, but governance is required to establish the issuer’s authority and the truth of claims. Selective disclosure and zero-knowledge proofs reduce unnecessary data exposure, while commitments hide values and support later proofs of consistency.

Ring signatures provide anonymity within a signer set, although anonymity depends on set quality and may conflict with accountability. Confidential transactions hide amounts through commitments and require balance and range proofs to prevent inflation. MPC enables joint computation over private inputs, whereas threshold cryptography distributes control of signing or decryption operations. These technologies reduce particular risks but do not eliminate key compromise, metadata leakage, collusion, inaccurate source data or regulatory obligations.

A professional design therefore combines cryptographic mechanisms with sound key management, privacy-by-design, recovery, revocation, governance, standards compliance and ongoing security assessment.

Key Terms

Decentralized identifier (DID): A cryptographically controllable identifier for an entity.

Verifiable credential: A digitally verifiable claim issued about a subject.

Issuer: Entity that creates and signs a credential.

Holder: Entity that stores and presents a credential.

Verifier: Entity that checks a credential or proof.

Selective disclosure: Revealing only selected credential attributes.

Data minimization: Limiting collected and disclosed data to what is necessary.

Commitment: A cryptographic value that hides a message while binding the committer to it.

Hiding: A commitment property preventing the committed value from being learned.

Binding: A commitment property preventing alternative openings.

Zero-knowledge proof: Proof of a statement without revealing its witness.

SNARK: Succinct non-interactive argument of knowledge.

STARK: A transparent, generally hash-based succinct proof system.

Ring signature: A signature proving membership in a signer set without identifying the signer.

Confidential transaction: A transaction whose amounts are cryptographically hidden while validity is proven.

Range proof: Proof that a hidden value lies within an allowed interval.

Secure multiparty computation: Joint computation over private inputs.

Threshold cryptography: Cryptographic control requiring a minimum number of participants.

Linkability: The ability to determine that two actions involve the same hidden party or key.

Trust registry: A governed record of approved issuers, keys or schemas.

Review Questions

Short Answer Questions

1. Distinguish an identifier, authentication and authorization.
2. What are the issuer, holder and verifier roles in a verifiable credential system?
3. State the hiding and binding properties of a commitment.
4. Why are range proofs needed in confidential transactions?
5. How does threshold cryptography improve resilience against single-key compromise?

Long Answer Questions

1. Explain how decentralized identifiers and verifiable credentials can reduce dependence on a central identity database. Discuss the remaining governance requirements.
2. Compare whole-credential disclosure, selective disclosure and zero-knowledge predicate proofs.
3. Explain the construction and purpose of commitments in privacy-preserving blockchain applications.
4. Compare ring signatures, confidential transactions and zero-knowledge proofs in terms of privacy objective and limitation.
5. Discuss the differences between secure multiparty computation and threshold cryptography, including suitable applications for each.

Analytical / Application Questions

1. Design a privacy-preserving university qualification credential system. Specify the information stored on-chain, the information retained by the holder and the proofs presented to an employer.
2. A blockchain bridge currently stores one private signing key on a cloud server. Analyse the security and governance risks and propose a threshold-cryptographic migration plan.
3. A regulator wants to verify that citizens are eligible for a benefit without learning their exact income. Select suitable commitments, proofs and status mechanisms, and explain metadata and ethical risks that remain.

Multiple Choice Questions with Answers

Question 1

Which role creates and digitally signs a verifiable credential?

A. Issuer

B. Holder

C. Verifier

D. Network observer

Correct Answer: A. Issuer

Question 2

What is the primary purpose of selective disclosure?

A. To reveal all credential fields permanently

B. To disclose only information necessary for verification

C. To eliminate the need for digital signatures

D. To make every blockchain transaction anonymous

Correct Answer: B. To disclose only information necessary for verification

Question 3

In a commitment scheme, which property prevents a committer from opening one commitment to two different values?

A. Completeness

B. Hiding

C. Binding

D. Fairness

Correct Answer: C. Binding

Question 4

In a hash commitment C = H(m ∥ r), what is r normally used for?

A. A random nonce that helps hide m

B. The verifier’s private key

C. The blockchain block number

D. A revocation signature

Correct Answer: A. A random nonce that helps hide m

Question 5

What does a zero-knowledge proof aim to demonstrate?

A. That the verifier knows the prover’s secret

B. That a statement is true without revealing the witness

C. That all transaction metadata is hidden

D. That an issuer is always honest

Correct Answer: B. That a statement is true without revealing the witness

Question 6

What does a ring signature normally conceal?

A. The fact that any signature exists

B. The message being signed in every scheme

C. Which member of the signing group produced the signature

D. The public verification algorithm

Correct Answer: C. Which member of the signing group produced the signature

Question 7

Why do confidential transactions require range proofs?

A. To prove hidden amounts are non-negative and within an allowed range

B. To identify the payer publicly

C. To replace all digital signatures

D. To publish every transaction amount

Correct Answer: A. To prove hidden amounts are non-negative and within an allowed range

Question 8

What is the main objective of secure multiparty computation?

A. To store every input on a public blockchain

B. To compute a function over private inputs while limiting input disclosure

C. To ensure that one administrator controls a secret

D. To remove the need for authentication

Correct Answer: B. To compute a function over private inputs while limiting input disclosure

Question 9

In a (t, n) threshold system, what does t represent?

A. The total number of public keys in the ecosystem

B. The minimum number of participants required for the operation

C. The number of blockchain blocks retained

D. The maximum message length

Correct Answer: B. The minimum number of participants required for the operation

Question 10

Which statement about a valid digital signature is correct?

A. It proves that the signed claim is factually true in every circumstance

B. It proves that the specified signing key signed the data, subject to the scheme’s assumptions

C. It automatically hides all signed data

D. It guarantees that the signer cannot lose its private key

Correct Answer: B. It proves that the specified signing key signed the data, subject to the scheme’s assumptions