中文版 · Blockchain learning guide · Previous: When Blockchain Is Useful
Blockchain learning · Article BC011
Cryptography gives precise tools for precise problems. A hash can support change detection. A digital signature can support verification of a key-authorised message. Encryption can protect confidentiality under its design assumptions. A proof system can establish a defined statement without revealing every input.
None of these tools independently guarantees that a document is true, a person intended the displayed action, a service will remain available or a whole application is safe. To interpret a guarantee, you need a threat model: what is being protected, what an adversary can do and which assumptions the protection relies on.
This guide introduces that way of thinking before the detailed lessons on individual cryptographic tools. It uses fictional documents and paper exercises, with no real keys, accounts or attack instructions.
Choose your reading route
In this guide
- 1. Start with a question that has a checkable answer
- 2. What a threat model adds
- 3. Hashes: fingerprints, not secret envelopes
- 4. Signatures: a message and its signing authority
- 5. Encryption: protecting contents requires more than a label
- 6. Proofs: specify the statement before praising the result
- 7. The exhibition-file example
- 8. Change the adversary’s power, and the answer changes
- 9. Cryptographic validity and application validity differ
- 10. Do not turn computational protection into “impossible”
- 11. A compact threat-model worksheet
- 12. What blockchain adds, and what it does not
- Exercise: narrow the claim
- Frequently asked questions
- Sources and scope
- Learn the basic guarantees: compare hashes, signatures, encryption and proofs.
- Understand the boundaries: follow the exhibition-document example and its failure cases.
- Evaluate a security claim: use the threat-model questions and claim-rewriting exercise.
- Plan further study: finish with the learning order and primary standards.
Back to contents · Next section
1. Start with a question that has a checkable answer
“Is this secure?” is too broad to answer usefully. A better question names an object and a possible failure.
For example: has this file changed since an approved version was recorded? Was this message authorised by the relevant signing key? Can an observer read the confidential contents? Can a verifier check this computation without receiving all its private inputs?
Each question points toward a different tool. Choosing a hash when the real requirement is secrecy does not solve the problem. Encrypting a false statement does not make it true. Checking a signature without knowing what the signed message means can verify the wrong thing perfectly.
A useful habit is to write the desired conclusion before naming the algorithm. Then ask what evidence the algorithm can actually supply and what the conclusion still assumes.
This is not pessimism about cryptography. It is how strong technical tools are used without expanding their claims beyond their design.
Back to contents · Next section
2. What a threat model adds
A threat model identifies the protected asset, the unwanted outcome, the adversary’s capabilities and the system’s assumptions.
The asset might be a document’s integrity, a signing key’s secrecy, a user’s private information or the availability of a record. The unwanted outcome might be undetected alteration, unauthorised signing, disclosure or inability to retrieve data.
Capabilities matter. Can the adversary edit a file but not its trusted reference? Can it replace both? Can it control the website displaying the verification result? Can it obtain the signing key? Those are different situations requiring different analysis.
The model should also say what it does not cover. A file-integrity check may not protect against a dishonest author. A confidentiality mechanism may not protect a device after an authorised user decrypts the file on it.
Do not assume that a result proved under one set of capabilities automatically holds when the adversary receives more power. A guarantee is meaningful together with its conditions.
Back to contents · Next section
3. Hashes: fingerprints, not secret envelopes
A cryptographic hash produces a digest from input data. Under the relevant security assumptions, hashes support checks such as detecting a difference between a supplied file and an expected fingerprint.
The expected fingerprint must itself have a trustworthy basis. If someone can replace both the file and the value a website tells you to compare, a simple matching display may prove very little about the original version.
A hash also does not hide predictable input. If there are only a few plausible messages, an observer may compare candidate inputs with the published digest. “Hashed” should therefore not be used as a synonym for confidential or anonymous.
NIST’s Secure Hash Standard, FIPS 180-4, August 2015, describes hash algorithms and message digests. Its publication page notes a planned revision; this article uses it for foundational concepts, not as a complete current algorithm-selection policy.
The central question is: what digest are we comparing against, and why is that reference authoritative for the claim?
Back to contents · Next section
4. Signatures: a message and its signing authority
A digital signature allows a verifier to check a relationship between a message, a signature and a public verification key. It can support evidence that the corresponding signing authority authorised the message under the scheme’s assumptions.
The message matters. A signature over “version received” is not a signature over “version approved for public release.” A signature over a fingerprint needs the surrounding protocol to explain which file and purpose it refers to.
Key control matters too. If signing authority is compromised, an attacker may create a signature that passes the cryptographic check. Verification does not automatically distinguish a legitimate human decision from misuse of a valid key.
NIST’s Digital Signature Standard, FIPS 186-5, published 3 February 2023, is a primary reference for signature mechanisms. The publication page also lists potential updates. A standard’s existence does not certify every application’s identity, key-management or user-interface design.
Keep the conclusion narrow: the signature check supports a defined authorisation claim, not every possible claim about honesty, identity or legal effect.
Back to contents · Next section
5. Encryption: protecting contents requires more than a label
Encryption transforms information so that recovering the plaintext requires the appropriate key and scheme conditions. It addresses confidentiality, but the full design also needs to handle integrity, authentication, key management and correct implementation.
A raw statement that “AES is used” does not describe how the system protects messages. The mode, surrounding protocol and key handling matter. This guide does not prescribe a construction or provide implementation instructions.
Consider an encrypted exhibition-planning file. The storage provider may be unable to read its contents under the intended design, yet authorised recipients can still disclose what they decrypt. File size, access timing or other metadata may also remain visible.
Encryption does not make a document accurate, ensure that it can be recovered after key loss, or prevent every endpoint from being compromised. Those are separate requirements.
NIST’s Advanced Encryption Standard, FIPS 197 describes the AES block cipher. It is a reference for a cryptographic component, not a complete secure application architecture.
Back to contents · Next section
6. Proofs: specify the statement before praising the result
A cryptographic proof system lets a verifier check a defined relation under the proof system’s assumptions. Zero-knowledge techniques can limit what the verifier learns about the private witness used to establish that relation.
The statement’s scope is crucial. A proof that a calculation followed specified rules does not establish that the rules are fair or that an outside measurement was accurate. A proof about one selected property does not certify the whole application.
Privacy is also scoped. Public inputs, the statement itself, timing and surrounding network observations can reveal information. A system using zero-knowledge proofs for scaling is not automatically a confidential communication system.
Ethereum’s zero-knowledge proof explanation introduces these ideas. Actual proof systems differ in assumptions, setup, implementation and what they reveal.
A useful question is: if the proof verifies, what exact sentence may the verifier now conclude, and which questions remain unanswered?
Back to contents · Next section
7. The exhibition-file example
Imagine three adult curators preparing a fictional exhibition checklist. They want to know whether a downloaded file matches the approved version, which authority approved it and whether an unpublished section remains confidential.
Those are three requirements, not one. A digest comparison can contribute to version matching. A signed approval statement can contribute to authorisation evidence. An appropriate encryption design can protect restricted contents during storage or transmission.
Now add a fourth requirement: readers must still be able to obtain the file after one service becomes unavailable. That needs an availability and recovery plan. None of the first three tools automatically supplies it.
Finally, consider factual quality. A curator could approve a file containing the wrong exhibition date. Cryptography can preserve and authenticate that error accurately. Editorial checking remains necessary.
The example shows why combining strong components does not remove the need to define the overall result. Each tool contributes something different, and the remaining process must connect them correctly.
Back to contents · Next section
8. Change the adversary’s power, and the answer changes
Start with a narrow scenario: someone can alter the downloaded checklist but cannot alter the trusted approved digest. A suitable comparison can reveal that the file no longer matches.
Now give the adversary control of the website that displays both the file and the expected digest. A user who trusts only that page may see a convincing match for the substituted material. The earlier argument no longer covers the new capability.
Next, suppose the approval key is compromised. A signature can verify correctly while the underlying approval was unauthorised in the real organisation. The response requires key-management and incident procedures, not just repeating the signature check.
Finally, suppose the adversary can only make the storage service unavailable. Integrity and signature checks may remain sound, but the user cannot obtain the file. This is an availability failure.
These are conceptual cases, not instructions for attacking a service. Their purpose is to show that “the cryptography worked” and “the user’s goal was achieved” are not always the same statement.
Back to contents · Next section
9. Cryptographic validity and application validity differ
A message can have a valid signature but request an action the application should reject. The sender may lack the necessary role, the requested resource may no longer be available or the message may be inappropriate for the current context.
Likewise, a transaction’s valid authorisation does not establish that it is beneficial to the signer. A misleading interface can lead someone to approve an action they did not understand.
Applications therefore need checks around the cryptographic primitive: correct message interpretation, permissions, relevant context and safe handling of repeated or stale instructions. The exact mechanisms are protocol-specific.
Solidity’s security considerations emphasise that application, compiler and platform risks remain. A bounded review can improve confidence without making the whole system immune to failure.
A strong security explanation separates the mathematical check from the policy decision that uses its result.
Back to contents · Next section
10. Do not turn computational protection into “impossible”
Many practical cryptographic guarantees depend on assumptions about the difficulty of certain computations, appropriate parameters and correct implementations. Their everyday value can be very strong without being a statement that failure is logically impossible.
This is why security language should identify the scheme and conditions rather than promise that no attacker could ever succeed. It is also why implementation and key generation matter: a sound primitive cannot compensate for every error around it.
Avoid inventing a universal number of years that would make every system safe. Different algorithms and parameter choices address different threats, and deployment decisions require current expert guidance.
For a beginner, the useful distinction is between a defined security claim and an absolute slogan. “Designed to resist this class of attack under these assumptions” is more informative than “unhackable.”
This article does not rank algorithms or recommend cryptographic parameters for production use.
Back to contents · Next section
11. A compact threat-model worksheet
For one claim, write six short lines.
- Asset: what must be protected?
- Bad outcome: what must the system prevent or reveal?
- Adversary capability: what can the attacker read, change or control?
- Mechanism: which cryptographic check contributes to protection?
- Assumption: what must remain true for that check to support the claim?
- Residual risk: what is still outside the guarantee?
For file matching: the asset is an approved version; the bad outcome is accepting altered bytes as that version; the adversary can alter a downloaded copy; the mechanism is digest comparison; the assumption is a trustworthy reference and suitable hash/checking process; the residual risk includes false original content and missing files.
For signed approval: the asset is authorised decision evidence; the bad outcome is accepting an unauthorised approval; the mechanism is signature verification; key control and identity binding remain assumptions; misunderstanding the approved message remains a separate risk.
The worksheet is an educational tool, not a substitute for a formal security assessment. Its value is making missing conditions visible early.
Back to contents · Next section
12. What blockchain adds, and what it does not
A blockchain combines cryptographic tools with validation, agreement and operating arrangements. Cryptography helps participants check data and authorisation; the wider protocol determines how the accepted history is maintained.
A chain of hashes alone does not settle which history participants should accept. Signatures alone do not order conflicting requests. Proofs alone do not make required data permanently available.
NIST’s Blockchain Technology Overview, October 2018, is useful for seeing these components together. The system guarantee depends on their composition and assumptions, not simply on the presence of cryptographic terminology.
Also keep the surrounding application visible. A user may rely on an access provider, document store, administrator and source of outside information. A secure base protocol does not automatically secure each dependency.
The lesson is to connect precise component guarantees into a precise system claim, while preserving the gaps that still need other controls.
Back to contents · Next section
Exercise: narrow the claim
Claim A: “The file is hashed, so nobody can read it.”
Correction: Hashing is not encryption. A published digest can support a comparison, while predictable inputs may still be guessable.
Claim B: “The signature is valid, so the person definitely intended this action.”
Correction: The check supports a key-linked authorisation claim. Key compromise, identity arrangements and what the person saw or understood require separate analysis.
Claim C: “The proof verified, so all the source data must be true.”
Correction: The proof establishes the specified relation under its assumptions. It does not automatically validate the real-world source of every input.
Claim D: “The document is encrypted, so we cannot lose it.”
Correction: Confidentiality is different from availability and recovery. Both the ciphertext and the required keys need appropriate handling.
For a final exercise, choose one correction and name a capability that would change its threat model. Do not use a real account or secret; a written hypothetical is sufficient.
Back to contents · Next section
Frequently asked questions
Does a strong algorithm guarantee a strong application?
No. Correct composition, implementation, key handling, permissions and user interaction also matter. A strong component can be placed inside a weak process.
Is a threat model the same as a trust model?
They overlap. A trust model highlights reliance and authority; a threat model focuses on protected assets, unwanted outcomes and adversary capabilities. Using both helps explain the full boundary of a guarantee.
Does every blockchain use the cited NIST algorithms?
No. The standards illustrate categories of cryptographic tools. This article does not claim that all blockchains implement them or are certified against them.
What should I learn next?
Study hashes first, then keys and signatures, then commitments and proofs. At each step, write one claim the tool supports and one it does not.
Back to contents · Next section
Sources and scope
The foundational reference was dated 12 October 2026, Asia/Singapore. The primary pages below were checked during this lesson’s preparation. Publication dates identify the cited documents, not a blanket assertion that their parameters are suitable for every current deployment.
- NIST FIPS 180-4: Secure Hash Standard, August 2015; publication page notes revision planning.
- NIST FIPS 186-5: Digital Signature Standard, 3 February 2023; publication page provides potential updates.
- NIST FIPS 197: Advanced Encryption Standard: the AES component standard.
- Ethereum: Zero-knowledge proofs: introductory proof concepts and boundaries.
- Solidity: Security Considerations: application and platform limitations.
- NIST IR 8202: Blockchain Technology Overview, October 2018: composition of blockchain mechanisms.
Ask a precise question, identify the exact guarantee, and keep the assumptions beside it. That is the foundation of useful cryptographic judgment.