What are Digital Signatures?

The stakes are high when signing goes wrong. Manual processes, disparate tools, and unprotected signing keys leave many companies exposed to key theft and software supply chain attacks. Every one of those incidents chips away at the trust we place in signed code and documents. This guide explains what digital signatures are and how signing actually works, walks through the problems they solve, compares the main algorithm families from RSA to post-quantum, and covers how signatures are used inside PKI and protected at scale. By the end you will understand both the cryptography and the infrastructure that makes it trustworthy.

What is a digital signature?

A digital signature is a cryptographic value that binds a signer’s identity to a specific piece of data. It lets anyone verify two things at once: that the data has not changed since it was signed, and who produced it. That combination of integrity and origin is what makes a signature meaningful rather than decorative.

This is very different from a simple electronic signature. A scanned image of your handwriting, a typed name at the bottom of an email, or a click-to-agree checkbox records intent, but none of them are cryptographically bound to the content. Change one word in the document and a scanned signature stays happily in place. A (cryptographic) digital signature breaks the moment the underlying data is altered, which is exactly the point.

Signing is the act of producing that cryptographic value. The signer uses a private key to generate a signature over the data, and anyone holding the matching public key can check it. The word “signing” therefore describes the operation, while “digital signature” describes the result. Both depend on the private key staying secret, which is why so much of this guide is about protecting keys.

How digital signatures work: the foundations

At the core of every digital signature is a key pair. The private key signs, and the public key verifies. The two keys are mathematically linked. The public key is derived from the private one (or from the private seed) via an efficient algorithm, but you cannot derive the private key from the public one. The signer guards the private key closely. Meanwhile the signer distributes the public key freely, often inside a certificate, so that anyone can validate what the signer produced without ever being able to forge it.

In practice, signers rarely sign the raw data itself. Instead they follow the classic hash-and-sign pattern: the data is first run through a cryptographic hash, which is a function that produces a short, fixed-length digest, and then that digest is signed. This is why algorithm names often look the way they do, such as SHA256WithRSA and SHA256WithECDSA, where the first part names the hash and the second names the signing algorithm. Signing the compact hash rather than a multi-gigabyte binary keeps the operation fast and practical.

Client-side hashing takes this idea further. The hash is computed on the client, so large files never have to travel across the network to a central signing service. Developers can sign quickly, teams keep control of their artifacts, and even the most complex, large-scale environments stay performant because only a small digest moves to the signer.

Throughout all of this, one rule holds: private signing keys should never leave secure, encrypted storage, even during signing. The safest designs generate and use the key inside protected hardware, so the secret value is never exposed on a workstation or build server. The signature comes out; the key stays in.

What problems do digital signatures solve?

Digital signatures deliver a set of trust properties that plain files simply cannot offer on their own.

• Integrity. 
  A signature proves that code, documents, or firmware have not been tampered with, whether in transit or at rest. If a single byte changes, verification fails.
• Authenticity. 
  A signature confirms who signed, giving you a reliable record of who signed the message rather than an unverifiable assertion.
• Non-repudiation and auditability. 
  Detailed, signable event logs create an irrefutable record of signing activity, which is invaluable for compliance and traceability. A signer cannot deny an action that is captured in a signed log before anyone.

These are three of the five pillars of information security, with confidentiality and availability being the outstanding two.

Signatures solve other real world problems, such as guaranteeing the security of supply chains, and protection against malware. Code signing is a critical step to prevent malware spread and to block malicious actors in the software supply chain. Whether you ship applications, deploy scripts and containers, or push over-the-air updates to IoT devices, signing is what lets recipients trust the artifact.

Together these properties explain why signing appears everywhere from published software and container base images to legal contracts and government-issued eIDs.

Digital signature algorithm families

Under the hood, several algorithm families produce signatures. The field is in the middle of a long shift, moving from the classical algorithms that have secured signing for decades toward new post-quantum ones designed to withstand future quantum computers. Understanding the classical families first makes the post-quantum transition much easier to follow.

RSA signatures

RSA is the long-standing baseline. It has been the default choice for signing for many years and still shows up constantly, often through hash-and-sign combinations such as SHA256WithRSA. Even in setups that sign with newer algorithms, RSA frequently remains in the picture: key recovery encryption key pairs, for example, often still rely on RSA at lengths such as 1024 or 2048 bits. RSA is dependable and universally supported, which is precisely why it is so entrenched.

ECDSA and elliptic curve signatures

