How Digital Signatures Work: From RSA to Ed25519 and Beyond

Understand digital signatures — how RSA, ECDSA, and Ed25519 work, when to use each, and how post-quantum ML-DSA changes the landscape. Includes code examples and real-world applications.

· 19 min read · Digital Signatures

Digital signatures are the cryptographic foundation of trust on the internet. Every HTTPS connection, every SSH login, every blockchain transaction, and every signed software update relies on digital signatures to prove authenticity and integrity. This guide explains how digital signatures work under the hood, compares the four major algorithms (RSA, ECDSA, Ed25519, and the new post-quantum ML-DSA), and shows you when to use each one.

If you want to create and verify signatures right now, try the Digital Signature Verify tool — it supports RSA, ECDSA, and Ed25519 with PEM key import, all in your browser.

What Is a Digital Signature?

A digital signature is a mathematical scheme for verifying the authenticity and integrity of digital data. It works like a physical signature — but with much stronger security guarantees:

  • Authentication — Proves the signer holds the private key
  • Integrity — Proves the message hasn’t been tampered with
  • Non-repudiation — The signer cannot later deny having signed the message

Digital signatures use public-key cryptography: the signer holds a private key for signing, and anyone with the corresponding public key can verify the signature. This is fundamentally different from symmetric authentication (like HMAC), where both parties share the same secret key.

How Digital Signatures Work

The process has three steps:

1. Key Generation

The signer generates a key pair: a private key (kept secret) and a public key (shared openly). The mathematical relationship between the keys depends on the algorithm:

  • RSA — Based on the difficulty of factoring large integers
  • ECDSA / Ed25519 — Based on the elliptic curve discrete logarithm problem
  • ML-DSA — Based on lattice mathematics (post-quantum)

2. Signing

To sign a message:

  1. Compute the hash of the message (e.g., SHA-256 or SHA-512)
  2. Apply the signing algorithm with the private key to the hash
  3. Output the signature (a fixed-size byte string)

The signature is unique to both the message and the private key. Even a single-bit change in the message produces a completely different signature.

3. Verification

To verify a signature:

  1. Compute the hash of the received message
  2. Apply the verification algorithm with the public key to the signature
  3. Compare the result to the computed hash — if they match, the signature is valid

Verification proves the signer held the private key and the message hasn’t been altered.

The Four Major Signature Algorithms

RSA Signatures

RSA (Rivest–Shamir–Adleman) is the oldest and most widely supported digital signature algorithm, standardized in 1977 and embedded in TLS/SSL, SSH, PDF documents, and code signing certificates.

How it works: RSA signatures use modular exponentiation with a 2048-bit or larger modulus. The signer computes signature = hash^d mod n, and the verifier checks hash = signature^e mod n.

Pros:

  • Universal compatibility — every library, platform, and protocol supports RSA
  • Well-understood security — 45+ years of cryptanalysis
  • Simple implementation — straightforward math, easy to audit

Cons:

  • Large key sizes — 2048-bit keys (256 bytes) for 112-bit security
  • Slow signing — ~1000x slower than ECDSA/Ed25519
  • Vulnerable to quantum computers — Shor’s algorithm breaks RSA entirely

Key size: 2048 bits (minimum), 3072 bits (recommended), 4096 bits (long-term)

Signature size: 256 bytes (RSA-2048), 384 bytes (RSA-3072), 512 bytes (RSA-4096)

Use when: You need maximum compatibility with legacy systems, or you’re working within regulated industries that mandate RSA for code signing or certificates.

ECDSA (Elliptic Curve Digital Signature Algorithm)

ECDSA is the elliptic-curve variant of DSA, standardized by NIST in 2009 (FIPS 186-3) and widely used in TLS certificates, Bitcoin, Ethereum, and FIDO2/WebAuthn security keys.

How it works: ECDSA operates on elliptic curves (most commonly NIST P-256 or P-384). The signer generates a random nonce k, computes a point on the curve, and derives the signature (r, s) from that point. Verification uses the public key and the curve equation to check the signature.

