Foundations of Cryptography and Blockchain Security

Introduction and Context

Blockchain systems combine cryptographic mechanisms, distributed networking, replicated data storage, and consensus protocols. Their security therefore cannot be reduced to the question, “Is the encryption strong?” A distributed ledger may use excellent cryptography and still fail because of compromised private keys, dishonest validators, insecure software, weak governance, poor operational procedures, or misleading assumptions about what the ledger proves.

Cryptography provides tools for protecting information and establishing evidence about digital actions. Blockchain architecture uses these tools to link records, authenticate transactions, coordinate participants, and make unauthorised alteration difficult. Security engineering determines how those tools are deployed within a system whose participants may not fully trust one another.

A useful starting point is to distinguish three related ideas:

• Cryptography is the study and practice of techniques for protecting information and enabling secure communication.
• Information security concerns the protection of information and systems from unauthorised access, use, disclosure, disruption, modification, or destruction.
• Blockchain security concerns the protection of ledger data, transaction processes, consensus, user assets, interfaces, and governance against technical and organisational threats.

A ledger can be technically immutable yet economically insecure. For example, if an attacker steals a user’s private key, the blockchain may correctly and permanently record an unauthorised transaction. The cryptographic verification has worked; the surrounding security system has failed.

Learning Objectives

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

1. Define essential security and cryptographic terminology.
2. Distinguish assets, vulnerabilities, threats, risks, controls, and incidents.
3. Identify major blockchain threat actors and their capabilities.
4. Explain trust assumptions in permissionless and permissioned ledgers.
5. Map the principal attack surfaces of a blockchain ecosystem.
6. Apply the confidentiality, integrity, availability, authenticity, and non-repudiation model to distributed ledgers.
7. Explain how cryptographic primitives support blockchain security without treating them as a complete security solution.
8. Analyse a practical blockchain security scenario and recommend controls.

1. Security Terminology and the Security Problem

Assets, threats, vulnerabilities, and risk

An asset is something valuable that requires protection. In blockchain systems, assets include cryptocurrency balances, token ownership, private keys, smart contracts, validator infrastructure, transaction history, personal data, availability of a service, and organisational reputation.

A threat is a potential cause of harm. Threats may be intentional, accidental, environmental, or organisational. Examples include key theft, malware, software defects, an internet outage, a malicious validator coalition, and accidental disclosure of personal information.

A threat actor is an individual, group, organisation, or event capable of causing harm. Capability, motivation, opportunity, and resources vary significantly among threat actors.

A vulnerability is a weakness that can be exploited. Examples include a predictable wallet seed, an unpatched node, an incorrectly designed smart contract, excessive administrator privilege, or an assumption that a majority of validators will always behave honestly.

An exploit is a method or code that takes advantage of a vulnerability. An attack is an intentional attempt to compromise a system. An incident is a security event that has, or may have, adverse consequences. Not every event is an incident: a failed login may be an event, while a successful unauthorised login may constitute an incident.

Risk expresses the possibility that a threat will exploit a vulnerability and produce harm. A simple qualitative model is:

Likelihood describes how probable or plausible the harmful event is within a defined period; impact describes the magnitude of resulting harm. This is a risk-analysis model rather than a universal physical law. Values should be defined consistently, and multiplication is meaningful only when the organisation has chosen a compatible scoring scale. In practice, risk is often represented using categories such as low, medium, high, and critical rather than precise numerical probabilities.

A security control is a safeguard that reduces likelihood, impact, or both. Controls may be preventive, detective, corrective, deterrent, or compensating. Examples include hardware security modules, multi-signature approval, rate limiting, code review, monitoring, backups, incident response, and legal governance.

Security objectives

Security objectives describe what must be protected and why. The familiar CIA triad consists of confidentiality, integrity, and availability. Blockchain systems require additional emphasis on authenticity and accountability.

These objectives can conflict. Public transparency may improve auditability while reducing confidentiality. Stronger validation may improve integrity but reduce throughput. A security design therefore begins with explicit requirements, not with the assumption that every property should be maximised equally.

2. Cryptographic Foundations

Hash functions

A cryptographic hash function maps an input of arbitrary length to a fixed-length output called a digest. A secure hash function is designed to provide one-wayness, second-preimage resistance, and collision resistance.

