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 is fixed by the crypt filter method (128 bits for AESV2, 256 for AESV3), and the encryption dictionary's /R value together with /V determines which algorithms a processor must use.

PDF 2.0's public-key encryption carries CMS (Cryptographic Message Syntax, RFC 5652) objects in the adbe.pkcs7.s3, adbe.pkcs7.s4 and adbe.pkcs7.s5 sub-filters, enabling certificate-based document encryption without a password. 'Identity' (no encryption) is a standard crypt filter name and 'Standard' is the built-in password security handler's name — neither is a new sub-filter value.

Default AES-256 — no more RC4

PDF 2.0 mandates AES-256 as the default encryption method for new password-protected documents. This means PDF creation tools — Adobe Acrobat (which has defaulted to AES-256 since Acrobat X in 2010), LibreOffice, and 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 key derivation is the revision 6 Algorithm 2.B construction, which requires a minimum of 64 rounds and typically runs between 65 and 80. 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 for which the 40-bit key space can be exhausted (mode 10400) will decline over time as the installed base of RC4-protected documents ages out.

The SHA-256 KDF — what revision 6 actually does

Revision 6 (V=5, R=6) uses Algorithm 2.B, the iterated construction introduced with PDF 1.7 extension level 8 and retained unchanged by PDF 2.0. It runs a minimum of 64 rounds, each combining a block of AES-128-CBC encryption with one SHA-256, SHA-384 or SHA-512 round chosen per round, and the total typically lands between 65 and 80.

PDF 2.0 does not raise that figure: password encryption in PDF 2.0 is V=5, R=6 (AESV3), and its Algorithm 2.B is the same one PDF 1.7 Extension Level 8 shipped. The round count is not selectable by the implementer — the algorithm derives it from the password and salt through its own termination rule.

The result for recovery: mode 10700's cost per candidate is set by this loop and applies equally to a PDF 1.7 Extension Level 8 file and a PDF 2.0 file. There is no PDF 2.0-specific throughput penalty to measure.

CMS encryption — certificate-based protection

PDF 2.0 carries public-key (certificate) encryption as CMS (Cryptographic Message Syntax) objects; the adbe.pkcs7.s3/s4/s5 sub-filters that carry them date back to PDF 1.5, not to PDF 2.0. 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 keeps the permissions value at 32 bits — /P is interpreted as an unsigned 32-bit quantity — and the flag meanings are unchanged from PDF 1.4/1.5. The one permission change runs the other way: bit 10, previously used for content extraction for accessibility, is deprecated in PDF 2.0, where readers must ignore it and writers must always set it to 1. The only 64-bit step in the standard is Algorithm 10, which pads the 32-bit /P value to 64 bits while building the encrypted Perms string, to allow for future extension.

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's byte range covers the file as stored, including its encrypted streams; only the signature's own /Contents value is left unencrypted, so the content still cannot be read without the password.

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, the mainstream readers and libraries support PDF 2.0 password encryption: Adobe Acrobat, Foxit Reader, PDF.js/Mozilla, Chromium's PDFium, Apple Preview, and the common open-source libraries (Poppler, QPDF, pikepdf). What decides compatibility is AES-256 revision 6 support, not a release year — check the reader you actually distribute to.

Readers without AES-256 revision 6 support cannot open a PDF 2.0 password-encrypted file. Acrobat X and XI (2010-2012) are the releases that introduced R=6, so they open such files; readers and tools that never implemented R=6 do not. If distributing to a broad audience, consider whether all recipients use a reader with AES-256 support.

For maximum compatibility: create documents with AES-128 (V=4/R=4 — hashcat modes 10500/25400), which PDF 1.5+ and PDF 2.0 readers both open, rather than AES-256 (mode 10700). Note that V=4 is itself deprecated in PDF 2.0. The two ciphers are comparable for confidentiality, but R=4 password protection is far weaker against password search than R=6 — that is the trade-off being made.

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.

PDF 2.0 uses the same revision 6 key derivation as PDF 1.7 extension level 8, so a PDF 2.0 file and a PDF 1.7 ext-level-8 file cost exactly the same per candidate (Algorithm 2.B, minimum 64 rounds, typically 65-80). What has changed over time is the mix of documents: AES-256 is now the norm and the RC4 generations are ageing out of circulation.

Services accepting PDF recovery cases in 2026 should read /V, /R and the crypt filter method from the encrypt dictionary — those are the only observable encryption inputs a file carries. No KDF round count is stored in the file, so it cannot be reported in a free analysis.

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, AESV3); R=5 is deprecated in PDF 2.0 and shall not be used. adbe.pkcs7.s3/s4/s5 sub-filters = certificate encryption.

3. 3

   For AES-256 (mode 10700)

   Submit for password recovery. Recovery speed depends on the password's strength and pattern, not on a per-file round count.

4. 4

   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