Pros:

  • Smaller keys — 256-bit ECDSA key ≈ 3072-bit RSA key in security
  • Faster than RSA — ~100x faster signing, ~10x faster verification
  • Widely supported — TLS certificates, blockchain, WebAuthn

Cons:

  • Nonce reuse is catastrophic — If the same k is used twice with the same private key, an attacker can extract the private key (this is how Sony’s PS3 signing key was stolen in 2010)
  • Random number quality matters — Weak RNG directly compromises security
  • Variable-length signatures — DER encoding produces 70-72 byte signatures (not fixed 64 bytes)
  • Vulnerable to quantum computers — Shor’s algorithm breaks ECDSA too

Key size: 256 bits (P-256, 128-bit security), 384 bits (P-384, 192-bit security)

Signature size: ~70-72 bytes (DER-encoded P-256), ~100+ bytes (DER-encoded P-384)

Use when: You need TLS certificates (Let’s Encrypt and all public CAs require ECDSA or RSA), WebAuthn/FIDO2 compatibility, or blockchain integration (Bitcoin/Ethereum use secp256k1 ECDSA).

Ed25519 (Edwards-curve Digital Signature Algorithm)

Ed25519 is a specific instantiation of EdDSA, designed in 2011 by Daniel J. Bernstein and colleagues, and standardized in RFC 8032 (2017). It’s built on the twisted Edwards curve Curve25519 and has become the modern default for SSH keys, Git commit signing, and new protocols.

How it works: Ed25519 uses a deterministic nonce generation process — the nonce is computed as a hash of the private key and the message, eliminating the need for a random number generator. This structural choice removes the entire class of nonce-reuse attacks that plague ECDSA.

Pros:

  • Deterministic signing — No random nonce required, immune to the PS3-style nonce-reuse attack
  • Fastest signing and verification — ~2x faster than ECDSA P-256 in every benchmark
  • Fixed 64-byte signatures — Simpler storage and bandwidth planning
  • Small 32-byte keys — Compact and efficient
  • Side-channel resistant — Design explicitly avoids timing attacks

Cons:

  • Not supported for public TLS certificates — Let’s Encrypt and CA/Browser Forum don’t accept Ed25519
  • Optional in WebAuthn/FIDO2 — Most hardware security keys only implement ECDSA
  • Weaker JWT/identity platform support — Many providers still default to ES256
  • Not available in all cloud KMS — AWS and Google support it, Azure does not (as of 2026)
  • Vulnerable to quantum computers — Same elliptic curve math as ECDSA

Key size: 256 bits (32 bytes), providing ~128-bit security

Signature size: 64 bytes (fixed)

Use when: You’re generating new SSH keys, implementing Git commit signing, building IoT device fleets, or working with blockchains that support EdDSA (Solana, Stellar). Ed25519 is the modern default for new deployments where ecosystem compatibility allows it.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

ML-DSA (formerly CRYSTALS-Dilithium) is NIST’s standardized post-quantum digital signature algorithm, published in FIPS 204 (August 2023). It’s designed to resist attacks from both classical and quantum computers.

How it works: ML-DSA is based on the hardness of lattice problems (specifically, the Module Learning With Errors problem). The signer holds a short vector in a high-dimensional lattice as the private key, and signatures are computed using lattice arithmetic that’s easy to verify but hard to forge without the private key.

Pros:

  • Quantum-resistant — Not vulnerable to Shor’s algorithm
  • Fast verification — Competitive with classical algorithms
  • Strong security proofs — Based on well-studied lattice problems

Cons:

  • Large keys — Public keys are 1-2 KB (vs 32-65 bytes for ECDSA/Ed25519)
  • Large signatures — 2420-4627 bytes (vs 64-72 bytes for Ed25519/ECDSA)
  • Newer algorithm — Less battle-tested than RSA/ECDSA (standardized 2023)
  • Limited ecosystem support — Not yet widely supported in TLS, SSH, or JWT
  • Performance overhead — Slower than classical algorithms on most platforms

Security levels: ML-DSA-44 (128-bit), ML-DSA-65 (192-bit), ML-DSA-87 (256-bit)

Key size: 1312-2592 bytes (public key), depending on security level

Signature size: 2420-4627 bytes, depending on security level

