Cryptography › Module 2 › Lesson 4
Digital Signatures
Prove who signed a message and that it was not altered in transit
Opening
Encryption hides. A signature proves: the private-key holder signed this, and the bytes did not change.
You can read a signed software update in plaintext and still trust it. That sentence is the whole split. AES hid a toy note. RSA wrapped a tiny secret. PKI bound a name to a public key. Digital signatures use the private half as a pen: hash the message, sign the digest, ship message + signature. Anyone with the matching public key hashes again and verifies. Success means integrity (not altered) plus authenticity (produced with that private key). It does not mean confidentiality. It does not mean the signer is a saint. It means the key that PKI (or another out-of-band check) told you to trust produced this signature. Optional lab: openssl dgst -sha256 -sign on a file YOU created in $HOME/cyberlium-lab, using a TOY key you delete. You will not forge signatures as an attack. You will not steal a company’s signing key. You will not “bypass” update signatures. Next is the module quiz, then TLS — where signatures sit inside certificates and the handshake.
1. Mechanism: hash the message, sign the digest with the private key
Signing the entire movie byte-for-byte with raw RSA would be slow and size-awkward, same hybrid lesson as encryption. The practical pattern is: cryptographic hash (Module 1 — SHA-256 class) over the message → fixed-size digest → sign that digest with the private key using a proper scheme (RSA-PSS, ECDSA, Ed25519 in real systems). openssl dgst -sign is the beginner-visible form of “hash then sign.” The signature is a separate blob (or an attached format). The message can remain readable. That is not a bug. That is the point when the goal is proof, not secrecy.
Do not homebrew a signature from openssl enc or XOR-a-hash. Libraries exist because padding is the security. openssl dgst on YOUR file is literacy, not a product signing pipeline. Code-signing, git -S, and TLS certs share the same beats: digest, private-key operation, public-key verify.
2. Verify with the public key: authenticity plus integrity, not a lockbox
The verifier starts from the public key they already believe belongs to the signer — via PKI, a pinned key, or a handoff you actually trust. They hash the received message, run the verify algorithm on (digest, signature, public key). Match: the message is the one that was signed, and the signer possessed the private key (assuming the public key is the right one). Mismatch: the message changed, the signature is for a different file, the key is wrong, or the signature is garbage. Fail closed. “It looks like the PDF I expected” is not verify.
Integrity here is “bit-for-bit what was signed,” not “the contents are true.” A signed lie is still a lie. Authenticity is “this private key,” not “this human had good intentions.” If Mallory swaps the public key you use to verify, she can make her own signatures verify — that is why lesson 3 existed. If Mallory alters the message but not the signature, verify fails. If she strips the signature, a client that requires signatures fails. A client that treats signatures as optional will accept the altered file. Software updaters that fail closed are why you are not running random internet executables every Tuesday.
What a successful verify bought you — and what it did not.
Integrity
The bits match what was hashed-and-signed. One flipped bit should fail verify (hash avalanche + signature).
Authenticity
The private key matching this public key produced the signature. PKI still has to name that key.
Not confidentiality
The message can be public. Sign then encrypt if you need both; do not assume sign hid anything.
Not permission to forge
Without the private key you cannot produce a verifying signature. Do not practice forgery against others.
3. Where you already depend on this: updates, certs, git, documents
OS and browser updates verify a vendor signature before installing. TLS certificates are signed by CAs (lesson 3). Package managers check signatures or hashes pinned by a signed repo metadata chain. git commit -S is optional proof a key holder authored a commit — still not proof the commit is a good idea. Document signing (PDF, office) is the same shape with more wrappers. As a defender, a failed signature is a stop. As a beginner, “I will forge an update to test the class” is malware practice aimed at a trust system. Out of scope. Always.
4. Wrong vs right: forging pens vs openssl dgst on YOUR file
Worked failure — treating signatures as encryption, or as a CTF to impersonate a vendor.
Wrong
Tell a teammate a signed README is secret because it is “crypto.” Copy a company’s public update signature onto your malware and hope. Try to forge a CA signature. Sign other people’s files without asking. Commit a toy private signing key. Skip verify because “the filename looks official.” Homebrew a signature from XOR. Attack a site’s code-signing. Those are integrity theater or crimes, not labs.
Right
In $HOME/cyberlium-lab, optionally openssl genrsa a TOY key, dgst -sha256 -sign a note YOU wrote, verify with the public key, flip a byte of the note and watch verify fail, record that this is authenticity+integrity not confidentiality, chmod 600, delete the toy private key. Next — Quiz — AES, RSA, PKI, signatures. Then TLS handshake.
5. Practical: optional openssl dgst -sign / -verify on YOUR note
If you already deleted the RSA toy key, generate a fresh 2048-bit TOY and delete it again after. The note is fictional. The signature file is not a weapon. Do not point -sign at firmware you do not own. Do not distribute the private key as “the verify key.” Windows: Git Bash / WSL / openssl on PATH; restrict ACLs if chmod is missing.
Command guide
DEFENSIVE signature lab — YOUR file, TOY key, then delete
DEFENSIVE. Sign a file YOU created. NEVER forge vendor/CA signatures. NEVER steal or reuse a real code-signing key. NEVER attack sites.
Command — copy this
mkdir -p "$HOME/cyberlium-lab" cd "$HOME/cyberlium-lab"
Fresh TOY pair (delete private key when done). 2048-bit floor.
Command — copy this
openssl genrsa -out toy-sig-private.pem 2048 openssl rsa -in toy-sig-private.pem -pubout -out toy-sig-public.pem chmod 600 toy-sig-private.pem 2>/dev/null || true
Command — copy this
echo "fictional release notes — not a vendor update" > toy-sig-notes.txt
Hash-then-sign (SHA-256 digest + private key). Message stays readable.
Command — copy this
openssl dgst -sha256 -sign toy-sig-private.pem -out toy-sig-notes.sig toy-sig-notes.txt
Command — copy this
openssl dgst -sha256 -verify toy-sig-public.pem -signature toy-sig-notes.sig toy-sig-notes.txt
Expect: Verified OK
Integrity check: one-byte change must FAIL verify (copy, then edit).
Command — copy this
cp toy-sig-notes.txt toy-sig-notes-tampered.txt echo "x" >> toy-sig-notes-tampered.txt openssl dgst -sha256 -verify toy-sig-public.pem -signature toy-sig-notes.sig toy-sig-notes-tampered.txt
Expect: Verification Failure — that is the lesson, not a bug to "fix" by forging.
Command — copy this
{
echo "=== SIGNATURE LAB NOTES (no private key material) ==="
echo "steps: hash(message) -> sign(digest, private) -> verify(digest, signature, public)"
echo "provides: authenticity + integrity"
echo "does_not: confidentiality (plaintext can still be read)"
echo "pki: public key still needs a name binding you trust"
echo "ethics: MY file; TOY key deleted; no forging; no vendor impersonation"
} > sig-lab-notes.txt
chmod 600 sig-lab-notes.txt toy-sig-notes.txt 2>/dev/null || trueCommand — copy this
rm -f toy-sig-private.pem
Optional: rm -f toy-sig-notes.sig toy-sig-public.pem toy-sig-notes-tampered.txt
NEVER: openssl dgst -sign on someone else's release NEVER: replace a vendor .sig with your toy and ship it NEVER: treat verify-skip as a "lab bypass"
Mission: hash-then-sign YOUR note; watch tamper fail verify
1) Optional but recommended: in $HOME/cyberlium-lab, sign a file YOU wrote with openssl dgst -sha256 -sign and a TOY RSA key. 2) Verify OK on the original; change one byte and confirm Verification Failure. Notes: authenticity+integrity, not confidentiality; PKI still names the key. 3) chmod 600; delete the toy private key. Never forge signatures. Never impersonate a vendor or CA.
Stuck? Ask Cyberlium AI Mentor
If “signing encrypts the file” or “I should try to fake a vendor signature to learn” still blurs, ask for a hint — not a forgery recipe. Try: "Hint only: why we hash then sign with the private key, why verify uses the public key, why that is integrity+authenticity and not confidentiality, and why forging is out of scope?" You still sign YOUR note. No CA impersonation. No update-bypass.
You now separate the pen from the lockbox: private key signs a digest, public key verifies, the message may stay public, PKI still answers which public key. AES hid; RSA wrapped; certificates named; signatures proved. Next — Quiz — Encryption — ten APPLY items on this module, then How TLS Handshake Works. Reward on the quiz screen: +40 XP — Encryption Types Complete! Proceed label: Continue to TLS & HTTPS. Still no breaking RSA, no homebrew ciphers, no forged pens.
Knowledge Check
APPLY: A teammate emails a readable “signed” changelog plus a .sig, then says nobody can read it because signatures are encryption. They want to copy a vendor’s signature onto their own binary “to see if the OS notices.” What did the signature provide, and what do you refuse?
Multiple choice
Knowledge Check
APPLY: openssl dgst -verify says Verified OK on toy-sig-notes.txt, then Failure after you append one character. What mechanism fired, and what must you not do next?
Multiple choice
Knowledge Check
APPLY: True or False: A digital signature by itself hides the message from eavesdroppers, proves the signer is ethical, and authorizes you to mint certificates for domains you do not own so the quiz feels “real.”
True or False