The last primitive completes the set, and it is the one finance leans on most. Confidentiality hides a message; integrity proves it was not changed; but neither answers the question a bank asks first: did the real account holder actually authorize this? The digital signature answers it. It is public-key cryptography run backward — sign with your private key, and anyone can verify with your public key that the message genuinely came from you and was not altered, and you cannot later deny it. This module makes it real: you will sign a message with a private key, watch anyone verify it with the public key, then tamper with the message and watch the signature break. It is the mechanism that authorizes a Bitcoin spend, validates a software update, and lets your browser trust your bank.
We now have three of cryptography's tools. The hash (Module 02) gives integrity — proof a message was not altered. Symmetric encryption (Module 03) and public-key encryption (Module 04) give confidentiality — secrecy. But recall from Module 01 that finance's first question about any instruction is not "is it secret?" or even "was it changed?" It is "did the real account holder actually authorize this?" — the question of authenticity. None of the tools so far answers it.
See why this is the gap that matters. Imagine a payment instruction arrives at a bank, perfectly encrypted and perfectly intact. It is secret and unaltered — and still worthless, even dangerous, unless the bank can be certain you issued it and not a fraudster. Encryption hides a message but says nothing about who wrote it; a hash proves a message is unchanged but not who it came from. Authenticity — proving origin, and binding the sender to what they sent — is the missing third job, and for finance, where almost everything is an authorization to move money, it is arguably the most important of all.
The tool that delivers it is the digital signature, and here is the elegant part: we do not need a new idea for it. The digital signature is the public-key cryptography of Module 04, simply run backward. That last module ended on the hint — locking with your private key instead of your public key. This module follows that thread to its conclusion and, in doing so, completes the four primitives and unlocks the third and last of cryptography's jobs.
Authenticity proves who sent a message — the question encryption and hashing cannot answer. A payment instruction that is secret and unaltered is still worthless unless the bank knows the real account holder authorized it. The digital signature delivers authenticity (plus integrity and non-repudiation), and it is simply public-key cryptography run in reverse.
In Module 04, the two keys worked like this: anyone locks with your public key, and only you unlock with your private key. That direction gives confidentiality — secret messages to you. The digital signature reverses the roles: you lock with your private key, and anyone unlocks with your public key.
At first this seems pointless — if everyone has your public key, then everyone can "unlock" it, so nothing is secret. Exactly right: a signature is not about secrecy. Its power is in the logic of who could have done the locking. Since only you hold your private key, only you could have produced something that your public key successfully opens. So when your public key opens it, that is mathematical proof the thing was created with your private key — that is, by you. You have not hidden the message; you have stamped it with proof of authorship that no one else could forge.
This is the precise mirror image of confidentiality, and the symmetry is beautiful: the same pair of keys does both jobs depending on which one you start with. Start with the public key (anyone locks, you unlock) and you get secrecy — messages only you can read. Start with the private key (you lock, anyone unlocks) and you get a signature — proof only you could have sent it. One idea, two of cryptography's three jobs, just by choosing which key goes first.
A digital signature is public-key cryptography reversed: you "sign" with your private key, and anyone "verifies" with your public key. It hides nothing — anyone can verify. Its power is that only your private key could have produced something your public key accepts, so a successful verification is proof the message came from you and no one else.
There is one refinement that makes signatures practical, and it reunites two primitives you already know. Public-key operations are slow (Module 04) and awkward on large data, so you do not sign a whole document directly. Instead — exactly as Module 02 previewed — you hash the document to its fingerprint, then sign the fingerprint.
The logic is airtight once you combine the two properties. The hash is a compact, faithful stand-in for the document: it changes completely if the document changes at all (the avalanche effect) and no one can find a different document with the same fingerprint (collision resistance). So signing the small fingerprint is as good as signing the entire document — and far faster. To verify, you do two things: recompute the document's fingerprint yourself, and use the public key to check the signature against it. If they match, two facts are proven at once: the signature was made by the private-key holder (authenticity), and the document is exactly what they signed (integrity), because any change would have altered the fingerprint and broken the match.
This is why the digital signature is so powerful: it delivers two of cryptography's three jobs in a single mechanism. Sign the fingerprint with your private key and you simultaneously prove who (authenticity) and unchanged (integrity) — and, because only you could have signed, you also get non-repudiation: you cannot later credibly deny having signed it, since no one else could have produced the signature. Authenticity, integrity, and non-repudiation, all from hashing (Module 02) plus public-key cryptography run backward (Module 04). The whole track's primitives converge here.
You sign a document by hashing it to a fingerprint and signing the fingerprint with your private key. Verifying recomputes the fingerprint and checks the signature with the public key. A match proves both authenticity (only your private key could sign) and integrity (any change to the document would alter the fingerprint and break the match) — plus non-repudiation. Two primitives, three jobs.
Use the same real RSA key pair from Module 04, now run backward to sign. Type a message (say, a payment instruction). The signer hashes it to a small fingerprint and signs that fingerprint with the private key (d = 2753), producing a signature. Press Sign to send the message and signature to a verifier. The verifier — who has only your public key (e = 17) — recomputes the fingerprint and checks the signature, and reports VALID. Then comes the crucial part: edit the "message as received" and watch verification instantly turn INVALID, because the fingerprint no longer matches what was signed.
Edit a single character of the received message and the verdict flips to INVALID at once. That is integrity and authenticity working together: the verifier recomputes the fingerprint of the message actually received, and the public key tells them what fingerprint the signer actually signed. If the two disagree, either the message was altered in transit or the signature was forged — and in both cases the verifier rejects it. Notice the verifier never had the private key; the public key alone was enough to check, but never enough to forge. That asymmetry is the whole point, and the next demo drives it home.
The security of a signature rests entirely on one fact: producing a valid signature requires the private key, but checking one requires only the public key. An attacker who wants to forge your signature faces an impossible task — they would need to produce a number that your public key turns back into the correct fingerprint, but doing that requires the private key they do not have. They can verify all day; they can never sign.
Watch a forger try. Below, an attacker has the message and your public key (both public) and wants to forge a signature for a fraudulent instruction. They can type any signature they like — but without the private key, nothing they produce will verify. Try to forge one:
The attacker knows the message and the public key (e = 17, n = 3233). They guess a signature number. Only a signature made with the private key will verify — guessing is hopeless.
No guess works, because the attacker is trying to hit a specific target — the message's fingerprint — by running the public key on a number, and only the private key can find an input that lands there. With the tiny numbers here a patient attacker could eventually stumble onto it by brute force; with real key sizes (hundreds of digits) it is, as far as anyone knows, computationally impossible, even for all the world's computers. The signature is unforgeable for the same reason the private key cannot be derived from the public key: the underlying math is easy in the signing direction and effectively impossible in the forging direction. That one-way hardness is what lets a signature stand as proof.
Anyone can verify a signature with the public key, but only the private-key holder can create one. A forger trying to fake your signature would need to produce a value your public key maps to the right fingerprint — which requires the private key they lack. Verifying is easy; forging is effectively impossible. That asymmetry is what makes the signature trustworthy proof of authorship.
A verified digital signature delivers three guarantees at once, and it is worth naming them together because finance needs all three:
This triple guarantee is why digital signatures are woven through the entire financial and digital world. A few examples you have already met or soon will:
In each case the same mechanism is at work: hash the thing, sign the fingerprint with a private key, verify with the public key. Master this one idea and you understand the authorization layer of nearly all digital finance.
There is a crack in everything we have built, and spotting it is the bridge to the next module. Digital signatures and public-key encryption both rest on using someone's public key — you verify my signature with my public key, you encrypt to your bank with your bank's public key. But a question has been quietly assumed away: how do you know a public key really belongs to who you think it does?
Consider the danger. Suppose you want to send an encrypted instruction to your bank, so you look up "the bank's public key." But an attacker has slipped their own public key in front of you, labeled as the bank's. You encrypt with it, believing it is the bank's — and now only the attacker can decrypt your message. Or in reverse: an attacker publishes a public key claiming to be your bank, signs fraudulent messages with the matching private key, and your software happily verifies them as genuine. The cryptography worked perfectly; it just bound to the wrong key. This is the man-in-the-middle problem, and it shows that public-key cryptography solves how to use keys but not, by itself, how to know whose key you hold.
This is not a flaw in the signature or in public-key cryptography; both did exactly what they promised. It is a binding problem: nothing so far ties a public key to a real-world identity. Solving it needs a way to vouch — reliably, at internet scale — that "this public key really belongs to this bank." The solution turns out to use digital signatures themselves, arranged into a chain of trusted vouchers called a public-key infrastructure, with certificate authorities signing statements about who owns which key. That structure — the thing that actually lets your browser trust your bank — is the subject of the next module, and it is where the primitives you have now finished assembling get put to work securing the real world.
Step back: with the digital signature, the four primitives are done, and together they cover all three jobs of cryptography. The hash gives integrity — the fingerprint. Symmetric encryption gives fast confidentiality — the shared lockbox. Public-key cryptography gives confidentiality between strangers and solves key distribution — the two-key padlock. And the digital signature, public-key crypto run backward and fused with the hash, gives authenticity, integrity, and non-repudiation at once — proof of who. That is the complete toolkit, and remarkably it is built from just a few ideas, recombined.
Notice how they interlock, because real systems use them together, never alone. A single secure connection to your bank uses all four: public-key cryptography to agree on a shared key with a stranger; symmetric encryption to protect the bulk of the session quickly; hashing to check integrity; and digital signatures (via certificates) to prove you are really talking to your bank. The primitives are not four separate tricks but one interlocking system, each covering the others' gaps — the slow-but-stranger-friendly public key handing off to the fast-but-needs-a-shared-key symmetric cipher, the hash making signatures practical, the signature proving identity that encryption alone cannot.
The track now turns from what the primitives are to how they secure the real financial world. The immediate next step follows directly from the gap we just found: the digital signature can prove a message came from a given key, but how do we trust that the key belongs to the right party? Module 06 answers it with public-key infrastructure — certificates, certificate authorities, and the chain of trust that lets your browser confirm a bank's website is genuine, securing every online transaction. From there the track moves to the cryptography inside your payment cards, and then to the full Bitcoin and blockchain stack — all of it built on the four primitives you have now completed.
Six questions on digital signatures — public-key crypto run backward, signing the fingerprint, the three guarantees, why forgery fails, and the key-binding gap. The questions test the concepts you just saw in action.