A digital signature proves authenticity and integrity using asymmetric cryptography. Learn how RSA, ECDSA, and Ed25519 signatures work, with real examples.
In 2010, hackers led by George Hotz used a blunt implementation flaw to extract Sony's private ECDSA key from the PlayStation 3 and sign custom firmware as if they were Sony itself. The flaw was not in the elliptic curve math. Sony had used a fixed random nonce for every signature, which means anyone with two valid signatures could recover the private key algebraically. A digital signature is supposed to prove who signed a message and that the message was not altered. When the signing implementation is broken, that proof collapses.
The core idea is straightforward. The signer hashes the message, then applies their private key to the hash. The verifier checks the result with the signer's public key. If verification passes, the signature is valid. This proves authenticity and integrity, and prevents the signer from later denying they signed it (non-repudiation). You can inspect a real RSA key pair with the RSA Key Inspector to see the modulus and exponents involved.
The mechanism relies on asymmetric cryptography, which means two paired keys: one private, one public. The private key signs. The public key verifies. Anyone can verify, but only the key holder can sign.
The process has two stages. First, the signer computes a cryptographic hash of the message using SHA-256 or another hash function. Hashing reduces the message to a fixed-size digest, typically 32 or 64 bytes. Second, the signer applies a mathematical operation using their private key to that digest. The output is the digital signature.
Signing the hash instead of the full message is what makes this practical. RSA operations on a multi-megabyte file would be absurdly slow. RSA on a 32-byte hash takes milliseconds.
On the verifier's side, the process reverses. The verifier independently hashes the message, then uses the signer's public key to check whether the signature matches that hash. If the message was modified by even one bit, the hashes differ and verification fails. If the signature was produced by a different private key, verification fails.
The public-key concept that makes this possible originated with Whitfield Diffie and Martin Hellman in their 1976 paper "New Directions in Cryptography," published in IEEE Transactions on Information Theory. The full paper is available here. RSA followed in 1977 from Rivest, Shamir, and Adleman at MIT, who showed how to build a practical public-key system from the difficulty of factoring large integers.
A small set of algorithm families dominate digital signature usage today. They differ in key size, signature size, speed, and the mathematical problem they rely on.
| Algorithm | Key Size | Signature Size | Relative Speed | Standard |
|---|---|---|---|---|
| RSA-2048 | 2048 bits | 256 bytes | Slow | FIPS 186-5, RFC 8017 |
| ECDSA P-256 | 256 bits | 64 bytes | Fast | FIPS 186-5 |
| Ed25519 | 256 bits | 64 bytes | Very fast | RFC 8032 |
RSA signatures come in two schemes defined in RFC 8017: PKCS#1 v1.5 and PSS. PKCS#1 v1.5 is older and still everywhere because of legacy TLS deployments. PSS is the modern recommendation because it is provably secure under a stronger model. Both produce 256-byte signatures at the 2048-bit key size.
ECDSA, defined in NIST FIPS 186-5, uses elliptic curves. A 256-bit ECDSA key provides security comparable to a 3072-bit RSA key, with signatures one quarter the size. The tradeoff is that ECDSA requires a fresh random nonce per signature, and getting that wrong is catastrophic. The Sony PlayStation 3 hack happened because of nonce reuse. If you sign two different messages with the same nonce, an attacker can solve a simple linear equation to recover your private key.
Ed25519, specified in RFC 8032, fixes the nonce problem. The nonce is derived deterministically from the private key and the message, so it is never reused by accident. Ed25519 is also faster than ECDSA and produces signatures of the same 64-byte size. For new systems that do not need RSA compatibility, Ed25519 is the best default choice.
The Digital Signature Standard (DSS) was first published as FIPS 186 in 1994. The current revision, FIPS 186-5 (2023), added EdDSA to the approved algorithms list alongside RSA and ECDSA.
Digital signatures are not theoretical. They are load-bearing in systems you use every day.
Code signing is the most visible application. Windows requires Authenticode signatures on drivers. macOS notarization requires a Developer ID signature. Without a valid signature, the operating system warns the user or blocks execution entirely. When a signing key is stolen, the attacker can sign malware that passes these checks, which is why code-signing keys are stored in hardware security modules.
TLS certificates are the second major use case. Every HTTPS connection starts with the server presenting an X.509 certificate, which is a public key signed by a certificate authority. The browser verifies the CA's signature on the certificate before trusting the server's identity. The certificate chain is a chain of digital signatures: the root CA signs the intermediate, the intermediate signs the leaf. You can inspect these chains with the Certificate Analyzer.
JSON Web Signatures (JWS), defined in RFC 7515, carry digital signatures in JWT tokens. Every time you authenticate with an OAuth provider, the ID token you receive is a JWS. The signature lets your application verify that the token came from the provider and was not tampered with. You can decode and inspect the signature header and payload with the JWT Decoder.
PGP email signing and PDF document signing (PAdES) are two more applications. PGP signatures let email recipients verify that a message came from the claimed sender. PAdES signatures on PDF documents are legally binding in the European Union under eIDAS regulations.
The math behind digital signatures is sound. The implementations are where things go wrong.
Nonce reuse in ECDSA is the classic failure. The Sony PS3 hack in 2010 is the textbook example, but it has happened elsewhere. In 2013, researchers found that some Bitcoin wallets had produced ECDSA signatures with repeated nonces, allowing attackers to steal private keys. Ed25519 avoids this by deriving the nonce deterministically.
Key theft is the other major failure mode. A stolen private key lets an attacker sign anything. This is why high-value signing keys live in hardware security modules or air-gapped machines. The Stuxnet attack in 2010 used stolen code-signing certificates to sign its drivers, allowing the malware to install on Windows machines without triggering warnings.
A digital signature does not provide confidentiality. Anyone can read a signed message. If you need privacy, you must encrypt separately. A common mistake is assuming that a signed message is also encrypted.
Certificate validation failures are a subtler problem. If a verifier does not check the certificate chain, check expiration dates, or check revocation status, the signature provides no real authentication. The signature is valid mathematically, but the identity claim is meaningless. The HMAC Generator is a useful contrast here: HMACs use a shared secret instead of asymmetric keys, which avoids certificate validation entirely but requires both parties to already share a key.
A digital signature proves that a specific key holder signed a specific message and that the message has not changed since. The math is well understood and has been deployed for decades. The hard parts are key management, certificate validation, and avoiding implementation mistakes like nonce reuse.
For new systems, Ed25519 is the strongest default: fast, compact, and resistant to the nonce-reuse footguns that have broken ECDSA deployments repeatedly. RSA remains necessary for compatibility with existing infrastructure, and ECDSA is the standard for TLS certificates today.
If you want to see how RSA key pairs are structured, open the RSA Key Inspector and load a sample key.
A digital signature is a cryptographic proof that a specific private key holder signed a specific message. The signer hashes the message and applies their private key to the hash. The verifier uses the corresponding public key to check the signature. It provides authenticity and integrity, and prevents the signer from denying they signed it (non-repudiation).
A hash only proves that data has not changed. Anyone can compute the same hash. A digital signature ties the hash to a specific identity using asymmetric cryptography. Only the private key holder can produce the signature, but anyone with the public key can verify it.
Not without the private key, assuming the underlying algorithm is secure and the implementation is correct. However, stolen private keys, nonce reuse in ECDSA, and failures in certificate validation have all led to forged signatures in practice. The math is sound; the implementations are the weak point.
RSA signatures use large keys (2048+ bits) and are slow but widely compatible. Ed25519 uses 256-bit keys, produces 64-byte signatures, is much faster, and derives its nonce deterministically to prevent reuse. Ed25519 is the better choice for new systems; RSA is needed for legacy compatibility.
No. A digital signature proves authenticity and integrity but does not hide the message content. Anyone can read a signed message. If you need confidentiality, you must encrypt the message separately, typically with a symmetric cipher like AES.
How Encryption Works: From Ancient Scytales to AES-256
A Spartan wrapped leather around a rod in 400 BCE. Your browser does 2,048-bit key exchange and AES-256-GCM. The goal is the same. The math is not. Learn how encryption evolved.
The Difference Between Encoding, Encryption, and Hashing
Base64 is not encryption. This guide defines encoding, encryption, and hashing precisely, runs the same input through each, and explains when to use which in production systems.
What Is a Cryptographic Nonce? (And Why Reusing One Breaks Everything)
Sony reused a nonce in PS3 code signing and hackers extracted the master key. PuTTY had biased nonces in 2024. Here is what a nonce is and why reusing one destroys cryptographic security.
