How Digital Signatures Work

A digital signature is a piece of data, generated with a private key, that proves a message came from whoever holds that key and hasn’t been altered since it was signed — and unlike a password or a shared secret, anyone can verify it using only the corresponding public key, without ever needing access to the private one. It’s the asymmetric-cryptography counterpart to HMAC: both prove authenticity and integrity, but HMAC needs both sides to share a secret, while a digital signature lets verification happen with public information alone.

The two keys, and what each one does

Digital signatures rely on a key pair: a private key that only the signer holds, and a mathematically related public key that can be shared with anyone. The relationship between them is one-way — you can derive the public key from the private key, but not the reverse, at least not with any known efficient algorithm for the key sizes in common use.

Signing and verifying use the keys in opposite roles from what people sometimes expect:

1. Signing uses the private key. The signer hashes the message, then runs that hash through a signing algorithm with their private key to produce the signature.
2. Verifying uses the public key. Anyone with the message, the signature, and the signer’s public key can run a verification function that either confirms or rejects the signature.

If even one byte of the message changes after signing, the hash changes, and the signature no longer verifies. If the signature was produced with a different private key, verification fails against the expected public key too. This gives you both integrity (the message wasn’t altered) and authenticity (it came from the private key holder) in one step — assuming the public key itself can be trusted as belonging to who it claims to.

The algorithms behind the curtain

• RSA — the oldest widely deployed signature scheme, based on the difficulty of factoring the product of two large primes. Still common, but its keys are large (2048+ bits) and operations are relatively slow compared to elliptic-curve alternatives.
• ECDSA (Elliptic Curve Digital Signature Algorithm) — offers equivalent security to RSA with much smaller keys, by relying on the difficulty of the elliptic-curve discrete logarithm problem instead of factoring. Widely used in TLS certificates and cryptocurrency systems.
• EdDSA (notably Ed25519) — a newer elliptic-curve scheme designed to avoid some of the implementation pitfalls that have caused real-world ECDSA failures (like signature generation that leaks the private key if the same random value is accidentally reused). Increasingly the default recommendation for new systems.

All three follow the same sign-with-private, verify-with-public shape; they differ in performance, key size, and how forgiving they are of implementation mistakes.

Where signatures actually get used

• TLS certificates. A certificate authority signs a website’s certificate with its own private key; browsers verify it with the CA’s well-known public key, which is what makes the padlock icon meaningful. See how HTTPS works and the TLS handshake for where this fits into establishing a secure connection.
• Code signing. Software publishers sign binaries or packages so operating systems and package managers can verify a download hasn’t been tampered with and genuinely came from the claimed publisher.
• JWTs signed with RS256 or ES256. One of the two standard signing approaches for JSON Web Tokens is asymmetric: the issuer signs with a private key, and any service holding the public key (often published as a JWKS endpoint) can verify tokens independently, without needing the signing secret itself.
• Git commit signing. Signing commits and tags with a GPG or SSH key lets others verify that a commit genuinely came from the claimed author, addressing the fact that Git’s own commit metadata (author name and email) is trivially forgeable on its own.
• Cryptocurrency transactions. Ownership of funds is proven by signing a transaction with the private key associated with an address; anyone on the network can verify the signature without knowing the private key.

Signatures vs encryption vs HMAC

	Digital signature	Encryption	HMAC
Keys involved	Key pair (private signs, public verifies)	Key pair or shared key (protects confidentiality)	One shared secret key
Proves origin	Yes, to anyone with the public key	Not by itself	Yes, to anyone with the shared key
Proves integrity	Yes	Not by itself	Yes
Protects confidentiality	No — the message is often sent in the clear alongside the signature	Yes, that’s its purpose	No
Needs a shared secret	No	Depends (symmetric vs asymmetric encryption)	Yes

A common point of confusion: signing and encrypting are different operations that solve different problems, and a signed message is not automatically confidential — the message content is typically still readable by anyone, unless it’s separately encrypted too.

What can go wrong

The math is solid; the surrounding infrastructure is where real-world failures happen. A signature is only as trustworthy as the binding between a public key and its claimed owner — which is why certificate authorities and public-key infrastructure exist, and why a compromised CA or a stolen private key undermines the whole chain. Weak random number generation during signing has broken ECDSA implementations in practice by leaking private key bits. And algorithm-confusion attacks — tricking a verifier into treating a public key as an HMAC secret, for instance — have shown up in real JWT library vulnerabilities, which is part of why validating the expected algorithm explicitly matters as much as validating the signature itself.

The takeaway

A digital signature lets a private key holder prove authorship and integrity of a message, and lets anyone with the corresponding public key verify it, without any shared secret changing hands. It’s the mechanism quietly underpinning HTTPS certificates, signed software, asymmetrically-signed JWTs, and verified Git commits — and its real-world security depends as much on trustworthy key management and correct implementation as on the underlying math.