Guide
Security
Cryptography
Developer Reference

What Is a Digital Signature?

How hash-then-sign works, why it proves authorship without sharing a secret, and where digital signatures appear in real systems.

Direct Answer

A digital signature is a cryptographic proof of authorship. The signer hashes the message and encrypts the hash with their private key. Any recipient can verify it with the signer's public key — confirming the message was not altered and came from the claimed sender, without sharing the private key.

TL;DR

  • Proves authenticity (who signed) and integrity (not tampered with since signing)
  • Uses an asymmetric key pair — private key to sign, public key to verify
  • Signing does not encrypt; the message content remains visible
  • Based on RSA-PSS, ECDSA, or Ed25519 — choose Ed25519 for new systems
  • Used in TLS certificates, JWT signing (RS256/ES256), and code signing
  • Unlike HMAC, no shared secret — any party with the public key can verify

What a Digital Signature Is

A digital signature is a mathematical scheme that lets a sender prove two things about a message: that it came from them specifically (authenticity) and that it has not been modified after signing (integrity). A third property, non-repudiation, means the signer cannot credibly deny having signed the message later — because only the holder of the private key could have produced a valid signature.

These three properties together make digital signatures essential for code distribution, document authentication, API security, and the certificate system that underpins HTTPS.

Authenticity

Proves the message came from the holder of the private key — not an impostor.

Integrity

Any modification to the message after signing invalidates the signature.

Non-repudiation

The signer cannot later deny signing — the private key is proof of origin.

How Digital Signatures Work

The process has two phases: signing (done by the sender) and verification (done by any recipient).

Signing (sender)

1

Hash the message

A cryptographic hash (SHA-256, SHA-384) produces a fixed-length digest of the message. Even one changed byte produces a completely different digest.

2

Sign the digest

The digest is encrypted with the sender's private key using RSA-PSS, ECDSA, or Ed25519. The result is the signature.

3

Attach the signature

The signature is sent alongside the original message. It does not hide the message content — both travel together.

Verification (recipient)

1

Hash the received message

Hash the message using the same algorithm the signer used. This produces the recipient's own digest of the message.

2

Decrypt with sender's public key

Apply the sender's public key to the signature to recover the original digest the sender signed.

3

Compare digests

If the two digests match, the signature is valid — the message is authentic and unmodified. If they differ, reject it.

Digital Signature vs HMAC

Both digital signatures and HMAC provide message authentication — but they differ fundamentally in how trust is established.

AspectDigital SignatureHMAC
Keys requiredPublic/private key pairShared secret key
Who can verify?Anyone with the public keyOnly parties holding the shared secret
Non-repudiationYesNo — either party could have created it
Key distributionPublic key can be shared openlySecret must be distributed securely
Typical useTLS certs, JWT (RS256/ES256), code signingAPI request signing, cookie integrity

Digital Signature vs Encryption

Signing and encrypting are often confused because both use asymmetric keys — but they serve opposite purposes and use the keys in opposite directions.

AspectDigital SignatureAsymmetric Encryption
GoalAuthenticity + integrityConfidentiality
Private key used to...Sign (create signature)Decrypt (read message)
Public key used to...Verify signatureEncrypt (send to owner)
Message readable by anyone?YesNo — only private key holder

For more on asymmetric encryption, see AES vs RSA.

Real-World Examples

📦Code Signing

Software vendors sign binaries with a private key. Your OS or package manager checks the signature against the vendor's public key before running or installing. A tampered binary fails the check.

🔑JWT Signing

A JWT with alg: RS256 or ES256 is digitally signed by the auth server. Any service with the public key (via JWKS) can verify the token independently without calling the auth server again.

🔒TLS Certificates

A TLS certificate is a public key signed by a Certificate Authority. During the TLS handshake, your browser verifies this signature using the CA's trusted root certificate, establishing that the server's public key is genuine.

Common Mistakes

✗ Confusing signing with encrypting

Signing proves who sent the message. Encrypting hides the content. Signing a message does not make it confidential. If you need both, encrypt-then-sign or use an authenticated scheme — don't assume one implies the other.

✗ Using RSA PKCS#1 v1.5 for signing

The older PKCS#1 v1.5 padding is vulnerable to Bleichenbacher-style attacks. Use RSA-PSS (PKCS#1 v2.1) for new implementations, or better, switch to ECDSA (P-256) or Ed25519.

✗ Skipping certificate chain validation

Verifying a signature against a raw public key is not enough if that public key's authenticity has not been established. Always validate the certificate chain and check revocation (CRL/OCSP) for TLS and PKI use cases.

✗ Reusing ECDSA nonces

ECDSA requires a unique random nonce per signature. If the same nonce is used twice (even across different messages), the private key can be recovered. Sony PlayStation 3 was famously compromised this way. Use Ed25519 to eliminate nonce risk entirely.

Try the Tools

Generate an RSA key pair for signing, or decode a JWT to inspect its signing algorithm and claims.

RSA Key GeneratorJWT Decoder

Frequently Asked Questions

Related Resources

Back to Guides