If H is a hash function and m is a message, the digest is:

Here, h is the fixed-length digest and m is the input message. A small change in m should produce a substantially different digest. Hashes do not encrypt data: they are not intended to be reversed to recover the original message.

In blockchains, hashes are commonly used for transaction identifiers, block identifiers, Merkle-tree commitments, linking one block to its predecessor, and proof-of-work puzzles. A hash can demonstrate that data has not changed since a digest was recorded, but it does not by itself prove who created the data or whether the data was truthful.

A collision occurs when two different inputs produce the same digest. Collision resistance means that finding such a pair should be computationally infeasible under the intended security model. The practical strength depends on the algorithm, output length, implementation, and advances in computation.

Symmetric cryptography

Symmetric cryptography uses the same secret key, or closely related secret keys, for encryption and decryption. It is efficient for protecting large amounts of data. Its major operational challenge is secure key distribution: communicating parties must obtain a shared secret without exposing it.

Confidentiality is commonly represented as:

where m is plaintext, c is ciphertext, k is the secret key, Enc is the encryption operation, and Dec is the corresponding decryption operation. Correctness requires that decryption with the authorised key recover the plaintext, subject to the algorithm and mode of operation.

Public blockchains frequently use symmetric encryption for local wallet storage, encrypted backups, node-to-node channels, or confidential application data. However, public ledger data is often intentionally visible, and encryption does not solve authorisation or key-loss problems.

Asymmetric cryptography and digital signatures

Asymmetric cryptography uses a key pair: a private key that must be protected and a public key that may be distributed. Digital signatures enable a party to sign a message with a private key. Others use the corresponding public key to verify the signature.

A signature system is normally expected to provide:

• Authenticity evidence: the signature verifies under the claimed public key.
• Integrity evidence: changing the signed message should cause verification to fail.
• Possession evidence: producing a valid signature generally demonstrates control of the private key at signing time.

A simplified conceptual representation is:

where m is the message, sk is the private signing key, pk is the corresponding public key, and σ is the signature. Actual algorithms define precise security assumptions and verification rules; this notation is not an implementation specification.

A digital signature does not prove that the human owner personally initiated a transaction. It proves that the relevant private key generated a valid signature, assuming the algorithm and implementation are sound. If the key was stolen, coerced, shared, or controlled by malware, the signature may still verify. Legal non-repudiation therefore depends on key custody, identity management, evidence handling, and applicable law as well as mathematics.

Merkle trees

A Merkle tree compresses many data items into a single root hash. Transaction hashes are combined pairwise, and the process continues until one root remains. If a level contains an odd number of items, the protocol must specify how the unpaired item is handled; implementations must follow the protocol’s exact rule.

A Merkle proof allows a verifier to check that a transaction is included in a committed set without receiving every transaction. The proof contains the transaction’s hash and the necessary neighbouring hashes. This supports efficient verification, light clients, and scalable data structures.

Cryptography does not establish truth

Cryptographic verification answers questions such as “Was this message signed by the key corresponding to this public key?” It does not answer “Was the information accurate?”, “Was the signer authorised by the organisation?”, or “Was the key held securely?” These are identity, governance, operational, and application-layer questions.

3. Threat Actors and Their Capabilities

Security analysis should identify actors rather than treating “the attacker” as a single category.

Threat modelling should consider both external and internal actors, direct attacks and indirect supply-chain attacks, and technical as well as social methods. An adversary may combine phishing, malware, social engineering, and exploitation of a smart-contract flaw.

4. Trust Assumptions in Distributed Ledgers

A blockchain is not “trustless” in the absolute sense. It replaces some interpersonal trust with assumptions about mathematics, software, incentives, hardware, communications, and governance. The correct question is: Which parties or mechanisms must be trusted, and what happens if an assumption fails?

Permissionless networks

In a permissionless ledger, participants may join without prior institutional approval. Security commonly depends on assumptions such as:

• the cryptographic primitives remain secure;
• a sufficient proportion of consensus power behaves according to the protocol;
• network connectivity is adequate for honest participants;
• economic incentives discourage harmful behaviour;
• most users protect their private keys;
• software implementations are sufficiently correct;
• no participant can indefinitely isolate or censor all honest nodes.

