What must stay in working memory
- Sign with the claimed signer's private key; verify with that signer's public key.
- Verification depends on trusting the public-key-to-identity binding and protecting the private key.
- Signatures allow public verification; HMACs use a shared secret; checksums target accidental transmission errors.
Concrete examples
- A software vendor signs a release manifest; customers validate it with the vendor's authenticated public key.
- A signed document remains readable unless encryption is applied separately.
Decision rules you’ll retrieve
Choose the signer's and verifier's keys
The claimed signer creates the signature with its private key, and every verifier checks it with the claimed signer's authenticated public key.
Retrieval cue: For a message signed by Alice and checked by Bob, state exactly which of Alice's and Bob's keys each operation uses.
State what a valid signature proves
A valid signature binds unchanged signed content to control of the claimed private key, assuming the public-key identity binding and private-key custody are trustworthy; it does not hide content or supply context it never signed.
Retrieval cue: List what signature verification establishes, its trust assumptions, and two properties it does not establish by itself.
Choose among signatures, HMACs, and checksums
Use a signature when independent parties need public-key verification, an HMAC when trusted peers share a secret, and a checksum only for accidental error detection—not adversarial integrity.
Retrieval cue: Compare who can create and verify a signature, HMAC, and checksum, then state whether each resists malicious replacement.