Digital Signature Comic Classroom: Did You Really Send This?

A familiar name is not proof

The robot receives a repair notice bearing the name MY. The fee is 100 units, the layout looks familiar, and it is about to pay. The teacher stops it: recognizing a name is easy. Establishing who put that name on this particular notice takes something more.

This fictional repair story resembles an email or download notification. To a computer, a sender name, portrait, and printed signature can all be ordinary data fields. Someone who can replace those fields can reproduce the appearance without having the claimed person's authority.

There is a second problem even when the notice really started with MY. Someone on the delivery path could replace 100 with 900 and leave the sender field untouched. Establishing the source and detecting changes to the content answer different questions. Getting only one answer right can still lead the robot to make a bad decision. ^[2]

The HRoT lesson protected keys and the authority to use them. Here we follow what a protected private key can do for a message: create evidence that another party can check. The notice gives every later term a concrete job before we ask the reader to remember its name.

A copied seal can travel to another document

The robot suggests a stamp. The attacker cuts the stamp image out of the original notice and pastes it onto a new one. The fee now reads 900. Nothing about the copied artwork tells the robot that it belongs beside 100 instead.

Paper documents may be assessed using handwriting, the physical sheet, and the delivery process. A scanned signature is much easier to duplicate as a file. Its familiar appearance alone does not establish that the surrounding text is what the signer approved.

A digital signature establishes a mathematical relationship involving the message and the signing key. Verification checks the message that was actually received. An attacker should not be able to reuse the evidence for one message as valid evidence for a different one. Decorative complexity contributes nothing to that property. ^[1]

A PDF can display a handwritten signature image and also contain a cryptographic signature. Those are separate features: one helps a human recognize a mark, while the other participates in a computation. Before looking at that computation, it helps to understand how software represents a long document with a short digest.

A short digest for a long message

A hash function takes the notice and produces a fixed-length digest. Think of it as a computed fingerprint: identical input bytes processed by the same function produce the same output. The colored tiles in the comic are visual markers, not real digest values that software should use. ^[5]

Changing 100 to 900 will ordinarily change the digest substantially. This makes hashes useful for detecting differences. It does not make collisions impossible. There are only finitely many outputs of a fixed length and far more possible messages. A secure design requires that attackers cannot efficiently find collisions they can exploit. ^[5]

A digest contains no compressed representation from which the full notice can be recovered. It also does not automatically conceal an easily guessed message. With only a few possible amounts, an observer can hash each candidate and compare it with the known digest. Finding an arbitrary preimage and guessing a notice from a small candidate set are different tasks.

The digest has given the robot a way to compare content, but it has not answered where the expected value came from. If the notice and the expected digest arrive together along a path the attacker can alter, both can be replaced. That is the next step in the story.

Replace the file and its digest together

MY hashes the 100-unit notice, obtaining digest A, and sends the pair. The attacker changes the fee to 900 and runs the same public hash function to obtain digest B. The robot receives the altered notice accompanied by B.

The robot follows its instructions perfectly. It hashes the received notice, obtains B, and reports a match. That match establishes consistency between two received objects. It does not establish that MY ever issued either of them.

No hash function has been broken. Anyone can compute a public hash over data of their choice. Substituting a different secure hash would not fix a delivery path that lets an attacker replace both the message and the reference value.

A digest obtained through a separately authenticated channel can still be useful. The lesson is to trace why the reference is trusted, rather than dismiss hashing itself. A digital signature lets the verifier connect the message check to a trusted public key; it will then matter how that key earned its place. ^[2]

Public verification without public signing power

MY prepares a mathematically related key pair. The private key stays under the signer's control and creates signatures. The public key can be distributed to the robot and other readers so that they can check those signatures for themselves.

These are not two spare keys with identical powers. Knowing the public key should not enable an attacker to efficiently recover the private key or forge signatures on arbitrary new messages. That asymmetry depends on a suitable scheme, adequate parameters, and a correct implementation. ^[1]

The repair notice can remain openly readable throughout this process. A signature checks a relationship between data and a key; it does not hide the amount. Encryption addresses who can read content. Signatures provide verifiable evidence about origin and integrity under the relevant trust assumptions. ^[2]

Readers of the RSA lesson may remember operations with public and private exponents. It would be a mistake to generalize those into private-key encryption as a definition of signing. Signature schemes use different algorithms, and verification is not a universal procedure that decrypts a signature into the original message.