The exact threshold depends on the consensus protocol. In a generic majority-based model, an adversary controlling more than the protocol’s tolerated fraction of voting or computational power may violate safety, liveness, or transaction ordering assumptions. The phrase “51% attack” is therefore a simplified description, not a complete analysis: different protocols and attacks have different thresholds and consequences.

Permissioned networks

A permissioned ledger restricts participation through identity and governance controls. This may improve accountability, performance, and privacy, but it introduces trust in administrators, certificate authorities, membership services, consortium rules, and organisational coordination. A permissioned system is not automatically more secure; it changes the threat model.

Trust boundaries

A trust boundary separates components with different assumptions or authority. Examples include the boundary between a user and a wallet, a wallet and a node, a node and a smart contract, or a blockchain and an external oracle. Every boundary should specify:

1. What data crosses it?
2. Who can send or modify that data?
3. How is it authenticated?
4. How is it validated?
5. What happens when the receiving component is unavailable or malicious?

5. Blockchain Attack Surfaces

An attack surface is the collection of points through which a system can be attacked. Blockchain security requires a systems view.

Key and wallet layer

Private keys are often the most direct control over digital assets. Risks include phishing, malware, weak random-number generation, insecure backups, seed-phrase exposure, SIM swapping, insider access, and signing malicious messages. Hardware wallets reduce some exposure but do not eliminate user deception or approval of harmful transactions.

Controls include hardware-backed storage, multi-signature or threshold approval, transaction simulation, withdrawal limits, independent verification, secure recovery procedures, and separation of duties.

Client and node layer

Node software may contain vulnerabilities, insecure APIs, poor access control, or denial-of-service weaknesses. Remote administration interfaces should not be exposed unnecessarily. Operators should use authenticated administration, network segmentation, timely patching, reproducible deployment procedures, monitoring, and tested backups.

Network layer

Peer-to-peer networks face eclipse attacks, routing manipulation, denial of service, traffic analysis, and partitioning. An eclipse attack attempts to surround a node with adversarial peers so that it receives a manipulated view of network activity. Encryption of communications may protect confidentiality in transit but does not by itself guarantee honest peer selection or correct consensus.

Consensus layer

Consensus attacks include double spending, censorship, selfish or strategic mining, validator collusion, equivocation, long-range attacks in relevant protocols, and denial of participation. Security depends on the protocol, the distribution of power, timing assumptions, finality model, slashing or other penalties, and monitoring.

Smart-contract and application layer

Smart contracts may contain re-entrancy vulnerabilities, arithmetic errors, faulty access control, oracle manipulation, insecure upgrade mechanisms, and logic that does not match business requirements. Formal verification can improve confidence in specified properties, but it cannot prove that the specification itself represents the correct business objective.

Governance and upgrade layer

Changes to protocol rules, contract code, validator membership, or emergency controls may create centralisation and abuse risks. Upgrade keys, timelocks, emergency pauses, and administrator privileges should be publicly documented and governed under a defined approval process.

Human and organisational layer

Employees, contractors, customers, regulators, and suppliers may all affect security. Social engineering, poor segregation of duties, inadequate training, and unclear incident ownership can defeat technically strong controls.

6. Applying the CIAAN Model to Distributed Ledgers

For this chapter, the five requirements are confidentiality, integrity, availability, authenticity, and non-repudiation (CIAAN).

Confidentiality

Many public ledgers intentionally expose transaction data. Public verifiability may be valuable, but addresses can sometimes be linked to real identities through exchange records, network metadata, and behavioural analysis. Confidentiality controls may include permissioned channels, zero-knowledge techniques, encrypted off-chain storage, data minimisation, and separation of identity from transaction identifiers.

A major design principle is not to place sensitive personal data permanently on an immutable public ledger unless there is a compelling legal and operational justification. Immutability can conflict with correction, deletion, and data-subject rights.

Integrity

Ledger integrity has several dimensions:

• Data integrity: recorded values are not altered without detection.
• State integrity: the current ledger state follows valid transition rules.
• Consensus integrity: participants agree on an accepted history under protocol assumptions.
• Application integrity: smart contracts implement intended business rules.

Hashing supports tamper evidence, signatures support transaction authorisation, and consensus supports agreement. None is sufficient alone.

Availability