Use when: You need long-term post-quantum security for signed data that must remain trustworthy for 10-30+ years, or you’re preparing for NIST’s post-quantum migration timeline. Start with hybrid signing (ML-DSA + Ed25519 or ECDSA) to maintain backward compatibility while gaining quantum resistance.

Algorithm Comparison Table

Property RSA-2048 ECDSA P-256 Ed25519 ML-DSA-65
Key size (public) 256 bytes 65 bytes 32 bytes 1952 bytes
Key size (private) 256 bytes 32 bytes 32 bytes 4032 bytes
Signature size 256 bytes ~70-72 bytes 64 bytes 3309 bytes
Security level 112 bits 128 bits 128 bits 192 bits
Signing speed ~1,000 ops/sec ~30,000 ops/sec ~46,000 ops/sec ~5,000 ops/sec
Verification speed ~50,000 ops/sec ~12,000 ops/sec ~15,000 ops/sec ~20,000 ops/sec
Quantum resistant ❌ No ❌ No ❌ No ✅ Yes
TLS certificates ✅ Universal ✅ Universal ❌ Not accepted ❌ Not yet
SSH keys ✅ Legacy ✅ Supported ✅ Modern default ❌ Not yet
WebAuthn/FIDO2 ✅ Supported ✅ Mandatory (ES256) ⚠️ Optional ❌ Not yet
JWT/JOSE ✅ RS256/384/512 ✅ ES256/384/512 ⚠️ EdDSA (limited) ❌ Not yet
Blockchain ❌ Rare ✅ Bitcoin/Ethereum ✅ Solana/Stellar ❌ Not yet
NIST standard FIPS 186-5 FIPS 186-5 FIPS 186-5 (2023) FIPS 204 (2023)
Nonce reuse risk ❌ None ⚠️ Catastrophic ❌ None (deterministic) ❌ None

Real-World Applications

SSH Authentication

SSH uses digital signatures to authenticate users and servers. The choice of algorithm affects security, performance, and compatibility:

  • Ed25519 — Modern default (OpenSSH 9.8+, GitHub, GitLab). Fast, small keys, deterministic signing.
  • ECDSA P-256 — Widely supported, mandatory for some compliance frameworks.
  • RSA-4096 — Legacy fallback for older systems that don’t support elliptic curves.

Recommendation: Use Ed25519 for new SSH keys. Generate one with the ECC Key Generator or via ssh-keygen -t ed25519.

TLS/SSL Certificates

Every HTTPS connection uses digital signatures to authenticate the server (and optionally the client). The CA/Browser Forum governs which algorithms are accepted for public certificates:

  • RSA-2048/4096 — Universal compatibility, still the most widely deployed.
  • ECDSA P-256/P-384 — Modern default for new certificates (Let’s Encrypt, Cloudflare, Google).
  • Ed25519 — Not accepted for browser-trusted certificates (CA/Browser Forum Baseline Requirements).
  • ML-DSA — Not yet standardized for TLS, but NIST is working on post-quantum TLS profiles.

Recommendation: Use ECDSA P-256 for new TLS certificates. Smaller keys, faster handshakes, and universally accepted by browsers.

Code Signing

Software vendors sign executables, updates, and packages to prove authenticity and prevent tampering:

  • RSA-2048/4096 — Dominant in Windows Authenticode, macOS code signing, and Android APK signing.
  • ECDSA P-256 — Used in iOS app signing and some Linux package managers.
  • Ed25519 — Used in Sigstore (cosign), OpenBSD packages, and some blockchain-based supply chain systems.
  • ML-DSA — Not yet deployed for code signing, but NIST recommends starting hybrid migration planning.

Recommendation: Use RSA-4096 or ECDSA P-256 for maximum compatibility with existing package managers and OS trust stores. For new deployments with long-term integrity requirements, consider hybrid ML-DSA + Ed25519.

Blockchain and Cryptocurrency

Every blockchain transaction is signed to prove ownership of funds:

  • ECDSA (secp256k1) — Bitcoin, Ethereum, and most EVM-compatible chains. Baked into the protocol since launch.
  • Ed25519 — Solana, Stellar, Cardano, and newer blockchains. Chosen for speed and compact signatures.
  • ML-DSA — Not yet used in production blockchains, but several post-quantum blockchain projects are experimenting with lattice-based signatures.

