PDF 2.0 Encryption — What's New and Why It Matters

What changed in PDF 2.0 encryption

PDF 2.0 (ISO 32000-2:2020) deprecates all legacy encryption schemes. RC4 encryption (V=1, V=2) is formally deprecated — compliant writers should not create new RC4-protected PDFs. AES-128 (V=4, R=4) is retained for backward compatibility but is no longer recommended. AES-256 (V=5, R=6) is the only encryption method that PDF 2.0-compliant writers are required to implement.

The encryption dictionary (Encrypt entry in the trailer) remains structurally similar to PDF 1.7, but PDF 2.0 clarifies many previously ambiguous encryption behaviours: the crypt filter (CF) sub-dictionary now has mandatory fields, the key-length field is restricted to 256 bits for AES, and the revision number in the document catalog must match the encryption revision.

PDF 2.0 also defines a new encryption sub-filter for the first time — 'Identity' (no encryption), 'Standard' (password-based encryption per the spec), and now 'CMS' (Cryptographic Message Syntax, RFC 5652) for public-key-based encryption. The CMS sub-filter enables certificate-based document encryption without a password.

Default AES-256 — no more RC4

PDF 2.0 mandates AES-256 as the default encryption method for new password-protected documents. This means all modern PDF creation tools (Adobe Acrobat 2024+, LibreOffice 7.5+, PDF libraries using PDF 2.0 validation) create AES-256 protected files by default.

The hashcat mode for PDF 2.0 AES-256 is mode 10700 (the same as PDF 1.7 extension level 8). The KDF remains SHA-256-based with 50-100 rounds. However, PDF 2.0 requires the encryption key to be exactly 256 bits (32 bytes) — no variable-length key support like PDF 1.x allowed.

For recovery services, the shift from RC4 (modes 10400, 10500) to AES-256 (mode 10700) in new documents means the proportion of recoverable PDFs via guaranteed key-search (mode 10400) will decline over time as the installed base of RC4-protected documents ages out.

SHA-256 KDF improvements

PDF 2.0 tightens the key-derivation process. In PDF 1.7 extension level 8 (V=5, R=6), the KDF chain used a specific sequence of SHA-256 operations with 50 rounds minimum, processing the password, salt, and file identifier through repeated SHA-256 hashing.

PDF 2.0 (V=6, R=7 in some implementations, though the formal spec retains V=5/R=6 with stricter interpretation) clarifies that the KDF must use at least 64 rounds of SHA-256, not the earlier minimum of 50. Some implementations increase this to 100-150 rounds for additional protection.

The result: per-password verification cost increases by 28-200% compared to minimally-conforming PDF 1.7 implementations. This translates to lower hashcat throughput on mode 10700, extending recovery timelines for AES-256 protected documents. On an RTX 5090, mode 10700 throughput drops from ~38,000 H/s to ~28,000 H/s with 100-round KDF.

CMS encryption — certificate-based protection

PDF 2.0 introduces public-key encryption via the CMS (Cryptographic Message Syntax) sub-filter. Instead of a user-supplied password, the document is encrypted with a random content key, which is then encrypted with the public key(s) of authorized recipients. Recipients use their private key to unwrap the content key.

CMS-encrypted PDFs have no password to crack. Recovery is impossible without the recipient's private key. If the private key is lost, the document is permanently unrecoverable. There is no cryptographic bypass — the content key is RSA-encrypted (2048+ bit) or ECC-encrypted, both infeasible to break.

Enterprise deployments should escrow private keys in a Hardware Security Module (HSM) or Key Management Service (KMS). CMS encryption is ideal for document distribution to known recipients but inappropriate for scenarios where the sender might need to recover access later.

Permission granularity and digital signatures

PDF 2.0 expands the permissions flags from 32 bits to 64 bits in the encryption dictionary. New permission flags include: PermitFullQualityPrinting (bit 12), PermitCopyExtraction (bit 5, expanded), PermitDocumentAssembly (bit 11), PermitAnnotations (bit 6), and PermitContentExtractionForAccessibility (bit 10).

Digital signatures in PDF 2.0 are now explicitly integrated with encryption: a document can be both encrypted (password-based or CMS) and signed. The signature covers the unencrypted content — verification works without the encryption password, but the content cannot be read without it.

For signed-and-encrypted documents: the signature verification proves document integrity and authorship. The encryption protects confidentiality. Recovery of an encrypted signed document requires only the password — removing the signature is not necessary for content access.

PDF 2.0 reader compatibility in 2026

As of 2026, most major PDF readers support PDF 2.0 encryption: Adobe Acrobat (2022+, all platforms), Foxit Reader (12+), PDF.js/Mozilla (2023+), PDFium/Chromium (since M120), Apple Preview (macOS 14+), and most open-source libraries (PDFium, Poppler, QPDF, pikepdf 9+).

Some older readers (Adobe Acrobat X/XI, Foxit Reader 10, macOS Preview pre-2023) may fail to open PDF 2.0 encrypted documents because they don't recognize the mandatory encryption fields. If distributing to a broad audience, consider whether all recipients use PDF 2.0-compatible readers.

For maximum compatibility: create documents with AES-128 (mode 10600) rather than AES-256 (mode 10700) when sharing externally. AES-128 is supported by PDF 1.6+ readers and PDF 2.0 readers alike. The security difference between AES-128 and AES-256 for document confidentiality is negligible in practice.

Recovery implications of PDF 2.0

RC4 key-search (mode 10400) only applies to legacy PDF 1.1-1.3 documents created before ~2001. These documents are a shrinking portion of the PDF ecosystem. Most modern documents use AES-256 (mode 10700), which requires password search, not key search.

The KDF hardening in PDF 2.0 means slower hashcat throughput for mode 10700. A password that would exhaust in 10 days on a loosely-conforming PDF 1.7 reader may take 20-30 days on a PDF 2.0-compliant document with increased KDF rounds.

Services accepting PDF recovery cases in 2026 should verify the KDF round count in the encrypt dictionary. Documents with 100+ rounds require updated pricing and timeline estimates compared to minimally-conforming PDF 1.7 documents. The free analysis should detect and report the KDF round count as part of the feasibility assessment.

PDF 2.0 encryption assessment flow

1. 1

   Check the PDF version

   Run qpdf --show-encryption file.pdf or check /Version in the document catalog. PDF 2.0 = 2.0.

2. 2

   Identify encryption scheme

   V/R values: V=5/R=6 (AES-256, standard), V=6/R=7 (PDF 2.0 enhanced KDF). CMS sub-filter = certificate encryption.

3. 3

   Check KDF round count

   PDF 2.0 documents may use 64-150 rounds. Higher rounds = lower hashcat throughput. Report this in free analysis.

4. 4

   For AES-256 (mode 10700)

   Submit for password recovery. Recovery speed depends on KDF round count. Typical: 28,000-38,000 H/s on RTX 5090.

5. 5

   For CMS encryption

   Cannot recover without the private key. Check if the key is escrowed in a KMS/HSM. If not, document is unrecoverable.

Frequently Asked Questions

Related Reading