Availability includes the ability to submit transactions, obtain current state, query history, operate validators, and recover from failures. Threats include denial-of-service, cloud-provider outages, congestion, censorship, key loss, and software incompatibility. Resilience requires geographically distributed infrastructure, capacity planning, rate controls, monitoring, recovery procedures, and tested operational runbooks.

Authenticity

Authenticity links an action or message to an identity, key, device, or trusted source. Blockchains often authenticate keys rather than legal persons. Organisations must therefore map cryptographic identities to real-world roles through onboarding, certificates, custody controls, and revocation procedures.

External data introduces the oracle problem. A signed oracle message may be authentic as a message from the oracle while still being factually wrong because the source, sensor, or data feed failed.

Non-repudiation

A signature creates technical evidence of key use. Strong non-repudiation additionally requires reliable identity binding, secure key custody, controlled signing processes, time and event records, and a legal framework that recognises the evidence. Shared keys and unmanaged wallets weaken attribution.

7. A Structured Security Assessment Method

A practical assessment can follow these steps:

1. Define scope and assets. Include wallets, contracts, nodes, interfaces, data, governance mechanisms, and external dependencies.
2. Draw trust boundaries and data flows. Identify users, services, validators, oracles, exchanges, and administrators.
3. State assumptions. Record assumptions about honest validators, network synchrony, key custody, identity, and external data.
4. Identify threats and vulnerabilities. Use threat catalogues, penetration testing, code review, abuse cases, and lessons from incidents.
5. Evaluate consequences. Consider financial loss, privacy harm, service interruption, regulatory breach, and reputational damage.
6. Select layered controls. Combine cryptographic, technical, procedural, economic, and legal controls.
7. Test and monitor. Conduct audits, adversarial testing, key-recovery exercises, incident drills, and continuous monitoring.
8. Review after change. Protocol upgrades, new dependencies, new jurisdictions, and changing asset values alter risk.

Defence in depth is essential. A system should not depend on a single administrator, key, cloud region, software library, oracle, or monitoring tool.

8. Illustrative Case: A Consortium Trade Ledger

Background

A consortium of manufacturers and logistics firms develops a permissioned ledger to record shipment milestones and automate payment when goods reach a destination. Each organisation operates validator nodes. A smart contract releases payment after receiving a delivery confirmation from an oracle.

Problem

A shipment is marked delivered even though the goods remain at a port. The buyer loses money, and an investigation finds that the oracle account was compromised. The ledger history is internally consistent: it records a validly signed oracle message and executes the contract as programmed.

Analysis

The incident is not primarily a hash failure. The attack surface included the oracle’s private key, the oracle software, the delivery-data source, contract permissions, and the governance process for correcting erroneous data.

The trust assumptions were inadequately documented. Consortium members assumed that the oracle was reliable, while the contract treated one oracle signature as sufficient evidence. Confidentiality was acceptable because the network was permissioned, but authenticity of the real-world event was weak. Integrity of the ledger was preserved, yet the integrity of the business process failed.

Approach and solution

The consortium introduces:

• multiple independent delivery oracles;
• threshold approval requiring a defined number of concordant reports;
• hardware-protected signing keys;
• narrow oracle permissions and rapid revocation;
• a dispute window before irreversible payment;
• an emergency pause controlled by a multi-party governance group;
• monitoring for unusual delivery patterns;
• documented procedures for correcting off-chain records while preserving an auditable history;
• periodic penetration tests and key-recovery exercises.

The contract is also redesigned so that a delivery event first enters a pending state. Payment occurs only after the dispute period expires or authorised parties approve the event.

Outcome

The revised design does not make false data impossible. It reduces the probability of a single-point failure, limits the amount at risk, improves detection, and creates a controlled response path. The ledger remains useful as an audit mechanism, but it is no longer treated as proof that every recorded real-world event was true.

Learning points

1. On-chain integrity does not guarantee off-chain truth.
2. Oracles are trust boundaries and require explicit security controls.
3. Administrative and emergency powers must be governed, logged, and limited.
4. Delayed settlement can reduce the impact of erroneous or fraudulent inputs.
5. Security requirements must be expressed in business terms, not only cryptographic terms.

9. Limitations, Ethics, and Governance

Immutability and privacy

Immutability supports auditability but can preserve inaccurate, sensitive, or legally problematic information. Data minimisation, off-chain storage, cryptographic commitments, access controls, and carefully designed deletion or revocation strategies should be considered before deployment.