Recommendation: Use the algorithm your blockchain requires — you can’t choose. Bitcoin uses secp256k1 ECDSA; Solana uses Ed25519.

Digital Identity (WebAuthn/FIDO2)

Passwordless authentication relies on digital signatures to prove user identity:

  • ECDSA P-256 (ES256) — Mandatory baseline in WebAuthn. All FIDO2 security keys (YubiKey, Titan) implement it.
  • Ed25519 (EdDSA) — Optional in WebAuthn. Supported by some newer authenticators but not universally deployed.
  • RSA — Supported for backward compatibility but rarely used in new deployments.

Recommendation: Use ECDSA P-256 for WebAuthn/FIDO2 — it’s the only algorithm guaranteed to work with all hardware security keys.

Code Examples

Browser — Web Crypto API (ECDSA P-256)

// Generate an ECDSA P-256 key pair
const keyPair = await crypto.subtle.generateKey(
  { name: 'ECDSA', namedCurve: 'P-256' },
  true,
  ['sign', 'verify']
);

// Sign a message
const message = new TextEncoder().encode('Hello, world!');
const signature = await crypto.subtle.sign(
  { name: 'ECDSA', hash: 'SHA-256' },
  keyPair.privateKey,
  message
);

// Verify the signature
const isValid = await crypto.subtle.verify(
  { name: 'ECDSA', hash: 'SHA-256' },
  keyPair.publicKey,
  signature,
  message
);

console.log('Signature valid:', isValid);

Browser — Web Crypto API (Ed25519)

// Generate an Ed25519 key pair (supported in modern browsers)
const keyPair = await crypto.subtle.generateKey(
  'Ed25519',
  true,
  ['sign', 'verify']
);

// Sign a message
const message = new TextEncoder().encode('Hello, world!');
const signature = await crypto.subtle.sign(
  'Ed25519',
  keyPair.privateKey,
  message
);

// Verify the signature
const isValid = await crypto.subtle.verify(
  'Ed25519',
  keyPair.publicKey,
  signature,
  message
);

console.log('Signature valid:', isValid);

Try both algorithms interactively in the Digital Signature Verify tool.

Python — cryptography library (Ed25519)

from cryptography.hazmat.primitives.asymmetric import ed25519
from cryptography.hazmat.primitives import serialization

# Generate an Ed25519 key pair
private_key = ed25519.Ed25519PrivateKey.generate()
public_key = private_key.public_key()

# Sign a message
message = b"Hello, world!"
signature = private_key.sign(message)

# Verify the signature
try:
    public_key.verify(signature, message)
    print("Signature is valid")
except Exception:
    print("Signature is invalid")

# Export keys to PEM format
private_pem = private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.NoEncryption()
)

public_pem = public_key.public_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PublicFormat.SubjectPublicKeyInfo
)

print("Private key:", private_pem.decode())
print("Public key:", public_pem.decode())

OpenSSL CLI (RSA, ECDSA, Ed25519)

# Generate RSA-4096 private key
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out rsa_private.pem

# Extract RSA public key
openssl rsa -pubout -in rsa_private.pem -out rsa_public.pem

# Sign a file with RSA
openssl dgst -sha256 -sign rsa_private.pem -out signature.bin document.pdf

# Verify RSA signature
openssl dgst -sha256 -verify rsa_public.pem -signature signature.bin document.pdf

# Generate ECDSA P-256 private key
openssl ecparam -genkey -name prime256v1 -noout -out ecdsa_private.pem

# Extract ECDSA public key
openssl ec -in ecdsa_private.pem -pubout -out ecdsa_public.pem

# Sign with ECDSA
openssl dgst -sha256 -sign ecdsa_private.pem -out signature.bin document.pdf

# Verify ECDSA signature
openssl dgst -sha256 -verify ecdsa_public.pem -signature signature.bin document.pdf

# Generate Ed25519 private key (OpenSSL 1.1.1+)
openssl genpkey -algorithm Ed25519 -out ed25519_private.pem