For now, assume the robot really has MY's public key. We will deliberately remove that assumption on page 8. Keeping it visible prevents a convenient classroom shortcut from becoming an unnoticed security claim.

Follow the complete signing and verification path

Let m stand for the message, sk for the private key, and s for the signature. The notation s = Sign(sk, m) describes a procedure that takes the key and this message and produces a signature. It is an input-output description, not an instruction to invent a cryptographic implementation.

MY sends m and s while keeping sk at the signing endpoint. The robot supplies its trusted public key pk and runs Verify(pk, m, s). The result says whether that key, message, and signature satisfy the chosen scheme's verification rules.

The robot never needs MY's private key to perform this check. Giving it that key would also give it signing power and destroy the intended separation. Only the message and signature cross the delivery arrow in the diagram.

Hashing has an important role in common signature schemes, but its placement depends on the scheme and library interface. Some interfaces accept a complete message; others explicitly accept a precomputed digest. Application code must not add a hashing step and assume that the receiver will interpret the result the same way. ^[3]

Both endpoints therefore need an agreed message representation and signature scheme as well as keys. Once those are fixed, we can change one field in the repair notice and observe exactly which verification check stops succeeding.

Change the amount while keeping the old signature

MY signs the 100-unit notice, producing s. Verification with MY's public key succeeds. Now change only the received amount to 900, keeping s and the same public key, and run the check again.

For the distinct messages in this example and a correctly implemented secure scheme, the altered notice fails verification. Copying the original signature does not turn it into evidence for a new amount. An attacker would need the corresponding signing capability or a break in the scheme or its implementation assumptions. ^[1]

The checked object is the data actually supplied to signing, not a human interpretation of its meaning. Documents that look alike can have different bytes because of whitespace, line endings, or encoding. A delivery system that rewrites those bytes can make an honestly issued message fail verification too.

The reverse problem matters as much. If an application signs the amount but leaves the recipient outside the protected data, an attacker might change the recipient while the amount's signature remains valid. The signed format must include every field on which the security decision depends.

An invalid result does not by itself diagnose fraud. A wrong key, damaged file, or representation mismatch can also cause failure. The safe response is to stop relying on the evidence and investigate, rather than ignore verification just to keep the workflow moving.

A valid signature under the wrong person's key

The attacker stops modifying MY's signed notices. Instead, they generate their own key pair, sign a new notice with their own private key, and send the corresponding public key alongside it. The accompanying claim says, This is MY's public key.

Verification succeeds. The mathematics has done exactly what it was asked to do: the signature fits the message and the supplied public key. The mistake was attaching MY's identity to an unfamiliar key without evidence.

A successful check can first be read as this signature is valid for this data under this key. Saying MY signed it requires a trustworthy connection between the key and MY, as well as appropriate control of the private key. A claim supplied by the same unverified sender cannot create that connection by itself. ^[1][4]

A system might provision a trusted public key in advance, confirm its fingerprint through an already authenticated channel, or use certificates under an established trust policy. The appropriate method depends on manufacture, update authority, and the parties the device must recognize.

We leave certificate paths for the next lesson. For now, the useful habit is to look past the green checkmark and ask which key it refers to. Certificate and PKI mechanisms will address who vouches for that key and why the verifier accepts the vouching party.

What a valid signature leaves unanswered

MY can make an honest mistake in the repair estimate and then sign it. The signature may be perfectly valid. Verification checks the data-key relationship; it does not recalculate the correct repair price. Evidence of origin leaves factual accuracy as a separate question.

Yesterday's notice poses another problem. An attacker can resend a previously valid payment instruction without changing a byte. The signature does not automatically expire because the calendar moved forward. The receiver needs rules and state to determine whether the request has already been handled or remains within an allowed period.

Confidentiality is separate too. A bystander can still read a notice sent in plaintext. Attaching a signature does not encrypt it. NIST's definition explicitly distinguishes origin and integrity protection from confidentiality and replay protection, which signatures do not provide on their own. ^[2]

The term non-repudiation needs care. A signature can provide evidence for another party to examine, but treating it as proof that a person can never dispute an action goes too far. Identity binding, private-key custody, and possible compromise affect the conclusion; legal consequences also depend on the relevant institutions and rules. ^[1][4]

The robot ultimately has to decide whether to pay. It must still establish that the issuer has the right authority, the notice applies to this transaction, and execution is appropriate now. A green cryptographic check is an input to that decision rather than a replacement for it.

