A digital signature is a cryptographic value attached to a piece of data that proves two things: who produced the data and that the data has not been changed since it was signed. It is not a scanned image of a handwritten signature. It is a mathematical computation using a private key that produces a verifiable proof tying the signer’s identity to the specific content being signed.
Three security properties flow from this mechanism: authenticity (the signature was produced by the holder of a specific private key), integrity (the signed data has not been modified), and non-repudiation (the signer cannot credibly deny having signed). These are not features layered on top of a simpler system. They emerge directly from the mathematics of asymmetric cryptography and hash functions.
This article covers how digital signatures work at the mechanism level, why the hash-then-sign pattern is used rather than signing raw data, how RSA and ECDSA signatures differ, what non-repudiation means in practice, and where digital signatures appear throughout internet security.
How Digital Signatures Work: The Mechanism
Digital signatures use asymmetric cryptography: a mathematically linked key pair where the private key is kept secret by the signer and the public key is distributed to anyone who needs to verify signatures. The two keys are related by a mathematical one-way function: it is computationally easy to derive the public key from the private key, but practically impossible to derive the private key from the public key.
The signing operation uses the private key to transform data into a signature. The verification operation uses the public key to confirm that the signature is valid for a specific piece of data. Only the holder of the private key can produce a valid signature. Anyone with the public key can verify it.
Why signatures work in the private-key-signs direction
This direction (private key signs, public key verifies) is the reverse of encryption (public key encrypts, private key decrypts), and the reversal is intentional. Signatures are meant to be publicly verifiable: any recipient should be able to confirm who signed a document. By computing the signature with the private key and verifying with the public key, anyone who has the signer’s public key can independently verify the signature. No secret is needed for verification.
If signatures worked in the other direction (public key signs, private key verifies), only the holder of the private key could verify the signature. This would be useless for a property called non-repudiation, which depends on the signature being verifiable by third parties, not just the intended recipient.
The Hash-Then-Sign Pattern: Why Data Is Hashed Before Signing
Nearly all practical digital signature schemes do not sign the raw data directly. They sign a hash of the data. This is not merely an optimization. It is a security requirement.
The signing operation in RSA involves modular exponentiation of the input. Applying RSA directly to a multi-megabyte document would be computationally prohibitive: the exponentiation of a large number takes time proportional to the size of the input. More critically, signing raw data directly creates malleability vulnerabilities: an attacker who knows the signature for data M can sometimes compute a valid signature for a related document M2 without knowing the private key, due to algebraic relationships in the RSA structure.
Hashing the data before signing eliminates both problems. A hash function (SHA-256 for modern signatures) takes any input, regardless of size, and produces a fixed 256-bit output. Signing 256 bits is fast regardless of whether the original document was 1 kilobyte or 1 gigabyte. The hash function also breaks the algebraic relationships that enable malleability: finding two different documents with the same SHA-256 hash is computationally infeasible, so a signature on the hash is a signature on exactly that document and no other.
The hash-then-sign pattern means the signature is tied to the exact bit sequence of the signed data. Change a single period in a contract, swap a digit in a bank transfer amount, or modify one byte of a software binary, and the SHA-256 hash changes completely. The signature on the original hash fails verification. The tamper-evidence is total. This is why digital signatures provide stronger integrity guarantees than physical signatures on paper, which cannot detect modifications to the document after signing.
The full signing process step by step
- The signer prepares the data to be signed (a contract, an email, a software binary, a certificate)
- The signer’s software computes the SHA-256 hash of the data, producing a fixed 256-bit digest
- The signing algorithm (RSA-PSS or ECDSA) applies the private key to the digest, producing the digital signature
- The signature is transmitted alongside the data. The data itself is not encrypted; it remains readable. The signature is proof of authorship and integrity, not confidentiality.
The full verification process step by step
- The verifier receives the data and the signature
- The verifier independently computes the SHA-256 hash of the received data
- The verification algorithm applies the signer’s public key to the signature to recover the digest the signer computed
- The verifier compares the two digests. If they match, the signature is valid: the data was signed by the private key holder and has not been altered. If they do not match, either the data was modified or the signature was forged.
RSA vs ECDSA: The Two Dominant Signature Algorithms
Two asymmetric algorithms dominate digital signature usage: RSA and ECDSA (Elliptic Curve Digital Signature Algorithm). They use different mathematical structures but provide equivalent security properties. The practical differences matter for key size, signature size, and computational performance.
| Property | RSA Signatures | ECDSA Signatures |
| Mathematical basis | Integer factorization problem: security depends on difficulty of factoring large numbers | Elliptic curve discrete logarithm problem: security depends on difficulty of finding the scalar from a point on a curve |
| Key size for 128-bit security | 3072-bit key | 256-bit key (P-256 curve) |
| Signature size | Equal to key size (384 bytes for 3072-bit) | 64 bytes for P-256 (much smaller) |
| Signing speed | Slower (modular exponentiation of large numbers) | Faster (elliptic curve point multiplication) |
| Verification speed | Fast (small exponent in public key) | Moderate (similar speed to signing) |
| Usage in SSL/TLS | Still common in server certificates, especially older deployments | Increasingly preferred; ECDSA certificates with P-256 keys are the recommended default |
| Usage in SSH | RSA remains widely used; Ed25519 (related to ECDSA) is recommended for new keys | ECDSA with standard curves; Ed25519 (EdDSA) preferred for new SSH key pairs |
Ed25519, used in SSH and increasingly in TLS, is an Edwards-curve Digital Signature Algorithm (EdDSA) variant using Curve25519. It combines the small key and signature size advantages of elliptic curve cryptography with a design that avoids certain implementation pitfalls in standard ECDSA. For new key generation in any context, Ed25519 or P-256 ECDSA are the recommended choices over RSA.
Non-Repudiation: What It Means and Why It Matters
Non-repudiation is the property that a signer cannot credibly deny having produced a signature after the fact. It is the most legally significant property of digital signatures and the one that makes them useful in commercial, financial, and legal contexts.
The mechanism behind non-repudiation: only the holder of the private key can produce a valid signature verifiable with the corresponding public key. If a signature on a document verifies correctly using a specific public key, and that public key is associated with a specific identity through a certificate, the only explanation is that the private key holder produced the signature. The signer cannot claim they did not sign it without claiming their private key was stolen, which is a separate dispute about key security.
The legal recognition of non-repudiation from digital signatures depends on jurisdiction and certificate type. The EU eIDAS Regulation establishes three levels: simple electronic signatures (any electronic indication of consent), advanced electronic signatures (must be uniquely linked to the signatory, capable of identifying the signatory, linked to the data in a way that detects changes), and qualified electronic signatures (produced with a qualified certificate from an accredited trust service provider, legally equivalent to handwritten signatures across EU member states). Digital signatures using X.509 certificates from qualified CAs satisfy the advanced or qualified levels depending on the CA’s accreditation.
Non-repudiation depends on a key assumption: the private key was under the sole control of the claimed signer. If a private key is stolen and used to produce a signature, the claimed signer can potentially repudiate the signature by demonstrating the theft. This is why private key security is the operational foundation of any system depending on non-repudiation for legal or financial consequences. Hardware security modules, smart cards, and TPM chips that prevent key extraction are used in high-stakes environments to make repudiation through key theft claims implausible.
What Digital Signatures Provide and What They Do Not
Understanding the boundaries of what digital signatures guarantee prevents false security assumptions.
| Property | Provided by digital signature? | Notes |
| Authenticity: identifies the signer | Yes, with caveats | Identifies the private key holder. Identity of the person depends on how the key is certified. |
| Integrity: data unmodified since signing | Yes | Any modification to signed data invalidates the signature completely. |
| Non-repudiation: signer cannot deny | Yes, with caveats | Depends on key being under sole control of claimed signer. |
| Confidentiality: content kept private | No | Signatures do not encrypt. Signed data is readable by anyone. Use encryption separately for confidentiality. |
| Timestamp: proves when document was signed | Not inherently | Requires a trusted timestamping authority. The signature itself contains no inherent time proof without an external timestamp. |
| Signer’s identity in the real world | Partially | The signature proves who holds the key. Tying the key to a real-world identity requires a certificate from a CA that verified that identity. |
Where Digital Signatures Appear in Internet Security
Digital signatures are not a single-purpose tool. They appear throughout internet security infrastructure in contexts that may not obviously seem related.
SSL/TLS certificate signing
When a Certificate Authority issues an SSL certificate, it hashes the certificate’s content and signs the hash with the CA’s private key. Every time a browser validates a website’s SSL certificate, it verifies this digital signature using the CA’s public key from the browser’s trust store. The signature ensures the certificate was genuinely issued by the CA and has not been modified since. This is the foundational trust mechanism of HTTPS.
Software code signing
Operating system vendors, application stores, and security tools require software to be digitally signed before installation or execution. When you download and run a signed installer on Windows or macOS, the OS verifies the publisher’s digital signature on the executable. A valid signature confirms the software came from the stated publisher and has not been modified since signing, reducing the risk of tampered software being delivered through download hijacking or supply chain attacks.
Email security with S/MIME and PGP
S/MIME and PGP allow email senders to digitally sign messages. The signing private key produces a signature over the email body and attachments. The recipient’s email client verifies the signature using the sender’s certificate or public key. A valid signature confirms the email came from the claimed sender and has not been altered in transit.
Document signing
PDF documents, Microsoft Office files, and electronic contract platforms use digital signatures to create signed documents with legally recognized authenticity. Adobe PDF’s digital signature implementation creates a signature over the document content at the time of signing. Any subsequent modification to the document changes the content hash and invalidates the signature, which is displayed as a signature validity warning in the PDF viewer.
Blockchain and cryptocurrency transactions
Every transaction in Bitcoin, Ethereum, and most blockchain networks is authorized by a digital signature from the sender’s private key. A transaction saying ‘transfer 1 BTC from address A to address B’ is broadcast to the network. Nodes verify the signature using the public key associated with address A. Only the holder of the corresponding private key could have produced a valid signature. This mechanism replaces the role of banks in verifying that the person initiating a transfer controls the relevant account.
TLS CertificateVerify message
During a TLS handshake, the server signs the handshake transcript with its private key and sends this as the CertificateVerify message. The client verifies this signature using the server’s public key from the certificate. This step is what proves the server actually possesses the private key corresponding to the certificate it presented. Without this verification, a server could present any certificate, including a stolen one, and the client would have no way to detect it.
Frequently Asked Questions
What is a digital signature?
A digital signature is a cryptographic value produced by applying a private key to a hash of data. It proves that the data was produced or approved by the holder of that private key, and that the data has not been modified since the signature was created. Digital signatures provide three security properties: authenticity (who signed it), integrity (was it changed?), and non-repudiation (the signer cannot deny signing it). They are used in SSL certificates, software signing, email authentication, electronic documents, and cryptocurrency transactions.
How does a digital signature prove authenticity?
Only the holder of the private key can produce a valid digital signature. The signature is created by applying the private key to a hash of the data using a mathematically one-way operation. The corresponding public key can verify the signature but cannot produce one. When a verifier confirms that a signature is valid for a specific public key, they know the data was signed by whoever holds the matching private key. Connecting that key to a real-world identity requires either prior knowledge of the key or a certificate from a Certificate Authority that has verified the key holder’s identity.
Why are digital signatures stronger than handwritten signatures?
A handwritten signature on a physical document can be forged with varying difficulty, and attaching the same signature to a different document requires no cryptographic work. A digital signature is bound to the exact content of the signed document: any change to the document changes the SHA-256 hash, which invalidates the signature. Forging a valid digital signature on a modified document requires either the private key or finding a hash collision in SHA-256, both of which are computationally infeasible with current technology. The forgery resistance is mathematical rather than physical.
Does a digital signature encrypt the data?
No. Digital signatures prove authenticity and integrity but do not provide confidentiality. A signed document is readable by anyone. The signature travels alongside the plaintext data. To keep the content private, the data must be separately encrypted. A document can be both signed (proving who produced it) and encrypted (hiding the content), but these are separate operations using different cryptographic functions. Signing uses the signer’s private key. Encrypting for a recipient uses the recipient’s public key.
What is the difference between a digital signature and a digital certificate?
A digital signature is a cryptographic value produced by signing data with a private key. A digital certificate is a data structure that binds a public key to an identity, itself signed by a Certificate Authority. The relationship: a digital certificate contains a digital signature from the CA that issued it. A digital signature created by a person becomes meaningfully attributed to a real-world identity when used alongside a certificate that links their public key to a verified identity. Signatures prove who holds a key; certificates prove who that key holder is.
How does hashing make digital signatures secure?
The hash-then-sign pattern is used for two reasons: efficiency and security. Efficiency: signing a 256-bit SHA-256 hash is fast regardless of the size of the original document. Signing a multi-megabyte document directly with RSA would be very slow. Security: the hash function produces a unique representation of the exact document content. Any modification changes the hash completely. Directly signing data without hashing creates algebraic vulnerabilities in RSA that allow forging signatures on related documents without knowing the private key. The hash function’s collision resistance eliminates these attack vectors.