# Extract Ed25519 public key
openssl pkey -in ed25519_private.pem -pubout -out ed25519_public.pem

# Sign with Ed25519
openssl pkeyutl -sign -inkey ed25519_private.pem -in document.pdf -out signature.bin

# Verify Ed25519 signature
openssl pkeyutl -verify -pubin -inkey ed25519_public.pem -in document.pdf -sigfile signature.bin

The Digital Signature Verify and Ed25519 Sign/Verify tools implement these algorithms in your browser with zero server exposure.

Security Considerations

  • Key size matters — RSA-1024 has been factored (2020), and ECDSA with weak curves can be broken. Use RSA-2048+ or ECDSA P-256+ for all new deployments. For long-term security (10+ years), RSA-3072 or ECDSA P-384.

  • Nonce reuse is catastrophic for ECDSA — If the same random nonce k is used twice with the same ECDSA private key, an attacker can extract the private key. This is how Sony’s PS3 signing key was stolen in 2010. Ed25519 eliminates this risk by using deterministic nonce generation.

  • Quantum computers break RSA and ECDSA — Shor’s algorithm can solve the integer factoring and discrete logarithm problems that RSA and ECDSA rely on. A sufficiently powerful quantum computer could break all three in hours. ML-DSA (and other post-quantum algorithms) are resistant to quantum attacks. Start planning your migration now for data that must remain secure for 10+ years.

  • Signature malleability — Some algorithms (like ECDSA) allow multiple valid signatures for the same message. This can cause issues in blockchain and authentication systems. Ed25519 and ML-DSA produce unique, non-malleable signatures.

  • Side-channel attacks — Poorly implemented signature algorithms can leak the private key through timing, power consumption, or electromagnetic emissions. Ed25519 was explicitly designed to be side-channel resistant. Always use well-audited cryptographic libraries (OpenSSL, libsodium, BoringSSL).

  • Hash algorithm choice — Most signature algorithms require a hash function (SHA-256, SHA-384, SHA-512). Use SHA-256 or stronger — never MD5 or SHA-1, which have been broken for collision resistance.

Common Implementation Mistakes

  1. Using RSA-1024 or smaller. RSA-1024 has been factored by academic researchers and provides less than 80 bits of security. Use RSA-2048 as a minimum, RSA-3072 for new systems, and RSA-4096 for long-term archival.

  2. Reusing ECDSA nonces. If your random number generator is weak or predictable, or if you accidentally reuse a nonce, your private key is exposed. Use Ed25519 instead, which eliminates this risk entirely.

  3. Using MD5 or SHA-1 for signature hashing. MD5 has been broken since 2004, and SHA-1 since 2017 (the SHAttered attack). Always use SHA-256 or stronger for signature algorithms.

  4. Not validating public keys. Accepting arbitrary public keys without validation can lead to invalid-curve attacks (for ECDSA) or small-subgroup attacks. Always validate that public keys lie on the correct curve and have the expected format.

  5. Ignoring post-quantum migration. If your signed data must remain trustworthy for 10+ years (code signing certificates, archival documents, blockchain smart contracts), you need a post-quantum migration plan. Start with hybrid signing (ML-DSA + Ed25519) to gain quantum resistance while maintaining backward compatibility. The ML-DSA Sign/Verify tool lets you experiment with post-quantum signatures.

  6. Confusing encryption with signing. RSA can be used for both encryption and signing, but they require different padding schemes (OAEP for encryption, PSS or PKCS#1 v1.5 for signing). Using the wrong padding can break security. ECDSA and Ed25519 are signature-only algorithms — they cannot encrypt data.

Frequently Asked Questions

What is the difference between RSA, ECDSA, and Ed25519?

RSA is the oldest and most widely supported algorithm, based on integer factorization. ECDSA is an elliptic-curve variant that’s faster and uses smaller keys than RSA. Ed25519 is a modern elliptic-curve algorithm designed for speed, security, and simplicity — it’s the fastest of the three and uses deterministic signing to eliminate nonce-reuse attacks. RSA and ECDSA are vulnerable to quantum computers; Ed25519 is also vulnerable (same elliptic-curve math). For post-quantum security, use ML-DSA.

Which signature algorithm should I use for SSH keys?

Use Ed25519 for new SSH keys. It’s the modern default in OpenSSH (9.8+), GitHub, and GitLab. Ed25519 offers the best combination of speed, security, and key size. If you need compatibility with older systems, fall back to ECDSA P-256 or RSA-4096. Never use RSA-1024 or smaller.

Can quantum computers break digital signatures?

Yes — a sufficiently powerful quantum computer running Shor’s algorithm can break RSA, ECDSA, and Ed25519 in hours. This is why NIST standardized post-quantum signature algorithms like ML-DSA (FIPS 204, 2023). For data that must remain secure for 10+ years, start migrating to ML-DSA now. Use hybrid signing (ML-DSA + Ed25519 or ECDSA) to maintain backward compatibility while gaining quantum resistance.

Why is Ed25519 faster than ECDSA?

Ed25519 uses a twisted Edwards curve (Curve25519) with optimized arithmetic that’s faster than the Weierstrass curves used by ECDSA (like NIST P-256). Ed25519 also uses deterministic nonce generation, which eliminates the need for a random number generator and removes an entire class of side-channel attacks. Benchmarks consistently show Ed25519 is ~1.5-2x faster than ECDSA P-256 for both signing and verification.

What is ML-DSA and when should I use it?

ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium) is NIST’s standardized post-quantum signature algorithm (FIPS 204, August 2023). It’s based on lattice mathematics and is resistant to both classical and quantum attacks. Use ML-DSA when you need long-term post-quantum security for signed data (10-30+ year horizon), or when preparing for NIST’s post-quantum migration timeline. Start with hybrid signing (ML-DSA + Ed25519) to maintain compatibility. Experiment with the ML-DSA Sign/Verify tool.

