What Encryption Does a Digital Signature Use?

July 20, 2026 ·Gustav Poola ·

digital-signaturecryptographyrsa-pssecdsaed25519post-quantumeidasetsi-119-312global-digital-identityauthentication

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

What Encryption Does a Digital Signature Use?

A Vienna-based signing-service integration lead sent a screenshot last week of an audit finding that read, in the specific language the auditor used: "the signature algorithm identifier does not match the certificate's public-key algorithm parameters." The vendor's AdES library had signed a PDF using RSA-PSS with SHA-384, but the certificate's public key was ECDSA over P-256. The signature would not verify against the certificate the platform presented. The finding was mechanically correct — the library had picked an algorithm the certificate could not consume. The engineer's question was reasonable: how does a signing platform end up in that situation, and what algorithms should it actually be using? This post is the answer at the level a technical review needs.

What does a digital signature actually do to the document — encrypt or sign?

Sign — over a hash. Encryption is a different operation, and using the two terms interchangeably is where the vocabulary starts to break.

Encryption transforms plaintext into ciphertext that only the intended recipient can decrypt. Symmetric encryption (AES, ChaCha20) uses one key for both operations; asymmetric encryption (RSA-OAEP, ECIES) uses a public key to encrypt and a private key to decrypt. The purpose of encryption is confidentiality — hiding the content from anyone without the decryption key. Digital signatures do not do this. The document remains in the clear; anyone can read it. What the signature adds is integrity and authenticity — evidence that the document has not been altered since signing, and that the signature was produced by the holder of a specific private key.

The mathematical operation at the signing step is straightforward. First, the signer computes a cryptographic hash of the document — a fixed-length digest that changes completely if any bit of the document changes. In 2026 production this is almost always SHA-256 under RFC 6234, sometimes SHA-384 or SHA-512 for higher-assurance contexts. The hash function is one-way: from the document you can compute the hash in milliseconds, but from the hash you cannot reconstruct the document. That property is what makes the hash a reliable stand-in for the document at the cryptographic layer.

Second, the signer applies a signing algorithm — an asymmetric-cryptography operation that takes the hash and the signer's private key as inputs and produces a signature as output. Under RSA-PSS as defined in RFC 8017, the operation is modular exponentiation over a large integer group; under ECDSA per RFC 6979 it is a scalar multiplication over an elliptic curve; under Ed25519 per RFC 8032 it is a deterministic scheme over the twisted Edwards curve Curve25519. In every case, the output is a bounded-size binary that, combined with the corresponding public key and the original hash, can be verified independently.

What the terminology-abuse actually hides is that the asymmetric primitive underneath signing and encryption is often the same key-pair (an RSA key can be used for both operations depending on padding, an EC key can support both signing and key-exchange). The operation is different. Calling signing "encryption of the hash" was a shorthand from the 1990s that has stopped being useful; the NIST Digital Signature Standard (FIPS 186-5) explicitly frames signing as its own primitive, not as encryption applied to a hash. Getting the vocabulary right up front makes the algorithm-choice discussion legible.

Which algorithms are actually used in 2026 production?

Three families dominate — RSA-PSS, ECDSA, Ed25519 — with a specific hash choice and a specific curve or key size. The differences matter at deployment time.

RSA-PSS with SHA-256. The oldest and still the most common in enterprise deployments. RSA-PSS is the Probabilistic Signature Scheme, defined in PKCS #1 v2.2 (RFC 8017), which improved on the earlier RSA PKCS #1 v1.5 signature scheme by adding randomised padding that makes certain attacks harder. In 2026, RSA-PSS with a 2048-bit modulus is the workhorse for AdES signatures produced by TSPs whose certificate infrastructure is RSA-based. 3072-bit RSA is common for higher-assurance contexts and for QTSPs whose policies require it. RSA signatures are larger than elliptic-curve signatures (256 bytes for RSA-2048 vs 64-72 bytes for ECDSA-P-256 or Ed25519), which matters for constrained-storage contexts but not for typical PAdES-embedded signatures.