Access and exclusion

Wallet loss, transaction fees, inaccessible interfaces, and irreversible mistakes can exclude users or create disproportionate harm. Systems handling essential services should provide recovery, support, accessibility, and clear dispute mechanisms.

Surveillance and profiling

Transparent ledgers may enable extensive behavioural analysis. Organisations should assess whether public visibility is necessary, apply privacy-by-design principles, and comply with data-protection obligations.

Governance and accountability

Decentralised technology does not remove responsibility. Developers, operators, validators, custodians, application providers, and governance bodies may each have duties. Policies should specify incident reporting, upgrade authority, audit responsibilities, sanctions, recovery, and communication with affected users.

Artificial intelligence

AI can support anomaly detection, code review, phishing analysis, and incident triage. It can also generate vulnerable code, produce false alerts, or be manipulated by adversarial inputs. AI-generated security decisions require human review, traceability, testing, and clear accountability. AI is a control aid, not a substitute for formal requirements and secure engineering.

10. Contemporary Best Practices

Professional blockchain security programmes should:

• use threat modelling before implementation;
• protect keys with hardware-backed or threshold mechanisms where appropriate;
• separate development, testing, administration, and production privileges;
• use secure randomness, dependency management, code review, and reproducible builds;
• audit smart contracts and test failure conditions, not only normal execution;
• document consensus, trust, oracle, and upgrade assumptions;
• monitor validators, transactions, governance actions, and privileged operations;
• maintain offline or independently protected backups and rehearse recovery;
• use staged deployment, transaction limits, timelocks, and emergency procedures;
• minimise sensitive on-chain data;
• perform independent security assessments and post-incident reviews;
• align controls with applicable legal, regulatory, and industry requirements.

Security is a continuing process. A secure deployment at launch may become insecure when asset values increase, software changes, validators consolidate, or attackers discover new techniques.

Chapter Summary

Cryptography supplies hashes, encryption, digital signatures, and commitments that support blockchain integrity, confidentiality, authentication, and efficient verification. These mechanisms do not independently establish real-world truth, legal identity, secure key custody, or sound governance.

Blockchain security begins with precise terminology: assets must be distinguished from threats, vulnerabilities, risks, controls, events, and incidents. Threat actors range from opportunistic criminals and insiders to validator coalitions and supply-chain attackers. Distributed ledgers rely on explicit trust assumptions concerning cryptographic algorithms, software, network conditions, consensus power, incentives, administrators, and external data.

The principal attack surfaces include wallets and keys, nodes, peer-to-peer networks, consensus, smart contracts, oracles, governance, supply chains, and human processes. The CIAAN requirements provide a practical framework: confidentiality protects sensitive information; integrity protects data, state, consensus, and application rules; availability supports continued operation; authenticity links actions to trusted identities or sources; and non-repudiation provides evidence of key use subject to operational and legal conditions.

The central professional lesson is that blockchain security is socio-technical. Strong cryptography is necessary but insufficient. Effective protection requires layered controls, explicit assumptions, sound governance, secure operations, privacy awareness, monitoring, recovery, and continuous reassessment.

Key Terms

Asset: Something valuable that requires protection.

Attack surface: The collection of system points that may be exploited.

Authenticity: Confidence that an entity, message, transaction, or source is genuine.

Blockchain security: Protection of ledger data, assets, processes, participants, and governance from compromise.

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

Confidentiality: Protection against unauthorised disclosure.

Consensus: A protocol process through which distributed participants agree on accepted state or history.

Control: A safeguard that reduces the likelihood or impact of harm.

Digital signature: A cryptographic value generated with a private key and verified with a public key.

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

Integrity: Assurance that data and processes remain accurate and unauthorised changes are detectable.

Non-repudiation: Evidence intended to prevent credible denial of an action, subject to technical and legal conditions.

Oracle: A service that supplies external information to a blockchain application.

Private key: Secret cryptographic material used for operations such as signing.

Risk: The possibility of harm arising from threats exploiting vulnerabilities.

Threat: A potential cause of harm.

Threat actor: A person, group, organisation, or event capable of causing harm.

Trust boundary: A system boundary across which different security assumptions or authority apply.

