PDF Encryption History — 1993 to 2026

Phase 0 — PDF 1.0 (1993): No password protection

When Adobe released Acrobat 1.0 in June 1993, the PDF format had no native password protection. Distribution control was a stretch goal — security was added in PDF 1.1, which shipped with Acrobat 2.0 in 1994.

Files from this earliest era cannot be password-protected by definition. If you have a PDF marked %PDF-1.0 with an encrypt dictionary, the file has been re-saved through a later Acrobat version that added the encryption while preserving the version metadata — investigate the actual encrypt dictionary, not the version line.

Phase 1 — PDF 1.1-1.3 / 40-bit RC4 (1996-2001)

PDF 1.1 (Acrobat 2.0, 1994) added the Standard Security Handler with V=1, R=2, 40-bit RC4. The 40-bit key length was a US export-control compromise — strong cryptography (anything above 40 bits) required an export licence, so commercial software shipped with the weakened variant globally.

PDF 1.2 (Acrobat 3.0, 1996) and PDF 1.3 (Acrobat 4.0, 1999) kept the same security model unchanged. This phase produced billions of documents during the late-1990s and early-2000s — many still circulate today as government archives and tax records.

These files map to Hashcat mode 10400. Because 40 bits = 2^40 possible keys, this generation is a finite-key candidate for authorized technical analysis. The exact file variant, compute budget, and verified output still matter.

Phase 2 — PDF 1.4-1.6 / 128-bit RC4 (2001-2008)

PDF 1.4 (Acrobat 5.0, 2001) added V=2, R=3 with configurable 40-128 bit key length. The US lifted strong-encryption export restrictions in early 2000, so 128-bit became the default almost immediately. RC4 stayed; only the key length changed.

PDF 1.5 (Acrobat 6, 2003) and PDF 1.6 (Acrobat 7, 2005) used the same scheme. By 2003, 128-bit RC4 was the dominant configuration for password-protected PDFs in business use — bank statements, government documents, legal disclosure files all sat in this category.

These files map to Hashcat mode 10500. Recovery becomes fundamentally a password-strength problem rather than a cipher problem: 128 bits is beyond brute-force, so success depends entirely on what the original password was. Short, predictable, dictionary-based passwords are recoverable; high-entropy random passwords are not.

Phase 3 — PDF 1.6 / AES-128 V=4 R=4 (2005-2008)

PDF 1.6 (Acrobat 7, 2005) introduced AES-128 as an option through V=4, R=4 with the new crypt filter (CF) sub-dictionary. AES became the default in Acrobat 8 (2006). The KDF (key-derivation function) remained the legacy MD5-based design from previous revisions — which is why hashcat parses these files under mode 10500, the same mode it uses for 128-bit RC4, rather than under a mode of their own.

These files appear most often in the 2005-2010 window: enterprise document management exports, mid-sized law firm work product, contract management systems. Federal agencies that procured Acrobat 8 typically produced this format until Adobe's next major upgrade cycle.

Mode 10500. Same password-strength dependency as the RC4-128 files in that mode, but with a sound cipher (AES instead of RC4). The KDF remains MD5×50, so per-second password verification rates remain high.

Phase 4 — PDF 1.7 ext 3 / AES-256 V=5 R=5 (2008-2010)

Adobe Extension Level 3 to PDF 1.7 (Acrobat 9, 2008) introduced a new Standard Security Handler revision: V=5, R=5. The cipher moved up to AES-256, and the key derivation was replaced outright — the legacy MD5-based chain gave way to a SHA-256 scheme that hashes the password together with the validation salt and the key salt in a single pass, with no iteration at all.

In the encrypt dictionary this phase appears as V=5, R=5, Length=256 with a crypt filter method of AESV3, and its hash prefix is `$pdf$5*5*256*`. The single pass kept verification cheap, which is why it was short-lived: revision 5 existed only in the 2008-2010 window before revision 6 replaced it with the iterated design.

Mode 10600. Because each guess costs so little, human-shaped passwords in this generation are the more favourable case; a truly random password still defeats it.

Phase 5 — PDF 1.7 ext 8 / AES-256 (2010-present)

Adobe Extension Level 8 (Acrobat X, 2010) kept the V=5 handler and the AES-256 cipher of phase 4 but moved to revision 6, replacing the single-pass SHA-256 derivation with an iterated one. The cipher is unchanged; the KDF is not, and that difference is what makes this the modern strong tier.

The KDF is the bigger practical upgrade for security purposes: where mode 10600 verifies a candidate password in microseconds on a GPU, mode 10700 takes 50-100x longer per candidate. This directly throttles password-search throughput.

Mode 10700. From 2018 onwards, Adobe products default to this tier for new password-protected documents. Most newly-encrypted files in 2026 fall into this category. Recovery is still possible for short or predictable passwords, but the wall-clock cost is meaningfully higher than older modes.

What this means for files you find in 2026

All five generations coexist in archives today. Government documents from the 2000s are still mode 10400 or 10500 because they've never been re-encrypted. Modern Acrobat exports default to mode 10700.

When you have a password-protected PDF, the right first step is to identify which generation it belongs to — this single piece of information predicts feasibility better than any other factor. Tools like qpdf --show-encryption, pdfinfo, or any browser-based PDF analyser will print V, R, and Length without requiring the password.

From there, you can place the file into a finite-key candidate (10400), password-dependent (10500/10600), or weak-password-only (10700) category. Plan accordingly.

Frequently Asked Questions

Related references