The Elliptic Curve Digital Signature Algorithm (ECDSA) offers comparable security to RSA with much smaller keys, which is attractive for constrained devices and high-volume signing. For long-term stability, the most commonly used curves are recommended. Choose P-256, P-384, or P-521 unless a specific requirement dictates otherwise. Implementations built on BouncyCastle support a wide range of named curves from NIST, SEC, X9.62, and Brainpool families.

Most deployments encode named curves directly in certificates and requests, which is what IETF recommends. In some cases, you instead need explicit parameters, an approach mandated by the International Civil Aviation Association (ICAO) for Country Signing Certificate Authority (CSCA) and Document Signer certificates used in ePassports. Explicit parameters should only be enabled when genuinely required, because they can violate RFC 5280 and cause enrollment to fail in some REST API flows.

EdDSA (Edwards-curve signatures)

The Edwards-curve Digital Signature Algorithm (EdDSA) uses a variant of the Schnorr signature built on twisted Edwards curves, and it is defined in RFC 8032. It is designed to be faster than existing signature schemes without sacrificing security, which makes it a popular modern choice. The two variants are Ed25519 and Ed448, with Ed25519 by far the most widely supported. Support has been catching up on hardware over time, and most tested hardware modules support Ed25519, while Ed448 remains less common.

Post-quantum signature algorithms

Post-quantum algorithms are becoming an essential fourth family, but their description deserves a fuller treatment. See the dedicated post-quantum section below for the standards, the operational trade-offs, and a real migration story.

Protocols and formats that use digital signatures

Signatures rarely stand alone. They are packaged into standardized formats so different tools and platforms can produce and verify them consistently.

• Code signing formats. 
  These include MS Authenticode for Windows executables, MSI installers, and PowerShell scripts; Java JAR signing and Android signing; CMS signing; OpenPGP signing with client-side hashing; Debian package signing; and Microsoft AppX bundle signing.
• Document signing.
  Similar to PKI, PDF document signing supports different certification levels (depending on the changes permitted to the document) and can request and embed timestamp responses. Advanced Electronic Signatures (AdES) for electronic IDentification, Authentication and trust Services (eIDAS).
   The AdES family covers PAdES for PDF, CAdES for the Cryptographic Messaging Sintax (CMS), and XAdES for XML.
• Timestamping.
   Timestamps follow several IETF RFCs, and MS Authenticode. A Time Stamp Authority can issue eIDAS-compliant time-stamps to prove when something was signed.
• ePassport signing.
   ICAO Machine Readable Travel Documents (MRTD) rely on digital signatures to secure the data in electronic passports.

How digital signatures are used within PKI

Inside a Public Key Infrastructure (PKI), signing shows up in several distinct roles. This section focuses on those signing roles rather than PKI fundamentals. If you want to dig deeper into PKI, check out our .

Certificate Authority (CA) signing keys are the anchor. The CA signing key pairsigns every certificate the CA issues using the CA’s signature algorithm, regardless of the subscriber’s key type. An EdDSA CA, for instance, produces EdDSA signatures on the certificates it issues even when the client key is RSA or ECDSA.

Online Certificate Status Protocol (OCSP) responder signing is a related role. Dedicated OCSP signer key pairs and certificates sign revocation status responses, so a client checking whether a certificate is still valid can trust the answer it receives. This is used in many PKI deployments, including parts of web PKI. CRL signing serves the same goal in batch form: certificate revocation lists are themselves signed. Large CRLs can raise practical signing challenges with certain algorithms, a point that becomes especially important with post-quantum schemes. Learn more in our dedicated guides to CRL and OCSP.

Finally, certificate issuance normally binds a public key to an identity only after the requester demonstrates possession of the corresponding private key, where “possession” means the ability to use it, not exclusive control. For signature keys this is nearly free: PKCS#10 requires the request to be self-signed, and the CA verifies that signature. But this was never universal. Key-agreement and key-transport keys have needed other mechanisms since RFC 4210, and RSA merely hid the problem by letting an encryption-only key produce a valid self-signature anyway. ML-KEM removes that convenience. RFC 9810 defines the alternatives for KEM keys: private-key archival, an indirect proof in which the CA returns the certificate encrypted to the subject, or a direct challenge-response, with EnvelopedData replacing the older EncryptedValue throughout. Signing infrastructure: securing keys and scaling signing

Strong algorithms and protocols are only half the story. The infrastructure that holds the keys and runs the signing operations matters just as much.

