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 and signing are different operations, 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; its purpose is confidentiality. A digital signature does not hide the document — 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 mechanics of hashing — why a hash is a reliable stand-in for the document at the cryptographic layer — are walked step-by-step in our earlier post on hash versus digital signature, and the binding of the private key to a specific verified person is walked in our earlier post on the identity proof behind digital signatures. This post picks up where those left off: the signing algorithm itself.

The signing step applies an asymmetric-cryptography algorithm — one of RSA-PSS, ECDSA, or Ed25519 — that takes the hash and the signer's private key as inputs and produces a signature as output. Under RSA-PSS 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 a verifier can check independently, using the corresponding public key and the original hash. Calling this operation "encryption of the hash" was a shorthand from the 1990s that has stopped being useful — the asymmetric primitive under signing and encryption is often the same key-pair, but the operation is different. The NIST Digital Signature Standard (FIPS 186-5) explicitly frames signing as its own primitive, not as encryption applied to a hash. Getting that 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 hash versus digital signature framed at the object level — the hash names the payload; the signature has to bind to a matching key algorithm.

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 words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.