Vulnerability: A weakness that may be exploited.

Review Questions

5 Short Answer Questions

1. What is the difference between a vulnerability and an exploit?
2. Why does a digital signature not necessarily prove that a human personally authorised a transaction?
3. State the five CIAAN security requirements.
4. What is the purpose of a Merkle tree?
5. Why are oracles important security boundaries in blockchain systems?

5 Long Answer Questions

1. Explain how cryptographic hashes, digital signatures, and consensus work together to protect a distributed ledger.
2. Compare the trust assumptions and attack surfaces of permissionless and permissioned ledgers.
3. Discuss why confidentiality can conflict with transparency and auditability in blockchain design.
4. Analyse the role of private-key management in authenticity and non-repudiation.
5. Explain why blockchain security must include governance, human processes, and supply-chain considerations.

3 Analytical / Application Questions

1. A company stores customer identity documents directly on a public blockchain. Analyse the confidentiality, integrity, availability, authenticity, and non-repudiation consequences, and recommend a safer architecture.
2. A permissionless network experiences a coalition controlling a large proportion of consensus power. Identify possible effects on safety, liveness, transaction ordering, and user confidence. Propose technical and governance responses.
3. Design a threat model for a smart contract that releases insurance payment after an oracle reports a flight cancellation. Identify assets, trust boundaries, threat actors, vulnerabilities, and layered controls.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a cryptographic hash function?

A. It encrypts data so that only the sender can decrypt it

B. It maps input data to a fixed-length digest designed to reveal tampering

C. It guarantees that the input data is factually true

D. It provides network availability during an outage

Correct Answer: B. It maps input data to a fixed-length digest designed to reveal tampering

Question 2

What does a valid digital signature primarily demonstrate?

A. That the transaction is economically beneficial

B. That the signer is physically located at a stated address

C. That the corresponding private key produced a signature for the message

D. That every fact in the message is true

Correct Answer: C. That the corresponding private key produced a signature for the message

Question 3

Which item is a vulnerability rather than a threat actor?

A. A cybercriminal group

B. A malicious validator coalition

C. A predictable wallet seed

D. A nation-state organisation

Correct Answer: C. A predictable wallet seed

Question 4

Which security objective concerns unauthorised disclosure of information?

A. Confidentiality

B. Integrity

C. Availability

D. Non-repudiation

Correct Answer: A. Confidentiality

Question 5

Why does a stolen private key remain dangerous even when the blockchain protocol operates correctly?

A. The blockchain automatically deletes all previous blocks

B. The thief may create transactions that verify as authorised by that key

C. Hash functions stop working when keys are stolen

D. Consensus becomes unnecessary after key theft

Correct Answer: B. The thief may create transactions that verify as authorised by that key

Question 6

What is a principal risk associated with an oracle?

A. It makes all ledger data confidential

B. It guarantees that external information is truthful

C. It introduces a trust boundary for information entering the blockchain

D. It eliminates the need for smart-contract testing

Correct Answer: C. It introduces a trust boundary for information entering the blockchain

Question 7

Which control most directly reduces the risk of a single compromised signing key authorising a withdrawal?

A. Publishing the private key publicly

B. Using multi-signature or threshold approval

C. Removing transaction monitoring

D. Storing the key in an unencrypted text file

Correct Answer: B. Using multi-signature or threshold approval

Question 8

What is the main purpose of a Merkle proof?

A. To prove inclusion of data in a committed set without transmitting the entire set

B. To recover a lost private key

C. To hide all transaction values from validators

D. To determine the legal identity of a user

Correct Answer: A. To prove inclusion of data in a committed set without transmitting the entire set

Question 9

Which statement best characterises a permissioned ledger?

A. It has no governance or identity assumptions

B. Participation is restricted through identity or membership controls

C. It cannot use digital signatures

D. It is automatically immune to insider attacks

Correct Answer: B. Participation is restricted through identity or membership controls

Question 10

A valid oracle message causes a smart contract to record a false real-world event. Which conclusion is most accurate?

A. Ledger integrity necessarily failed because the message was signed

B. Cryptography cannot verify whether an external fact is true

C. Availability guarantees the oracle’s factual accuracy

D. A hash function should have corrected the oracle’s report

Correct Answer: B. Cryptography cannot verify whether an external fact is true