中文版 · Blockchain learning guide · Previous: Cryptographic Hashes
Blockchain learning · Article BC013
A digital signature lets someone check that a message was authorised by the relevant signing key, under a particular signature scheme’s assumptions. The private key supplies signing authority; the corresponding public key supports verification without revealing that secret.
This separation is powerful, but the conclusion is narrow. A valid signature does not automatically prove who was sitting at a device, what that person understood, whether the message is true or whether the requested action should succeed.
This guide follows a fictional document approval from signing to verification. It distinguishes key control, message meaning and application permission without asking you to create an account or handle a real secret.
Choose your reading route
In this guide
- 1. The key pair separates authority from checking
- 2. Three operations, with a different result from each
- 3. Signing is not “encrypting with the private key”
- 4. Worked example: approving an exhibition checklist
- 5. The exact message is the object of approval
- 6. Identity requires a binding beyond the raw key
- 7. A valid signature can still request an invalid action
- 8. Reusing a signature is not the same as obtaining new approval
- 9. Key compromise changes the meaning of a successful check
- 10. Public verification does not provide secrecy
- 11. A timestamp inside a message is still a statement
- 12. What a reviewer should check
- Paper exercise: four approvals that look similar
- Frequently asked questions
- Sources and scope
- Learn the mechanism: start with the key pair and the signing/verification sequence.
- Understand what is approved: read the worked document example and context checks.
- Evaluate a security claim: focus on identity, compromised authority and replay.
- Practise safely: use the paper verification exercise and answers.
Back to contents · Next section
1. The key pair separates authority from checking
In a public-key signature system, the private key is secret material used to produce signatures. The public key is information that other parties can use to verify them.
The mathematical relationship allows verification without giving the verifier the signing secret. Under the scheme’s security assumptions and appropriate implementation, possessing the public key should not make it feasible to forge valid signatures for arbitrary unauthorised messages.
This is different from sharing one password with every verifier. A public verification key is meant to be available for checking; the private signing authority is not.
Still, the public key’s availability does not identify its owner by itself. Someone must establish which key is relevant to the organisation, account or role being checked. Otherwise, a perfectly valid signature under an unrelated key answers the wrong question.
NIST’s Digital Signature Standard, FIPS 186-5, published 3 February 2023, is a primary reference for signature algorithms. It describes mechanisms, not a complete identity or organisational approval process.
Back to contents · Next section
2. Three operations, with a different result from each
Key generation creates the required signing and verification material according to the scheme. Secure generation and handling are part of the system, not an optional detail.
Signing uses the private signing authority and the message, together with any other scheme-defined inputs, to produce a signature. The exact process varies across algorithms; do not assume every scheme works by the same formula or uses randomness in the same way.
Verification checks the message and signature against the relevant public key and scheme rules. Its result supports or rejects that cryptographic relationship.
Verification does not require the verifier to receive the private key. If a supposed checking service asks for a real private key or seed phrase merely to verify a public signature, that request is inconsistent with the basic separation explained here.
This lesson remains conceptual. It does not provide key-generation code or recommend that beginners invent their own signature implementation.
Back to contents · Next section
3. Signing is not “encrypting with the private key”
A tempting shortcut describes signatures as encryption performed with a private key. That is not a reliable general explanation of modern signature schemes.
Encryption and signing have different goals and algorithms. Encryption protects confidentiality so that authorised decryption can recover plaintext. Signing supports verification of an authorised message. A signed message may remain fully readable.
A signature can involve hashing and other mathematical operations, but calling it encryption can make readers expect a secrecy guarantee that is not present. It can also lead them to misunderstand how particular algorithms actually work.
The safer explanation is functional: the signer creates a scheme-defined signature for a message; the verifier checks that signature with the public verification key.
This language remains correct without pretending that every signature scheme is a reversed encryption operation.
Back to contents · Next section
4. Worked example: approving an exhibition checklist
Imagine an adult curator, Lina, is authorised to approve a fictional exhibition checklist for internal planning. The organisation recognises a particular public key for that approval role.
The document has a version identifier and a fingerprint. The proposed approval message says which version is covered and what the approval means. For this example, it means approval for internal planning, not permission to publish or a guarantee that every statement has been independently investigated.
Lina’s signing system produces a signature over the defined approval message. A reviewer later obtains the message, signature, relevant public key and the document needed for the intended comparison.
The reviewer checks that the file matches the stated version and that the signature verifies under the recognised key. It also checks whether that key was authorised for this approval purpose under the organisation’s process.
These steps support a bounded conclusion about a version and its approval authority. They do not automatically establish Lina’s physical presence, perfect judgment or the truth of every caption.
Back to contents · Next section
5. The exact message is the object of approval
“Approve version seven” and “acknowledge receipt of version seven” are different messages. So are “approve for internal review” and “approve for public release.”
A user interface should make the authorised content understandable. If the screen displays a harmless summary while the signed bytes authorise something broader, the signature may verify even though the human interaction was misleading.
Structured messages need a defined representation and interpretation. A signature protects the message specified by the signing process, not whatever a later website chooses to describe in a badge.
W3C’s Verifiable Credential Data Integrity 1.0, a Recommendation dated 15 May 2025, treats proof purpose, verification relationships and data processing as part of the surrounding design. This illustrates why the mathematical signature check is only one step.
A strong review therefore asks both “does the signature verify?” and “what, exactly, does the verified message authorise?”
Back to contents · Next section
6. Identity requires a binding beyond the raw key
Suppose a file is signed by Public Key K. The cryptographic check may be correct, but who is K?
An application may use an account registry, certificate arrangement, organisational directory or another identity mechanism to connect the key to a role. The mechanism has its own maintenance and trust assumptions.
If the reviewer obtains the key from the same untrusted message that claims to be from the museum, a valid signature only shows consistency with that supplied key. It does not independently establish the museum’s approval.
The key must be connected to the intended authority through an appropriate trusted process. That binding can also change over time when staff roles or keys change.
This is why public key, account address, organisation name and legal person should not be treated as interchangeable labels. They can be connected, but the connection must be explained and checked.
Back to contents · Next section
7. A valid signature can still request an invalid action
Now imagine the approval key is allowed to approve internal drafts but not public releases. It signs a public-release request.
The cryptographic signature could verify correctly. The application should still reject the action if the role lacks that permission. Signature validity and policy validity are separate checks.
The same distinction appears in blockchain transactions. A key can authorise a message while the requested action fails because the relevant balance, state, permission or other protocol condition is not satisfied.
Ethereum’s transaction documentation is one concrete example of authorisation within a wider transaction process. Different networks define their own fields and rules.
A useful rule of thought is: verification tells the application something about the message’s signing authority; the application must still decide whether the authorised request is allowed in the current context.
Back to contents · Next section
8. Reusing a signature is not the same as obtaining new approval
A recorded signature can remain mathematically verifiable when shown again. That does not mean an application should execute its action repeatedly or accept it in every context.
Return to Lina’s checklist. Approval of one identified version for one purpose should not silently become approval of a different version or a different purpose. The protocol needs to bind the relevant context into what is signed and checked.
Transaction systems also need ways to prevent inappropriate replay. Counters, spending conditions, identifiers and domain-specific context can contribute, depending on the design. The exact mechanism must be evaluated for the actual protocol.
Ethereum’s account documentation describes a transaction counter in its account model. Bitcoin instead uses spending conditions around outputs, among other transaction rules. These are examples, not a universal recipe. Ethereum accounts · Bitcoin transactions.
The conceptual point is that old evidence of authorisation is not automatically fresh authority for a new action.
Back to contents · Next section
9. Key compromise changes the meaning of a successful check
If an attacker gains control of signing authority, it may produce signatures that pass verification. The algorithm has not necessarily failed; the assumption about who controls the key has failed.
The organisation then needs procedures for stopping future misuse, establishing replacement authority and explaining which earlier records may be affected. The signature alone does not reveal the precise moment the key became compromised.
Likewise, losing access to a private key can prevent further signing even when the public records remain visible. Cryptographic verification does not restore a missing signing capability.
NIST’s Recommendation for Key Management, Part 1 Revision 5 explains that key management spans a lifecycle. This lesson uses that principle without prescribing an operational recovery process for a particular wallet or institution.
Protecting signing authority and planning its replacement are different tasks from checking a signature once.
Back to contents · Next section
10. Public verification does not provide secrecy
A digital signature can be publicly verifiable while the signed message is also public. That is often useful: many readers can check the same approval without receiving any secret signing material.
But signing does not hide the message. If a document needs confidentiality, the application requires a separate design for limiting disclosure.
Public keys and signatures can also create linkable records depending on how they are used. Calling a key “public” does not mean every possible use is irrelevant to privacy.
For the exhibition example, publishing a signed internal checklist might reveal information the organisation intended to keep restricted. The validity of the signature does not make that disclosure appropriate.
Always ask two separate questions: who can verify the statement, and who is allowed to learn its contents?
Back to contents · Next section
11. A timestamp inside a message is still a statement
A signed message may contain a date or time. The signature can protect that stated value from undetected alteration within the signed content, but does not by itself prove the clock was accurate or that signing occurred at that exact moment.
An application that needs stronger evidence about time requires an appropriate timestamping or recording arrangement and a clear account of what that arrangement establishes.
Similarly, inclusion in a ledger can provide protocol-specific ordering or recording evidence, but should not be casually expanded into proof of every real-world event time.
In Lina’s case, a field saying “approved at noon” is part of the statement. Whether the organisation can rely on that as an exact time depends on the surrounding process.
The broader lesson is to distinguish protected content from independently established truth about that content.
Back to contents · Next section
12. What a reviewer should check
A conceptual review can use six questions.
- Message: which exact content and purpose were signed?
- Scheme: which signature method and verification rules apply?
- Key binding: why is this public key recognised as the relevant authority?
- Permission: was that authority allowed to perform this action?
- Context: does the message belong to this version, system and intended use, and is reuse handled correctly?
- Key status: what does the application know about replacement, loss or compromise under its policy?
Not every application expresses these checks in the same format. The checklist is an educational map of responsibilities, not a claim that a single signature API performs them all.
A green check mark should ideally make its meaning clear. “Signature verified under this key” is narrower than “document approved, accurate and safe for all uses.”
Back to contents · Next section
Paper exercise: four approvals that look similar
Use a fictional public key label, Museum-Approval-Key, rather than any real cryptographic material. Assume the museum has authorised it only for internal checklist approval.
Case A: a correctly signed message approves version seven for internal planning. The file matches that version.
Case B: the signature is mathematically valid, but the message approves public release.
Case C: the message says internal approval, but the file supplied is version eight.
Case D: the signature verifies under a different key supplied by an unknown sender, who claims it belongs to the museum.
Which checks are satisfied, and what remains wrong?
Worked answers
Case A fits the stated authorisation and version conditions, assuming the recognised key and other policy requirements remain valid. It still does not certify every fact in the document.
Case B passes the signature check but exceeds the role’s stated permission.
Case C does not support approval of the supplied file. A valid signature about one version should not be transferred to another.
Case D lacks the trusted binding between the supplied key and the museum. Mathematical consistency with an unknown key is not enough.
The exercise separates four questions that a simple “signed” badge can hide.
Back to contents · Next section
Frequently asked questions
Can the public key create signatures?
Public verification material is not intended to supply private signing authority. Under the scheme’s assumptions, knowing it should not make arbitrary signature forgery feasible.
Must I send my private key to someone who verifies a signature?
No. Public-key verification is designed to work without revealing the signing secret. Do not provide a real private key or seed phrase for a basic public-signature check.
Is a digital signature a picture of handwriting?
No. A scanned handwritten mark is an image. A cryptographic digital signature is a scheme-defined value checked against a message and verification key. An application may display an image, but the image is not the cryptographic mechanism.
Does a valid signature settle every dispute?
No. Message meaning, identity, authority, key status and external facts can still be disputed. This article explains technical evidence rather than giving a legal determination.
Back to contents · Next section
Sources and scope
The foundational research reference was dated 12 October 2026, Asia/Singapore. Primary standards and protocol documentation were checked during preparation. All people, documents and key labels in the exercise are fictional; no real signing credentials are used.
- NIST FIPS 186-5: Digital Signature Standard, 3 February 2023; consult listed updates for implementation work.
- W3C Verifiable Credential Data Integrity 1.0, Recommendation, 15 May 2025: proof purpose and verification relationships around cryptographic checks.
- NIST SP 800-57 Part 1 Revision 5: general key-management lifecycle.
- Ethereum: Transactions and Accounts: one authorisation and state model.
- Bitcoin: Transactions: a different transaction and spending-condition model.
A signature is strongest when the key, message, purpose and permission are all understood. Verification begins with mathematics and ends with a carefully bounded interpretation.