ECDSA over P-256 or P-384. ECDSA is the Elliptic Curve Digital Signature Algorithm, defined in FIPS 186-5 and standardised in RFC 6979 for deterministic ECDSA. The two curves in wide deployment for AdES are NIST P-256 (secp256r1) and NIST P-384 (secp384r1), providing security levels roughly equivalent to RSA-3072 and RSA-7680 respectively at much smaller key sizes. ECDSA is dominant in newer deployments, particularly signing platforms that need small signatures embedded in bandwidth-constrained document formats or high-volume signing operations where the smaller compute cost matters. The deterministic-nonce variant in RFC 6979 is preferred because it eliminates the class of ECDSA implementation bugs that leak private keys through nonce reuse.

Ed25519. Ed25519 is the Edwards-curve Digital Signature Algorithm defined in RFC 8032, using the twisted Edwards curve Curve25519. Signatures are 64 bytes, keys are 32 bytes, and the scheme was designed from the outset to avoid the nonce-reuse and side-channel vulnerabilities that have historically affected ECDSA implementations. Ed25519 is the modern choice for green-field deployments, but its adoption in eIDAS-anchored AdES infrastructure has been slower than ECDSA — many QTSPs and legacy CA infrastructures do not yet issue Ed25519 certificates. Where it is used, it produces smaller, faster, safer signatures.

The 2026 shortlist across these three is not a matter of one being universally better. The choice is driven by what the certificate infrastructure supports, what the signing platform's HSM or key-container permits, what the document format's signature envelope can carry, and what the receiving system will accept. The mismatch case the Vienna auditor found is exactly this: a signing library that supports every algorithm, applied to a certificate that only supports one, without the choreography step that resolves the mismatch before signing.

Where do the algorithm choices come from — policy, or defaults?

Both — but the policy is the constraint that actually binds, and most audit findings against algorithm choice trace back to a mismatch between defaults and policy.

The policy layer for AdES is ETSI TS 119 312, the ETSI Technical Specification titled "Cryptographic Suites". It defines the algorithms, key sizes, and hash functions that are acceptable for AdES signature creation and validation, and it publishes explicit sunset dates for algorithms whose security assumptions have weakened enough that their continued use is discouraged. Under ETSI EN 319 102-1, the validation procedure's stage 4 check — "were the algorithms used acceptable under policy at the time of signing?" — compares the signature's algorithm identifiers against the cryptographic-suites policy that was current at the signing moment. A signature produced with an algorithm that was acceptable at signing time but has since been deprecated remains verifiable; a signature produced with an algorithm that was already deprecated at signing time produces an INDETERMINATE verification result under Article 32 procedures.

The NIST Digital Signature Standard (FIPS 186-5) is the parallel U.S. policy anchor, defining the acceptable signing algorithms and their parameters for federal-government contexts. QTSPs operating under the EU Trusted List map their algorithm choices to the intersection of ETSI TS 119 312 and their national supervisory body's requirements. The two policy sources agree on the core algorithms (RSA-PSS, ECDSA, Ed25519 in FIPS 186-5's 2023 update) but diverge on curve preferences and specific key-size guidance in ways that matter for cross-border interoperability.

The defaults layer is the signing library — the OpenSSL, Bouncy Castle, or vendor-specific SDK the platform integrates. Defaults are set by the library author for typical use cases and rarely re-checked by the integrator against the specific policy the deployment sits under. The audit-finding pattern that shows up most frequently in 2025 and 2026 is a signing library defaulting to whatever the library author considered current, applied to a certificate whose CA policy required something different. The signature validates against the library's expectations and fails against the CA's — and the audit finding lands on the integrating platform, not on the library or the CA.

The pattern I've seen work is to treat algorithm selection as an explicit choice at deployment time, checked against three anchors: what the certificate infrastructure supports, what ETSI TS 119 312 currently accepts, and what the receiving verifiers are expected to consume. A Copenhagen-based bank-signing integrator we spoke with in the spring of 2026 had exactly this discipline written into their signing-platform onboarding checklist — every new tenant's certificate profile was inspected, mapped against the current cryptographic-suites policy, and the signing algorithm was set explicitly per tenant rather than allowed to default. The audit findings against algorithm choice on their platform dropped to zero over eighteen months. Skipping any of the three anchors produces the algorithm-mismatch case; getting all three right requires the signing platform to expose algorithm selection as a configuration parameter, not as an invisible default — and the deployment to actually configure it. This is the same discipline that our earlier post on certificate versus signature framed at the object level — the certificate names the key's algorithm; the signature has to match.

