中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC017
Choose a cryptographic operation by the question the recipient must answer. Encryption addresses who can recover protected content. Hashing gives a reproducible digest of exact input bytes. Digital signing lets a verifier check a message’s relationship to a signing key. Real workflows often need more than one operation, plus rules about identity, permission, versions, and delivery.
The mistake is not simply choosing the wrong algorithm. It is sending the wrong evidence for the promised result: a hash where secrecy was required, encrypted content where public authorship verification was required, or a signature that covers a different object from the one the reader sees.
This workshop follows a fictional exhibition catalogue from confidential draft to public release. It uses descriptions of artifacts, not executable cryptographic instructions. The aim is to write a clear requirements-and-evidence plan that an established protocol and maintained implementation can satisfy.
For modular arithmetic, toy RSA and the mathematical foundations of secure messages, see Why Mathematics? Cryptography, Prime Numbers and Secure Messages. This workshop instead maps requirements to the artifacts and audiences of a blockchain-linked document workflow.
Choose your reading route
In this guide
- 1. Start with the exhibition’s promises
- 2. Compare four proposed packages
- 3. Name the exact object behind every digest
- 4. Authentication can protect visible context too
- 5. A signing key and a recipient key answer different questions
- 6. What does the signature actually endorse?
- 7. Map on-chain and off-chain audiences explicitly
- 8. Six delivery tests with answers
- 9. Build a requirements-to-evidence worksheet
- 10. The practical limits of adding cryptography
- Frequently asked questions
- Sources and next reading
If the three operations are new, start with the exhibition requirements and package comparison. If you already know the definitions, focus on what each artifact covers, associated data, recipient versus signer keys, and the six delivery tests.
Earlier lessons explain hash functions and signatures individually. This guide compares the evidence a whole package gives its readers. You do not need to generate keys, upload a real document, or connect to a blockchain to complete the exercises.
Back to contents · Next section
1. Start with the exhibition’s promises
A fictional museum has a draft catalogue, a public opening announcement, and a final catalogue. The team initially says it wants to “make all three secure.” That phrase is too broad to choose a design.
They replace it with explicit requirements:
- Before release, only the invited review group should be able to recover the draft’s content from the delivery package.
- Reviewers should detect unauthorized changes to the protected package under the chosen protocol.
- The final public catalogue should be readable by everyone.
- A reader of the final catalogue should be able to check that an authorized publication key endorsed the specified release statement.
- The announcement and catalogue must identify the same edition.
- The team should not claim that cryptography proves the catalogue’s historical facts are correct.
These requirements already reveal why one operation cannot do everything. Confidential review and public reading have different audiences. A byte-integrity check and an institutional endorsement have different evidence. A version label is application context that must be covered or checked appropriately.
The museum also distinguishes the file from its delivery container. Compressing, packaging, encrypting, or attaching metadata can produce different byte objects even when a person thinks of them as “the same catalogue.” Every check must say which object it concerns.
Back to contents · Next section
2. Compare four proposed packages
Package A: plaintext plus a plain hash
The draft file is sent in readable form with its digest. Anyone who obtains the file can read it. The digest gives no confidentiality. If an adversary can replace both the file and the accompanying digest, a recipient who has no independent expected digest may accept a different matching pair.
This package can still be useful when the expected digest comes through a trusted reference and the task is to compare exact bytes. It is simply unsuitable for the museum’s confidential-review requirement.
Package B: plaintext plus a digital signature
The file remains readable. A correct signature check can connect the signed message to the relevant verification key under the scheme. The reader still needs a reason to associate that key with the publication role and to interpret the signed statement correctly.
This is a plausible building block for a public release. It does not hide the draft. Nor does the signature prove that the text is factually accurate or that its signer had authority beyond the applicable policy.
Package C: an authenticated encrypted package
A suitable authenticated-encryption protocol can protect the content from parties without the required decryption capability and detect unauthorized modifications under its assumptions. The reader must still know which keys and context apply, and the application must handle authentication failure correctly.
That does not automatically give an outside reader publicly verifiable evidence of a particular author’s endorsement. In a shared-secret arrangement, multiple holders may be able to create valid authenticated messages.
Package D: a protocol that combines signing and encryption
This can address both restricted readership and a signature-based endorsement when the chosen protocol defines the combination appropriately. But the design must specify what is signed, what is encrypted, which identities and contexts are bound, and what each recipient verifies.
“Add all three operations” is not a protocol specification. The museum should select a maintained, appropriate message or document protocol rather than improvise a sequence of hash, sign, and encrypt calls. More cryptographic steps do not automatically mean a stronger or more understandable promise.
Back to contents · Next section
3. Name the exact object behind every digest
Suppose the original catalogue file is called P and the encrypted delivery container is called C. These are teaching labels, not actual protocol fields. A digest of P answers a question about the plaintext bytes; a digest of C answers a question about the container bytes.
A reviewer with P can compare it with an expected plaintext digest. A storage service that sees only C can compare the encrypted container with an expected ciphertext digest. Neither comparison should be silently described as the other.
Two deliveries of the same plaintext may produce different encrypted containers under a protocol that uses different nonces or other varying inputs. Therefore different ciphertext digests do not necessarily mean the underlying readable catalogue changed. Conversely, matching a ciphertext digest establishes only the relevant byte match; it does not prove the recipient can decrypt the package.
A file can also change at the byte level without an obvious visual difference. Metadata, line endings, embedded fonts, or a serialization choice may matter to the digest. Define whether the workflow compares original files or a specified canonical representation. Do not let the verification tool normalize data silently after a failure just to produce a match.
NIST’s Secure Hash Standard specifies hash functions, not a universal rule for what an application’s “document” means. The application must define its input object.
Back to contents · Next section
4. Authentication can protect visible context too
The delivery package may need some information to remain readable: a format version, a routing label, or a message identifier. That does not mean the information should be freely changeable without detection.
Authenticated encryption with associated data, usually shortened to AEAD, distinguishes encrypted content from associated data that is checked for authenticity and integrity but is not encrypted. RFC 5116 defines an interface for this pattern. The associated data is therefore not a place to put information whose confidentiality the museum has promised.
In our requirements discussion, “edition: draft-3” might be visible context that must be bound to the protected content. Whether it is represented as associated data or inside an authenticated message structure depends on the selected protocol. This article is not defining a custom encoding for it.
Equally important, authenticated context does not make replay impossible by itself. A previously valid package may still be delivered again. A recipient needs the protocol’s freshness and replay rules when those properties matter. RFC 5116 explicitly leaves anti-replay and access-control decisions outside its cryptographic interface.
The review question is therefore not merely “is this field encrypted?” Ask whether it should be secret, whether unauthorized changes should be detected, and how its meaning affects acceptance.
Back to contents · Next section
5. A signing key and a recipient key answer different questions
For a signature, a verifier needs the appropriate public verification information and a justified association with the claimed signer or role. For encrypted delivery, the sender needs confidence that the chosen recipient mechanism corresponds to the intended reader.
If the museum encrypts a draft perfectly for the wrong recipient key, the encryption can work exactly as designed while violating the intended audience requirement. Strong mathematics cannot repair the wrong destination association.
If the final catalogue is signed by a key that the reader cannot associate with the museum, the signature may be mathematically valid without establishing museum endorsement. The missing evidence concerns identity and authorization, not necessarily the signature algorithm.
NIST FIPS 186-5 defines digital-signature methods. Its role should not be confused with maintaining the museum’s publication directory or appointing a member of staff. Those are separate relationships that the workflow must establish.
The museum therefore uses two explicit questions in its review: who is allowed to read this package, and who is making this statement? A person may play both roles, but the design should not assume that their cryptographic objects, permissions, or key-management requirements are identical.
Back to contents · Next section
6. What does the signature actually endorse?
Imagine a signature that covers the encrypted container C. A verifier can check the relationship between that container and the signing key, but a reader who cannot decrypt C does not thereby learn its contents. The signature does not turn opaque bytes into a human-readable endorsement of every claim someone describes beside them.
Now imagine a signature over a release statement that names an edition and a digest of P. To connect the statement to the catalogue, the reader must verify the signature, check the statement’s meaning and authority, and compare the actual catalogue bytes with the named digest. Skipping the final comparison leaves the visible file unconnected to the signed statement.
Neither description is a recommendation to design a new signing format. It illustrates why coverage matters. The chosen protocol must define the signed representation, parsing, identifiers, and verification sequence. Ambiguous text such as “approved” without the relevant object and context may support less than its author intended.
Established message protocols illustrate that combination rules require specification. S/MIME version 4.0 addresses signed and encrypted message structures. It is a reference example of a defined protocol, not a blanket recommendation that every blockchain application should use email formatting.
For a project review, ask the implementer to describe the statement a successful verification actually establishes. If the answer is only “the green badge appears,” the meaning has not been explained sufficiently.
Back to contents · Next section
7. Map on-chain and off-chain audiences explicitly
The museum’s proposed record package has two locations. The document delivery service stores the protected draft off-chain. The registry stores a narrowly defined reference or release statement on-chain. Before using either, the team records who can observe it: invited reviewers, storage operators, network participants, or the wider public, depending on the actual system.
Putting readable content in a transaction payload does not become confidential because a copy elsewhere was encrypted. Similarly, an application event that emits a plaintext caption can disclose it even if the original file remains protected. The review follows the data through payloads, events, indexes and interfaces, rather than checking only the storage folder.
A transaction signature and a document-approval signature can also have different meanings. A service might be authorized to submit a registry update without being the curator who endorses the catalogue. The design must say whether it relies on the transaction’s authorization, a separately signed release statement, or both. It cannot silently convert submission authority into editorial endorsement.
The museum considers recording the final catalogue’s digest in a blockchain registry. That may provide an additional reference to a committed value within the relevant chain context. It does not encrypt a readable catalogue that has already been published elsewhere.
Nor does recording a digest make an inaccurate caption true. The registry can commit consistently to an error. The approval process, research evidence, and correction policy still matter.
A public plaintext digest can also reveal more than expected when the underlying content comes from a small set of plausible candidates. Someone can compare candidate digests. Therefore “we only published a hash” is not automatically a sufficient privacy analysis, especially for predictable fields or sensitive small-domain data.
For this workshop, all catalogue content is fictional and non-sensitive. The lesson is conceptual: decide what becomes public, including identifiers, timing, relationships, and commitments, rather than assume the use of a cryptographic function removes disclosure concerns.
A blockchain is one possible place for a reference. Whether it is necessary is a separate architecture question. The encryption, hashing, and signing requirements should remain clear even if the registry is replaced by a simpler authenticated publication channel.
Back to contents · Next section
8. Six delivery tests with answers
Test 1: The confidential draft is sent as plaintext with a correct hash. Has the readership requirement been met?
Answer: no. Anyone holding the plaintext can read it. The digest’s correctness does not add secrecy.
Test 2: A storage server substitutes a different file and supplies the matching new hash. The reader checks only that the two agree. Has the intended catalogue been authenticated?
Answer: no. The reader lacks an independently justified expected value or other evidence connecting the replacement to the intended release.
Test 3: The draft decrypts and passes the selected authenticated-encryption checks, but the final-release task requires public evidence of the museum’s endorsement. Is the draft’s success enough?
Answer: no. Successful protected delivery and publicly verifiable endorsement are different requirements. Check the actual signature or other evidence required by the release protocol.
Test 4: A signed release statement verifies, but its named plaintext digest does not match the attached catalogue. Should the application display the catalogue as endorsed?
Answer: no. The signature can be valid while the attachment is the wrong object. Preserve the distinction and report the failed binding.
Test 5: An encrypted package authenticates with visible associated data saying draft-2. The reader expected draft-3. Is authentication enough to accept it?
Answer: no. It may be an authentic older package. The application must apply the requested edition and freshness requirements.
Test 6: The museum removes a reviewer from future access after that reviewer already decrypted a draft. Does changing future permissions erase the earlier readable copy?
Answer: no. Future access control does not automatically recall information already disclosed. The retention and distribution policy must recognize this limit.
These tests use no cryptographic break. They fail through an unmet requirement, an incorrect object binding, or a mistaken assumption about what the operation guarantees. That is why comparison should start with the workflow, not with a list of algorithm names.
Back to contents · Next section
9. Build a requirements-to-evidence worksheet
For each artifact, write one short entry answering six questions:
- What exact object is protected or checked?
- Who should be able to read it?
- Who should be able to create an accepted statement about it?
- Which context, edition, and purpose must be bound to it?
- What evidence will the recipient actually verify?
- Which important claims remain outside that evidence?
For the public catalogue, the answers might specify the exact release file, unrestricted readership, an authorized publication role, edition and purpose, a verified signed statement plus a matching digest, and separate responsibility for factual review. For the confidential draft, the answers instead include the invited audience and the selected authenticated delivery protocol.
Then run failure cases against the worksheet. Replace the attachment, change the edition, use an unrecognized signer, select the wrong recipient, replay an older package, and make the required evidence unavailable. The expected behavior should be defined before a real incident occurs.
Do not implement these tests using actual private documents or keys in public tools. A test environment can use invented content and dedicated non-production material. The purpose is to evaluate the workflow’s logic without introducing a new disclosure problem.
Back to contents · Next section
10. The practical limits of adding cryptography
Encryption cannot make an authorized reader forget plaintext. A signature cannot force a recipient to inspect the signed object. A digest cannot preserve a file that every storage provider has deleted. None of the three can guarantee that a compromised endpoint will show the user an honest description.
These observations are not reasons to abandon cryptography. They identify the other responsibilities: endpoint security, identity binding, access policy, version management, storage, and human review. A clear design assigns each responsibility rather than attributing the whole outcome to one primitive.
The Advanced Encryption Standard specifies a block cipher. A claim that a product “uses AES” therefore does not, by itself, describe its complete encryption protocol, authentication behavior, nonce handling, or key management. The same caution applies to a product that merely lists SHA-256 or a signature algorithm.
A useful final explanation should sound like a set of checkable promises: this audience can recover this content; these modifications are detected under this protocol; this key endorsed this statement; this file matches that statement’s digest. Those claims are narrower than “everything is secure,” and much more useful.
Back to contents · Next section
Frequently asked questions
Is hashing a form of encryption?
No. A normal cryptographic hash has no decryption key that restores arbitrary original input. It produces a digest for defined uses such as comparison or commitment.
Does a digital signature hide a document?
No. A signature can be supplied with readable content. Confidentiality needs a suitable separate mechanism or a protocol that includes it.
Is authenticated encryption the same as a public digital signature?
No. Their verification models and key assumptions differ. In particular, shared-secret message authentication does not automatically supply public evidence of which individual key holder created a message.
Should I always hash, sign and encrypt everything?
No. State the requirements first and choose an established construction that meets them. Unnecessary or poorly specified combinations can make interpretation and implementation harder.
Back to contents · Next section
Sources and next reading
Sources checked on 12 October 2026, Singapore time. FIPS 197 was updated in May 2023 without a technical change to AES; FIPS 186-5 was published in February 2023 and its landing page notes potential errata. FIPS 180-4 is dated August 2015. RFC 5116 is dated January 2008; RFC 8551 is dated April 2019. The catalogue packages and tests are original teaching scenarios, not a new cryptographic protocol.
- NIST FIPS 180-4: Secure Hash Standard.
- NIST FIPS 186-5: Digital Signature Standard.
- NIST FIPS 197: Advanced Encryption Standard.
- RFC 5116: Authenticated Encryption interface.
- RFC 8551: S/MIME version 4.0.
Revisit addresses and identity if the signer or recipient association is unclear. The next article examines zero-knowledge proofs and the precise statement a proof can establish without disclosing all of its supporting information.