Teams regularly encrypt data when they needed to prove who produced it, or sign data when they needed to keep it secret, and neither mistake shows up until an incident or an audit. Digital signatures protect integrity and origin: anyone can verify, only the key holder can sign. Encryption protects confidentiality: anyone can encrypt to a recipient, only the key holder can read. This guide compares the two side by side, covering the reversed roles of the key pair, how each fails, the use cases where they are routinely confused (code signing, tokens, email), the patterns that combine them, and the key management rules that differ for each. It is written for architects and PKI owners making design decisions.
Key takeaways
- Different security goals. A signature answers "who produced this, and has it changed?"; encryption answers "who can read this?". Neither answers the other's question.
- The key roles are reversed. You sign with your own private key and others verify with your public key; others encrypt with your public key and you decrypt with your private key.
- Encryption is not integrity by default. Authenticated encryption (AEAD) detects tampering only for parties who hold the key, and it cannot prove to a third party who wrote the message.
- Real systems use both, in a deliberate order. TLS, S/MIME, OpenPGP and signed-then-encrypted tokens each make an explicit choice about what is signed, what is encrypted and in which order.
- Keep signing and encryption keys separate. They have different escrow, backup, cryptoperiod and revocation rules, and X.509 key usage bits exist to enforce the split.
The short answer
Use a digital signature when the reader must be able to verify origin and integrity, especially when the reader is a third party, a machine that pulls code, or an auditor later on. Use encryption when the data must stay unreadable to anyone except intended recipients, in transit or at rest. Use both when content is sensitive and its origin matters, which covers most regulated messaging, signed and encrypted tokens carrying personal data, and software updates delivered over hostile networks.
A useful test: if publishing the content openly would be acceptable but forging it would not, you need a signature. If forging it would be harmless but disclosure would not, you need encryption. If both would hurt, you need both. The Digital Signatures Guide and the Encryption Guide cover each primitive in depth; this page is about choosing and combining them.
Side-by-side comparison
| Dimension | Digital signature | Encryption |
|---|---|---|
| Security goal | Integrity, signer authentication, non-repudiation (FIPS 186-5) | Confidentiality |
| Who uses the private key | The sender, to sign | The recipient, to decrypt |
| Who uses the public key | Any verifier | Any sender |
| Output | Original data stays readable, plus a signature value | Ciphertext that hides the data |
| Third-party proof | Yes: a verifier can show others the signer produced it | No: encryption says nothing about who wrote the plaintext |
| Symmetric equivalent | MAC (for example HMAC), integrity among key holders only, no third-party proof | Symmetric ciphers such as AES-GCM or ChaCha20-Poly1305 |
| Typical algorithms | RSA-PSS, ECDSA, EdDSA (FIPS 186-5); ML-DSA (FIPS 204) | AES-GCM for data; RSA-OAEP, ECDH or ML-KEM (FIPS 203) to deliver the data key |
| X.509 key usage | digitalSignature, contentCommitment | keyEncipherment, keyAgreement, dataEncipherment |
| Key escrow and backup | Avoid escrow of private signing keys: it weakens non-repudiation | Often required: losing the key loses the data |
| Effect of private key compromise | Attacker can forge new signatures; past signatures become disputable | Attacker can read past and future data encrypted to that key (unless forward secrecy applies) |
Key roles reversed: what the key pair actually does
Both mechanisms commonly use the same family of key pairs, which is where the confusion starts. With RSA the mathematics of signing and decrypting look alike, so older textbooks describe signing as "encrypting with the private key". That description is wrong in practice and dangerous in code: modern signature schemes such as RSA-PSS and ECDSA include hashing, padding and randomisation that differ from RSA-OAEP encryption, and ECDSA and EdDSA have no encryption operation at all.
- Signing: the signer hashes the message and produces a signature with its private key. Any party with the public key, usually delivered in a certificate, checks the signature. The message itself is not hidden.
- Encrypting: the sender generates a random data key, encrypts the message with a symmetric AEAD cipher, and then wraps the data key to the recipient's public key (key transport with RSA-OAEP) or derives it through key agreement (ECDH, or a KEM such as ML-KEM). Only the recipient's private key unwraps it. This hybrid pattern is explained in the Symmetric vs Asymmetric Encryption Guide.
- Consequence for trust: for signatures, the verifier must trust that the public key belongs to the claimed signer. For encryption, the sender must trust that the public key belongs to the intended recipient. Both depend on PKI or another binding, but the failure looks different: a substituted key lets an attacker forge for signatures, and read for encryption.
Why authenticated encryption is not a signature
AEAD ciphers such as AES-GCM detect any modification of ciphertext, so engineers sometimes treat them as integrity protection. They are, but only between parties sharing the key. Any key holder can create a valid ciphertext, so the recipient cannot prove to anyone else who wrote it. The same applies to HMAC: RFC 7518 distinguishes MACs from digital signatures for exactly this reason. Even public-key encryption with sender authentication behaves this way. HPKE (RFC 9180, an Informational IRTF document) offers an Auth mode that tells the recipient the sender held a particular private key, but the RFC notes this authentication is repudiable and suffers from key-compromise impersonation, and suggests adding a separate signature where that matters.
Threat model and failure modes for each
| Threat | Signature addresses it? | Encryption addresses it? | Notes |
|---|---|---|---|
| Eavesdropping on data in transit or at rest | No | Yes | Signed data is fully readable |
| Tampering by a party without keys | Yes | Only with AEAD | Unauthenticated modes such as CBC without a MAC are malleable |
| Tampering or forgery by a key holder | Yes (only the signer can sign) | No | Any party who can encrypt can produce valid ciphertext |
| Signer later denies the action | Yes, if the key was under the signer's sole control | No | Escrowed or shared signing keys weaken this |
| Malicious software update | Yes (code signing) | No | Encrypting a package does not tell the client who built it |
| Replay of an old valid message | Not alone | Not alone | Needs timestamps, nonces or audience and expiry claims |
Signature failure modes: verifiers that skip validation or accept weak algorithms (the JWS none value, which RFC 7518 says recipients must not accept by default); verifying the signature but not the signer identity; signing keys left on build agents or laptops; and no revocation or timestamping, so a compromise invalidates history. ATT&CK tracks adversary use of these weaknesses as T1553.002 Code Signing (subverting trust controls) and T1588.003 Code Signing Certificates (obtaining certificates to sign malware).
Encryption failure modes: nonce reuse in AES-GCM, unauthenticated cipher modes, keys stored beside the ciphertext, and no recovery path for lost keys. See the Authenticated Encryption and Block Cipher Modes Guide for the cipher-level detail.
Use cases where they get confused
Code signing
Code signing is a pure signature use case. The goal is that a client, operating system or admission controller can confirm the publisher and that the artefact has not changed. Encrypting a package or container image does nothing for this: anyone with the recipient key could have built the content. Modern supply chain tooling makes the split explicit. In Sigstore, the cosign client generates an ephemeral key pair, Fulcio issues a short-lived certificate binding the key to an OIDC identity such as a CI workflow, the signature and certificate are recorded in the Rekor transparency log, and the private key is discarded. Verifiers check the signature, the expected identity, the chain to the Sigstore root and inclusion in Rekor. Nothing is encrypted. Where firmware or models also contain secrets, encryption is added as a separate layer. See the Code Signing Security Guide and Code Signing vs Artifact Attestation.
Tokens: JWS and JWE
Most JSON Web Tokens are signed (JWS), not encrypted. Their claims are base64url encoded and readable by anyone holding the token. RFC 7518 lists the signing alg values: HS256 (HMAC, required for implementations), RS256 and ES256 (recommended), PS256 (optional) and none. JWE uses separate key management values such as RSA-OAEP and ECDH-ES and content encryption such as A256GCM. Two practical consequences follow:
- HS256 is a MAC, not a signature: every service that can verify can also mint tokens. For tokens consumed by many resource servers, an asymmetric algorithm limits minting to the issuer.
- Personal data in claims needs JWE or removal: if a token travels through browsers, logs or third parties and carries identifiers you would not publish, sign it and then encrypt it as a nested JWT, or keep the data server-side and pass a reference.
The JWS vs JWE guide covers the token formats and the JWT Security Guide covers validation.
Email shows both mechanisms at three layers. DKIM signs messages at the domain level so receivers can check the sending domain and that signed headers and body are intact, while TLS between mail servers encrypts the hop but is removed at each server. Neither protects the message end to end. S/MIME and OpenPGP add user-level signing and encryption. RFC 8551 (S/MIME 4.0) allows any order and sets out the trade-off: signing first means the signer identity is hidden inside the encryption, while encrypting first exposes the signer and lets anyone verify without decrypting but breaks the link between the signer and the plaintext. RFC 8551 also anticipates separate key pairs for confidentiality and signatures, with an encryption key preference attribute telling correspondents which certificate to encrypt to. See the OpenPGP and S/MIME Email Encryption Guide and the DMARC, SPF and DKIM Guide.
Combined patterns and ordering
| Pattern | What it gives | Where it is used | Watch out for |
|---|---|---|---|
| Sign then encrypt | Hidden content and hidden signer; recipient verifies after decrypting | S/MIME and OpenPGP default practice, nested JWT (JWS inside JWE) | Bind the recipient inside the signed content, or a recipient can re-encrypt the signed message to someone else (surreptitious forwarding) |
| Encrypt then sign | Anyone can verify origin of the ciphertext without decrypting | Gateways that filter by sender, some messaging and storage protocols | The signature does not prove the signer knew the plaintext; an attacker can strip the signature and sign the ciphertext themselves |
| Sign, encrypt, sign (triple wrap) | Inner signature over content, outer signature over the encrypted envelope | S/MIME with Enhanced Security Services, labelled messages | Complexity; verify both layers |
| Authenticated channel plus signed object | TLS for confidentiality in transit; separate signature for long-term origin proof | API payloads, software update delivery, webhooks needing audit | TLS protection ends at the endpoint; the signature survives storage |
| Signed key exchange | Signature authenticates the parties, key agreement provides encryption keys | TLS 1.3 handshake, SSH | Forward secrecy depends on ephemeral key exchange, not on the signing key |
Ordering rule of thumb: sign the plaintext with the recipient and context named inside the signed content, then encrypt. Use encrypt-then-sign only when intermediaries must verify origin without access to content, and treat that signature as covering the ciphertext only.
Key management differences
Signing and encryption keys can share an algorithm family yet need opposite handling. NIST SP 800-57 Part 1 Rev. 5 is the reference for key types, cryptoperiods and protection requirements, and the Cryptographic Key Management Guide applies it.
| Concern | Private signing key | Private decryption key |
|---|---|---|
| Backup and escrow | Avoid escrow; generate a replacement if lost. Escrow lets someone else sign as the owner | Back up or escrow; loss makes stored data unrecoverable |
| Storage | HSM or cloud KMS with non-exportable keys for high-value keys (code signing, token issuers, CAs) | HSM or KMS, usually as a key encryption key in an envelope scheme |
| After retirement | Destroy the private key; keep the public key and certificate to verify old signatures, with timestamps | Keep the private key while any data encrypted under it must remain readable |
| Compromise response | Revoke, re-sign affected artefacts, use timestamps to separate pre-compromise signatures | Rotate, re-encrypt data, assess what was readable |
| Certificate key usage | digitalSignature and contentCommitment only | keyEncipherment or keyAgreement only |
RFC 5280 defines these key usage bits so relying parties can refuse a key used outside its purpose. Issuing one certificate with both signing and encryption bits forces you to choose between escrowing a signing key and losing the ability to recover data. Separate key pairs avoid the conflict and limit cross-protocol attacks. Cloud KMS products enforce the same split by fixing a key's purpose (sign and verify, or encrypt and decrypt) at creation. See the HSM Deployment and Operations Guide and the Envelope Encryption and KMS Integration Patterns Guide.
Post-quantum differences
The quantum transition affects the two differently. Encrypted data recorded today can be decrypted later if the key exchange is broken, so confidentiality migration to ML-KEM (FIPS 203) is the more urgent "harvest now, decrypt later" concern. Signatures are verified at a point in time, so the risk is future forgery, which matters most for long-lived roots of trust, firmware signing and documents that must verify for decades. NIST published ML-DSA as FIPS 204 on 13 August 2024. See the ML-DSA and SLH-DSA Post-Quantum Signatures Guide.
Where identity fits
Signing keys are machine identities. A token issuer's signing key, a CI pipeline's code signing identity and a webhook sender's key all assert "this came from me", so whoever can use them can impersonate that workload. Treat them as high-privilege non-human identities: one owner, scoped use, monitored signing operations and short-lived credentials where possible, as Sigstore does with OIDC-bound certificates. Decryption keys are access to data, so they belong in data access reviews rather than identity reviews.
Decision guidance
- State the threat in one line. Disclosure, forgery or both. If you cannot say, you will pick the wrong mechanism.
- Identify the verifier. If only two parties who share a secret must check integrity, a MAC or AEAD is enough. If third parties, many services or auditors must verify, use a signature.
- Identify the readers. If anyone outside the intended recipients will handle the data (browsers, logs, intermediaries, storage providers), add encryption.
- Decide the lifetime. Long-lived proof needs signatures with timestamping; long-lived confidentiality needs key escrow and a post-quantum plan.
- Choose the order deliberately using the combined patterns table, and bind recipient and context into signed content.
- Issue separate keys with the right key usage, storage and owners.
Small organisations: rely on platform services: managed KMS keys with fixed purposes, Sigstore or a managed code signing service, and an identity provider that signs tokens with asymmetric keys. Large organisations: centralise signing key custody in HSMs with approval workflows for high-value signing, keep an inventory of signing identities, and standardise one token format per use case.
Worked scenario
A payments platform sends settlement files to partner banks over SFTP. The original design encrypted files with each bank's public key and called the job done. During a dispute, a bank claimed a file had been altered; the platform could not prove origin because any party holding the bank's public key could have produced an identical encrypted file. The redesign signs each file with a dedicated signing key held in an HSM, includes the bank identifier, file sequence number and creation time inside the signed content, then encrypts to the bank. The bank decrypts, verifies the signature and the sequence, and archives the signed plaintext with a trusted timestamp. Signing and encryption certificates are separate: the encryption key is escrowed for recovery, the signing key is not.
How to implement
- Inventory: list every place the organisation signs or encrypts (token issuers, code signing, document signing, data encryption, messaging) with the key, its purpose, algorithm and owner. The Certificate Inventory Register Template is a starting point.
- Classify: mark each against the threat (disclosure, forgery, both) and flag mismatches, such as encrypted but unsigned updates or signed tokens carrying personal data.
- Split dual-use keys: issue new certificates with single-purpose key usage; run old and new in parallel until relying parties accept the new keys.
- Harden verification: pin algorithms per use case, reject
noneand unexpected algorithms, verify signer identity as well as the signature, and check expiry and audience. - Pilot ordering changes on one integration, test that recipients reject tampered, re-signed and replayed messages, then roll out.
- Rollback: keep previous keys valid for verification or decryption for a defined window, and document how to revert relying parties to the previous trust list.
Detection and measurement
- Log signing operations: every use of a high-value signing key (KMS or HSM audit logs) with the requesting identity; alert on use outside the expected pipeline or hours.
- Log verification failures: rising signature failures at clients or admission controllers can indicate tampering or a key rollover problem.
- Watch transparency logs: where Sigstore or certificate transparency apply, monitor for entries using your identities that you did not create.
Metrics that show the programme is working:
- Percentage of keys with a single declared purpose and matching key usage.
- Percentage of high-value signing keys held in HSM or KMS as non-exportable.
- Percentage of deployed artefacts with a verified signature at admission.
- Number of token types carrying personal data without encryption (target zero).
- Mean time to revoke and replace a signing key in an exercise.
Common failure patterns
- Encrypting updates instead of signing them: the client decrypts successfully and installs whatever the key holder built.
- Shared HMAC secrets across many services: any compromised verifier can mint tokens for all others.
- Escrowed signing keys: a backup operator or recovery process can sign as the owner, which removes non-repudiation.
- Encrypt-then-sign treated as proof of authorship: the signer may never have seen the plaintext.
- Signing keys on build agents: long-lived exportable keys copied into pipelines are stolen with the agent. The Compromised Code Signing Certificate Playbook covers response.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-12 Cryptographic Key Establishment and Management | Separate key types, custody and lifecycle |
| NIST SP 800-53 Rev. 5 | SC-13 Cryptographic Protection | Approved algorithms for each purpose |
| NIST SP 800-53 Rev. 5 | SC-8 Transmission Confidentiality and Integrity | Encryption and integrity in transit |
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity | Signature verification of code and data |
| NIST CSF 2.0 | PR.DS-01, PR.DS-02 | Protection of data at rest and in transit |
| ISO/IEC 27001:2022 | Annex A 8.24 Use of cryptography | Policy for cryptography and key management |
| MITRE ATT&CK | T1553.002 Code Signing; T1588.003 Code Signing Certificates | Adversary abuse of signing trust |
Practitioner checklist
- Write down, for each use of cryptography, whether the threat is disclosure, forgery or both.
- Use signatures wherever third parties or many services must verify origin; reserve MACs for two-party integrity.
- Encrypt any signed token or file that carries data you would not publish.
- Sign first and bind recipient, purpose and time into the signed content when combining.
- Issue separate signing and encryption key pairs with matching X.509 key usage.
- Escrow decryption keys; never escrow private signing keys.
- Hold high-value signing keys in HSM or KMS as non-exportable and log every use.
- Pin signature algorithms in verifiers and reject
none. - Timestamp long-lived signatures and plan post-quantum migration for both purposes.
Standards and references
- NIST: FIPS 186-5 Digital Signature Standard
- NIST: FIPS 204 Module-Lattice-Based Digital Signature Standard
- NIST: SP 800-57 Part 1 Rev. 5 Recommendation for Key Management
- IETF: RFC 5280 Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- IETF: RFC 8551 S/MIME Version 4.0 Message Specification
- IETF: RFC 7518 JSON Web Algorithms
- IRTF: RFC 9180 Hybrid Public Key Encryption
- Sigstore: Overview
Related NHI Mgmt Group resources: Digital Signatures Guide, Encryption vs Hashing vs Masking, Cryptographic Key Management Guide, JWS vs JWE.