Protect the authority to sign as well as the key

MY places the private key inside protected hardware where ordinary software cannot read it. That sounds reassuring. Yet if every program can ask the hardware to sign any notice, an attacker may submit a fabricated notice and receive a genuinely valid signature.

No key has leaked in that case. The signing service has been abused. Alongside secret data, the HRoT must protect decisions about who can request an operation, which operation is allowed, and whether the current state permits it. The previous lesson's access control now has a concrete purpose.

A repair service might be restricted to a defined notice format and requests from an approved program or workflow. Sensitive deployments may add authorization steps and audit records. These are controls a system can implement, not features that appear automatically merely because a security chip is present.

If a private key is actually copied, the attacker may continue signing outside the device. Restarting the system or changing an interface password does not erase that copy. The system needs a way to stop trusting the compromised key, establish replacement material, and communicate the change to verifiers. ^[4]

Later units will cover rotation and revocation in detail. Here the distinction is enough: preventing key extraction and preventing unauthorized use of signing power are two defenses that must work together.

Different schemes preserve the same role split

By now the purpose of a signature is familiar. When RSA, ECDSA, or EdDSA appears in a document, place it in the same role diagram first: the signing endpoint holds a private key and the verifier uses a public key.

RSA mathematics can underpin signature schemes as well as encryption schemes. Those uses have their own rules. The tiny encryption example from the RSA classroom is not a production signing recipe, and sharing the RSA name does not make complete workflows interchangeable.

ECC describes the elliptic-curve cryptography field and its mathematical foundation. ECDSA and EdDSA are distinct signature schemes built on elliptic curves. FIPS 186-5 includes signature provisions for RSA, ECDSA, and EdDSA, while RFC 8032 describes specific EdDSA variants. ^[1][3]

There is no need to derive three algorithms here. When implementing a system, however, engineers must specify the actual scheme, parameters, and library interface. We use ECC is not enough information for another party to implement verification. Input validation and the boundaries around key use matter as well.

The relationship map helps readers find the right level in a product description. Identify the signing or verification role, determine the exact scheme, and then return to public-key trust and the policy governing its use.

Return to the notice and trace the failure

Return to the notice from page 1. A sender name no longer persuades the robot on its own, and a digest beside the message is not enough to authorize payment. The robot needs to know which trusted public key to use, which data was signed, and which signature it is checking.

If 100 became 900 while the signature stayed the same, verification should reject the altered data. If the attacker substituted a public key and called it MY's, the failure lies in key-identity trust. Both attacks can produce a fraudulent notice, but they require fixes at different points.

If MY genuinely signed the notice and it was simply resent, processing records and freshness rules matter. If the attacker controlled access to the signing service, investigate caller authorization. Following the path prevents every failure from being blamed on an allegedly weak algorithm.

A digital signature connects data to a particular key and supplies checkable evidence. Identity, authority, and time determine which action that evidence can justify now. Hardware security needs these services to cooperate because the cryptographic check covers only part of the decision. ^[2]

One question remains: if I have never seen MY's public key, who can vouch for it? Certificate and PKI mechanisms start there. Once the key's identity has a trustworthy basis, Secure Boot can use signature verification in the startup path, and we can ask exactly what a chip is trusting when it begins to run.

Five ideas to take with you

1. A name or copied stamp is not evidence that binds a sender to this particular message.
2. A hash match needs a trustworthy reference; an attacker can replace both an unprotected message and its attached digest.
3. The private key signs; the public key verifies. Signing does not hide the message.
4. A valid signature still needs a trusted key identity, appropriate authority, and freshness checks.
5. Protect access to signing as well as the secret key; an attacker may abuse a service without extracting its key.

Next: Certificate & PKI. Who vouches for an unfamiliar public key, and why should the verifier trust that claim? Secure Boot will later connect these foundations to a chip's startup path.

References

1. NIST, Digital Signature Standard (FIPS 186-5, 2023): Signature roles and the RSA, ECDSA, and EdDSA schemes.
2. NIST CSRC Glossary, Digital signature: Authenticity and integrity; no confidentiality or replay protection by itself.
3. RFC 8032, Edwards-Curve Digital Signature Algorithm (EdDSA), 2017: PureEdDSA and prehash variants use different processing rules.
4. NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management, 2020: Key protection, authorized use, and compromise handling.
5. NIST FIPS 180-4, Secure Hash Standard, 2015: Message digests and the standardized SHA functions.