A candidate defines a digital signature as "encrypting the hash with your private key". Give a definition that also holds for signature schemes involving no encryption at all, and state precisely which security property a signature provides that a shared-key message authentication code (MAC) cannot.
answer
- sign private, verify public
- integrity + authenticity + non-repudiation
- MAC: both sides can forge → no transferability
- verifier needs no secret
- signature ≠ confidentiality
basics
~20 sSigning runs the message and a private key through a signing algorithm to produce a value anyone can check with the matching public key. It gives integrity and origin authenticity. A shared-key MAC gives both too, but not non-repudiation: either key holder could have produced the tag.
solid answer
~50 sA digital signature is a **pair of algorithms**: sign(private key, message) → signature, and verify(public key, message, signature) → true/false. Verification checks a mathematical relation; it does not necessarily decrypt anything. "Encrypting with the private key" is at best a loose analogy for one algorithm family, and even there signing and encryption use different padding constructions with different security arguments. For the elliptic-curve and discrete-log families there is no encryption operation anywhere in signing or verification. Properties gained: - **Integrity** — any change to the message makes verification fail. - **Authenticity of origin** — only the private-key holder could have produced it. - **Non-repudiation / third-party verifiability** — the verifier holds only a public key and therefore *could not* have forged the signature, so the evidence is transferable to someone else. A MAC gives the first two between two parties who share a secret, but both can compute the tag, so neither can prove to a third party which one did. That transferability is the whole difference.
go deeper
Sign with the private key, verify with the public key; integrity plus origin plus non-repudiation; no confidentiality; a MAC is symmetric so it cannot prove which party made the tag.
Add why the encryption analogy fails outside one algorithm family, and give the cost and key-distribution trade-off that decides MAC versus signature.
Argue selection from the verifier population and the trust domain, and note that a MAC hands the forging capability to every verifier.
Discuss what non-repudiation demands beyond the primitive — exclusive key custody, identity binding, trusted time — and when claiming it is not worth the operational burden.
## The definition that survives A signature scheme is three algorithms: - **KeyGen** → a key pair: a private (signing) key and a public (verification) key. - **Sign(private key, message)** → a signature value. - **Verify(public key, message, signature)** → accept or reject. The security goal is *existential unforgeability*: no one lacking the private key can produce a message-and-signature pair that verifies, even after seeing many signatures on messages of their choosing. Nothing in that statement mentions encryption, and that is the point. ## Why "encrypt with the private key" is wrong It is a mnemonic inherited from one algorithm family where the same modular operation underlies both primitives, and it survives because it feels intuitive. Three problems: 1. **It does not generalise.** In the elliptic-curve and discrete-log signature families, signing produces a pair of values from the message digest, the private scalar and a per-signature random or deterministically-derived value; verification recomputes a curve point and compares. There is no ciphertext and nothing to decrypt. A definition that fails for most deployed schemes is not a definition. 2. **Even where the analogy has roots, the constructions differ.** Encryption and signing in that family use different, non-interchangeable padding/encoding schemes with distinct security proofs. Treating one as the other is how implementations become forgeable. 3. **It suggests the wrong mental model of verification.** Verifiers do not recover a plaintext and eyeball it; they evaluate a relation that holds only for a signature produced with the matching private key. Thinking "decrypt and compare" leads people to accept whatever the message says about itself. Say instead: **signing proves origin; encryption hides content. They are different jobs, and a signature hides nothing** — the message travels in the clear beside its signature. ## Signature versus MAC A MAC is symmetric: MAC(shared key, message) → tag, and verification recomputes the tag with the same key. Compare on four axes: | | MAC | Signature | |---|---|---| | Keys | one shared secret | private/public pair | | Integrity | yes | yes | | Origin authenticity | yes, within the pair | yes, to anyone | | Non-repudiation | **no** | **yes** | | Cost | very cheap | orders of magnitude more expensive | | Verifier needs a secret | yes | no | **Non-repudiation** is the asymmetry made useful. With a MAC, the verifier can compute exactly what the signer can, so "the sender must have sent it" is not provable to an outsider — the receiver could have fabricated it. With a signature, the verifier holds a key that cannot sign, so a valid signature is evidence a third party can check independently. The practical corollary: **the verifier needing no secret is often the bigger win**. You can hand the public key to a hundred verifiers, a CDN, a client, an auditor, without any of them gaining the ability to forge. A MAC requires distributing the forging capability to everyone who must verify, so the trusted set grows with the audience. ## Choosing between them Use a **MAC** when both endpoints are inside one trust domain and you control them: internal service-to-service authentication of a payload, cookie integrity where only your servers verify, tamper-evidence on a value you round-trip through a client. It is far cheaper and the key management is trivial. Use a **signature** when verifiers are numerous, untrusted, or must not be able to produce the artefact: software and package provenance, certificates, tokens verified by many independent services, receipts and audit records, anything a third party may need to check later. A sharp illustration: outbound webhooks are commonly authenticated with a MAC over a per-recipient secret. That works for tamper-evidence, but it means the recipient can manufacture a call that looks exactly like yours, and neither of you can prove otherwise. If the events carry financial or legal weight, that is an argument for a signature. ## Where signatures show up Certificates (a certification authority signs a binding between an identity and a public key), signed tokens (an issuer signs a set of claims that many services verify), software artefacts and update manifests, code-signed binaries, signed commits and release tags, receipts and timestamps. The pattern is always the same: **one producer, many independent verifiers, none of whom should be able to produce the artefact**. ## Interview delivery "Sign with the private key, verify with the public key. It gives integrity and origin authenticity, and unlike a MAC it gives non-repudiation, because the verifier holds a key that can't sign — the evidence is transferable. It gives no confidentiality; the message is still in the clear. And it isn't 'encrypting with the private key' — most schemes involve no encryption at all."
- Does a valid signature mean the message was kept confidential in transit?No. Signing provides no confidentiality whatsoever; the message travels in the clear beside its signature and anyone can read it. If both properties are needed you combine mechanisms — encrypt for confidentiality and sign for origin — and you must be explicit about ordering and about which bytes each covers, otherwise you can end up authenticating something other than what the recipient actually reads.
- When would you deliberately choose a MAC over a signature?When both endpoints are yours and no third party ever needs to adjudicate: internal service payload authentication, tamper-evidence on a value you round-trip through a client, integrity on cached entries. A MAC is far cheaper per operation and has simpler key handling. The moment verifiers multiply, or become parties you do not control, the shared secret becomes a forging capability handed to everyone who verifies — switch to a signature.
- If a private key is stolen, what happens to signatures made before the theft?They become unreliable as evidence, because an attacker holding the key can produce signatures indistinguishable from genuine ones and can backdate the message content. Nothing in a bare signature records when it was made. Recovering historical assurance requires an independent time source — a timestamping authority or an append-only log entry made before the compromise — plus revocation that records the point from which the key is no longer trusted.
A MAC is a shared-secret handshake: convincing between the two who know it, worthless as proof to anyone else, because either could have performed it. A signature is a wax seal whose stamp only one party holds — anyone can compare it against a published impression.
saying these in an interview costs you the question
- "Signing is encrypting with the private key" — false for most deployed schemes.
- "A signature keeps the message secret."
- "HMAC is a digital signature" — it authenticates, but it is symmetric and gives no non-repudiation.
- "Non-repudiation just means the message wasn't tampered with" — that is integrity; non-repudiation is transferable proof of origin.
- Believing the verifier needs some secret in order to check a signature.