Technical deep dive

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

PDF 2.0 (ISO 32000-2) is the first major revision of the PDF specification since PDF 1.7, published in 2006 and standardised as ISO 32000-1 in 2008. First published in 2017 and re-issued as the second edition, ISO 32000-2:2020, in December 2020, it only reached critical mass in consumer and enterprise software in 2024-2026. The encryption changes are the most significant since AES arrived in PDF 1.6 in 2005.

PDF 2.0 — AES-256 (V=5, R=6)hashcat 10700strong encryption

What changed in PDF 2.0 encryption

PDF 2.0 (ISO 32000-2:2020) deprecates all legacy encryption schemes. RC4 (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 no longer recommended. AES-256 (V=5, R=6) is the only method PDF 2.0-compliant writers are required to implement.

The encryption dictionary remains structurally similar to PDF 1.7, but PDF 2.0 clarifies many previously ambiguous 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 /R 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 handler's name — neither is a new sub-filter value.

Backward compatibility

PDF 2.0 readers can open PDF 1.x encrypted documents. The reverse depends on AES-256 revision 6 support: readers that implement R=6 (Acrobat X and later, 2010) open PDF 2.0 password-encrypted files, and readers that never implemented it cannot. Always verify reader compatibility when distributing protected PDFs.

Default AES-256 — no more RC4

PDF 2.0 mandates AES-256 as the default encryption method for new password-protected documents. PDF creation tools — Adobe Acrobat, which has defaulted to AES-256 since Acrobat X in 2010, LibreOffice, and PDF libraries validating against PDF 2.0 — therefore produce AES-256 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. PDF 2.0 also requires the encryption key to be exactly 256 bits (32 bytes) — no variable-length keys like PDF 1.x.

For recovery services, the shift from RC4 (modes 10400 and 10500) to AES-256 (mode 10700) in new documents means the share of PDFs whose 40-bit key space can be exhausted will decline as the installed base of RC4-protected documents ages out.

The SHA-256 derivation — 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 usually 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.

CMS encryption — certificate-based protection

PDF 2.0 carries public-key (certificate) encryption as CMS 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 keys of authorised 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, and 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 suits distribution to known recipients but is inappropriate where the sender might later need to recover access.

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. 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, allowing 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, signature verification proves document integrity and authorship, while encryption protects confidentiality. Recovering an encrypted signed document needs 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) introduced R=6 and open such files; readers that never implemented R=6 do not. If you distribute to a broad audience, consider whether every recipient uses a reader with AES-256 support.

For maximum compatibility, create documents with AES-128 (V=4/R=4 — Hashcat modes 10500/25400), which both PDF 1.5+ and PDF 2.0 readers 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.

Recovery implications of PDF 2.0

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

PDF 2.0 uses the same revision 6 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 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 derivation round count is stored in the file, so it cannot be reported in a free analysis.

PDF 2.0 encryption assessment flow

1
Check the PDF version
Run qpdf --show-encryption file.pdf or check /Version in the document catalog. PDF 2.0 = 2.0.
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
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
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

Is PDF 2.0 encryption backward-compatible?

For password encryption, yes — PDF 2.0 uses the same V=5/R=6 AES-256 scheme as PDF 1.7 Extension Level 8, so any reader with revision 6 support (Acrobat X and later, 2010) opens it. Readers that never implemented AES-256/R=6 cannot.

Does PDF 2.0 still support RC4?

RC4 is deprecated in PDF 2.0. Compliant writers should not create new RC4-protected PDFs. Existing RC4 documents remain readable in PDF 2.0 readers.

What is the CMS sub-filter?

CMS (Cryptographic Message Syntax) enables public-key-based PDF encryption. Recipients use their private key to decrypt. No password is involved — recovery requires the private key.

Is AES-256 in PDF 2.0 crackable?

Not by attacking AES itself — the only searchable input is the password, via Hashcat mode 10700. Revision 6's Algorithm 2.B keeps the per-candidate cost high (minimum 64 rounds, typically 65-80), so feasibility is decided by password strength, not by the cipher.

Can I encrypt and sign the same PDF 2.0 document?

Yes. PDF 2.0 explicitly supports combined encryption and digital signatures. The signature's byte range covers the file as stored, including its encrypted streams; encryption protects content confidentiality.

What PDF reader should I use for PDF 2.0 encrypted files?

Any reader with AES-256 revision 6 support: Adobe Acrobat, Foxit Reader, Chromium-based browsers and current macOS Preview all qualify. Verify that every recipient's reader implements R=6 before distributing.

Need a second opinion on this file?

Run the free local check first. If the file is healthy and you are authorized to recover it, you can compare the evidence with a specialist's supported workflow.

Check the file See supported formats

For authorized owner use only. Recovery depends on the exact file and password; no outcome is guaranteed. FilesUnlock is a separate product from the recovery service that processes submissions.