Can I use Ed25519 for TLS certificates?

No — as of 2026, Let’s Encrypt and other public certificate authorities do not issue Ed25519 certificates for browser-trusted HTTPS. The CA/Browser Forum’s Baseline Requirements only accept RSA and ECDSA (P-256, P-384) for public web certificates. Ed25519 is supported in OpenSSL and can be used for internal PKI or private certificates, but not for public-facing websites.

Which algorithm does Bitcoin use?

Bitcoin uses ECDSA with the secp256k1 curve for transaction signatures. This choice was baked into the protocol in 2009 and cannot be changed without a consensus-breaking hard fork. Ethereum and most EVM-compatible chains also use secp256k1 ECDSA. Solana, by contrast, uses Ed25519 for all transaction signatures.

Is RSA still secure in 2026?

Yes — RSA-2048 and larger remain secure against all known classical attacks. The largest RSA key factored to date is 829 bits (2020), well below the 2048-bit threshold. However, RSA is vulnerable to quantum computers (Shor’s algorithm), so it’s not suitable for long-term archival security (10+ years). For new systems, prefer Ed25519 (faster, smaller keys) or ML-DSA (post-quantum). RSA-4096 is still acceptable for legacy compatibility.

  • Digital Signature Verify — Create and verify RSA, ECDSA, and Ed25519 digital signatures with PEM key import/export. Supports PKCS#1 v1.5, PSS, and deterministic ECDSA.

  • Ed25519 Sign/Verify — Fast, secure Ed25519 signatures with deterministic signing. Ideal for SSH keys, Git commit signing, and new deployments.

  • ML-DSA Sign/Verify — Post-quantum digital signatures using NIST’s ML-DSA (FIPS 204) standard. Quantum-resistant signing for long-term security.

  • RSA Key Generator — Generate RSA key pairs (2048, 3072, 4096 bits) with configurable public exponent. Export in PEM, DER, or JWK format.

  • ECC Key Generator — Generate elliptic curve key pairs (P-256, P-384, secp256k1, Ed25519). Smaller keys, faster operations, modern cryptography.

Further Reading

Related Tools

Digital Signature & Verify

Try it now →

Ed25519 Sign / Verify

Try it now →

ML-DSA Sign / Verify

Try it now →

RSA Key Generator

Try it now →

ECC / ECDSA Key Generator

Try it now →