• Centralized signing engines.
  A single platform can host many use cases, signers, organizations, and users at once. Consolidating scattered signing tools into one engine simplifies administration, improves security, and lowers cost, while still letting developers and automated processes sign quickly.
• HSM-backed key protection.
  Signing keys should be generated and used inside a FIPS-certified hardware security module (HSM), so they are never exposed on workstations or build servers. Different project members or systems can authenticate and share the same protected key, though always with a record of who signed what.
• Code signing as a service.
   Lightweight agents plug directly into platform-native tools such as SignTool, Jarsigner, Cosign, and OpenSSL, so signing happens locally on the developer’s workstation or the build server. Large binaries never have to move across the network to a central service.
• Policy, access control, and authentication. 
  Granular policies decide who can sign what, when, and with which tools. Authentication through SAML, OAuth, or similar methods verifies users and machines before any signing occurs, and role-based controls keep usage compliant.
• Auditability and scale. 
  Detailed, signable event logs create irrefutable records of key access and usage. Built-in failover, load balancing, and on-demand scaling keep signing available under high transaction volumes.

Post-quantum digital signatures

Post-Quantum Cryptography (PQC) is cryptography that resists the threat a cryptographically relevant quantum computer would pose. A large enough quantum computer to break cryptography does not exist yet, but governments and standards bodies are already driving the migration away from classical asymmetric cryptography, and the largest actor in that effort is the National Institute of Standards and Technology (NIST). The reason is straightforward: once a powerful enough quantum computer arrives, algorithms like RSA and elliptic curve cryptography can be broken.

NIST has standardized the core algorithms. For signatures, FIPS 204 defines ML-DSA (derived from CRYSTALS-Dilithium) and FIPS 205 defines SLH-DSA (derived from SPHINCS+), with another signature standard, FN-DSA (derived from FALCON), to follow. An additional standardization process is currently ongoing, aiming to add signature constructions to diversify the underlying mathematics and cover different use cases. There are also two stateful hash-based signature algorithms, LMS and XMSS, standardized in NIST SP 800-208. They are cryptographically sound, but operationally cumbersome, because the private key carries state that must be handled carefully. The specification does not allow exporting the private key material, which makes secure long-term operation and disaster recovery genuinely hard.

To bridge the transition, hybrid keys and signatures combine a classical key (RSA, ECDSA, or EdDSA) with a post-quantum key such as ML-DSA. A certificate protected this way stays trustworthy as long as either component holds. This is a sensible hedge during the PQC migration as not everyone has full confidence in the security of the new PQC algorithms. Not every HSM supports every hybrid combination, so both the model and its firmware version need checking.

One technical wrinkle stands out. Many post-quantum algorithms are not hash-and-sign the way classical RSA and EC are, which admit hash digests that only depend on the message, making them more portable. This means that, in the case of many post quantum constructions, the full payload must be sent to the signature function, rather than a compact hash. That can strain an HSM when signing large objects such as big CRLs, because the amount of data that can be sent to an HSM is usually limited. RFC 9881 addresses this by introducing Externalμ-ML-DSA as the selected way to handle signing of large payloads, though support varies by HSM and firmware, so early production-scale testing is wise.

For a deep dive into the wider quantum resistant ecosystem, check out our complete guide on post quantum cryptography.

How Keyfactor can help

Keyfactor’s signing portfolio maps directly onto the challenges in this guide. SignServer is a versatile server-side signing engine that securely signs software, firmware, containers, documents, and more, while Signum delivers code signing as a service with a built-in HSM and a SaaS model that is fast to deploy.

Both connect reader problems to concrete solutions. They

• protect signing keys in FIPS-certified HSMs so that secrets never sit exposed,
• enforce signing policy centrally,
• integrate with existing DevOps and document workflows through native tools and standard interfaces, and
• maintain full, signable audit trails of every signing action.
• That combination directly counters the key theft and supply chain risks that undermine trust.

They are also built for cryptographic agility and post-quantum readiness. Support spans RSA, ECDSA, and EdDSA alongside the ML-DSA and SLH-DSA post-quantum signing algorithms, plus client-side hashing for performance and on-demand scaling for high volumes. That positions teams to keep signing today and to move to post-quantum signing when they are ready.

Keyfactor’s Bouncy Castle is a long-established open-source cryptography library that is the default choice for anything involving certificates and signatures. It supports essentially every signature algorithm in use, including the new post-quantum schemes such as ML-DSA and SLH-DSA.