What changes with post-quantum cryptography, and when?

The current asymmetric algorithms — RSA, ECDSA, Ed25519 — are all vulnerable to Shor's algorithm on a sufficiently large quantum computer. Post-quantum signature algorithms replace them. The transition is running through 2030-2035 for regulated-signing contexts, and the certificate infrastructure choices being made in 2026 need to account for the migration path.

The NIST standardisation process produced two lattice-based signature schemes and one hash-based scheme for the post-quantum transition. ML-DSA (FIPS 204) is the module-lattice-based digital signature algorithm, standardised as the primary post-quantum replacement for classical signatures. SLH-DSA (FIPS 205) is the stateless hash-based digital signature algorithm, offering conservative security assurance at the cost of larger signatures and slower operations. Both were finalised in August 2024. NIST SP 800-208 covers earlier stateful hash-based signature schemes (LMS, XMSS) that predate the FIPS 204/205 standardisation and remain acceptable for specific long-term-signature use cases.

The ETSI response to the post-quantum transition is codified in ETSI TR 103 692 and successor documents, which map the NIST-standardised algorithms to the eIDAS regulatory framework and start defining the sunset schedule for classical algorithms in AdES and QES contexts. The current shape of the transition is hybrid signatures — signatures that combine a classical algorithm (typically ECDSA P-256) with a post-quantum algorithm (typically ML-DSA-65), so that a verifier who accepts either algorithm can still validate the signature. Hybrid schemes are the pragmatic bridge through the transition period, allowing certificates and signing infrastructures to evolve without breaking backward compatibility.

For AdES deployments landing in 2026, the practical decisions are twofold. First, whether the signing platform is architected for algorithm agility — the ability to swap signing algorithms without rearchitecting the platform. Signing services that hardcode RSA-PSS in their signing chain need substantial rework to accept ECDSA and even more to accept ML-DSA when it becomes required. Second, whether the retention layer can carry signatures whose algorithms may be deprecated in ten years. This is where PAdES-LTA, XAdES-A, CAdES-LTA long-term validation profiles become critical: they define how to wrap a signature with augmented evidence so that even if the original algorithm's security has degraded, the wrapper's timestamp anchors validity in a form the future verifier can still evaluate. That evidence chain is what our post on what makes a digital signature legally valid walked through at the regulatory-framework level — the Article 32 validation procedure's stage 4 policy check is precisely what algorithm agility protects against.

The way we architect around this at IdentiGate is by treating the identity-proofing primitive as algorithm-agnostic. The Identity Verification product produces a chip-anchored proofing record — passport NFC chip read for the 179 ICAO 9303 countries, or document authenticity plus biometric face match for every remaining country — that is bound to whatever signing algorithm the certificate infrastructure adopts. Whether the AdES record uses RSA-PSS today or ML-DSA in 2030, the identity-proofing evidence underneath remains the same globally verifiable primitive. The Signatures product produces AdES records under eIDAS Article 26 using the algorithm the customer's certificate infrastructure supports, and the Evidence Layer product retains the wrapped record — proofing event, certificate, signature, validation data — in a form that carries through algorithm transitions.

Where I disagree with the loud vendor position on post-quantum is the framing that PQC migration is a distant problem that can be deferred. It is a near problem. Signatures being produced in 2026 with classical algorithms need to be retained under LTV wrappers that accommodate future algorithm sunsets, and the platforms locking into single-algorithm architectures now are the platforms that will need substantial rebuild when the ETSI sunset dates for classical algorithms land. Algorithm agility is not an optional feature; it is the architectural property that separates 2026 signing platforms that survive the migration from those that need to be rebuilt around it.

Sources

Primary — eIDAS and signature framework

Primary — ETSI signature and cryptographic standards

Primary — IETF cryptographic standards

Primary — NIST standards (classical and post-quantum)

Primary — identity assurance and document standards

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.

A digital certificate is a signed statement about a public key and its holder's identity, issued by a Certificate Authority. A digital signature is a cryptographic operation produced by the corresponding private key over document data. The certificate proves who the signer is; the signature proves the document is intact and was signed by that signer. Different objects, complementary purposes, and the confusion between them is where most eIDAS audit findings actually land.