PDF Encryption Standards Explained — RC4 vs AES

The 1994 origin: RC4 and US export controls

PDF 1.1 (1994, Acrobat 2) introduced the Standard Security Handler with V=1 and R=2 — a 40-bit RC4 cipher. The 40-bit key length wasn't a cryptographic choice; it was a regulatory one. US export rules treated strong cryptography (above 40 bits) as munitions under the ITAR before jurisdiction moved to the Export Administration Regulations in 1996; until the 2000 relaxation, exporting it required a licence. Software shipped globally with the weakened variant. Adobe followed this convention through PDF 1.3 (1999).

RC4 itself is a stream cipher designed by Ron Rivest in 1987. The cipher keeps a 256-byte permutation plus two 8-bit indices that are shuffled once per output byte — key scheduling followed by the pseudo-random generation loop. RC4 was widely deployed in TLS, WEP, and many file-encryption schemes — until weaknesses became public.

By 2026 standards, both the cipher and the key length are weak. RC4 has biased keystream output (FMS attack on related keys, AlFardan et al. multi-byte biases). The 40-bit key space is small enough to search directly (2^40 ≈ 1.1 trillion keys) using the known padding string in /U, so an R=2 file is recoverable without guessing the password — a different attack from mode 10400's password search. Success still assumes an intact, decryptable file.

2001: 128-bit RC4 lifted by export-rule changes

The US relaxed export controls on cryptography in early 2000. Adobe responded with PDF 1.4 (2001, Acrobat 5), introducing V=2/R=3 with a configurable 40-128 bit RC4 key length. Most commercial software defaulted to 128-bit immediately.

The cipher (RC4) was unchanged — only the key length grew. This is mode 10500 in Hashcat. The 2^128 keyspace is beyond brute-force, so recovery shifted from a key-search problem to a password-search problem.

V=2/R=3 remained the default through PDF 1.6. By 2007, a meaningful fraction of business-grade PDFs in circulation used 128-bit RC4. Many still exist in archives today.

2005: AES enters the picture

PDF 1.5 (2003, Acrobat 6) introduced V=4/R=4 and the crypt-filter sub-dictionary (CF/StmF/StrF). PDF 1.6 (2004, Acrobat 7) added CFM/AESV2 — AES-128 in CBC mode. AES-128 PDFs fall under mode 10500, not 10600.

AES (Advanced Encryption Standard, NIST FIPS 197) was specifically designed to replace ageing ciphers. It has no known practical attacks at 10 rounds (AES-128) or 14 rounds (AES-256) full-strength. Adopting AES future-proofed PDF encryption against cipher-level breakthroughs.

The key-derivation function in V=4/R=4 still used the legacy MD5-based chain from V=1 — a weakness that distinguishes mode 10500 from the later SHA-256 modes 10600 and 10700. Per-password GPU verification remained fast because MD5 is fast.

2008 and 2010: AES-256, then a strengthened KDF

PDF 1.7 Extension Level 3 (Acrobat 9, 2008) introduced V=5/R=5 — AES-256 with a single-pass SHA-256 key derivation (mode 10600). Extension Level 8 (Acrobat X, 2010) kept AES-256 but replaced the KDF with the iterated SHA-256/384/512 construction (V=5/R=6, mode 10700), roughly two orders of magnitude more expensive per attempt than the MD5-based modes.

Two structural improvements over previous generations: AES-256 has 2^256 possible keys (astronomically larger than 2^128, both far beyond brute force, but quantum-resistant) and the SHA-256 KDF chain throttles password search throughput on GPUs.

The combination matters more than either individually. AES-256 alone with a fast KDF would still be password-strength-bound (and recoverable for weak passwords). The slow KDF reduces per-second attempt count, lengthening practical recovery times.

How V/R/Length encode the generation

Adobe's encrypt dictionary uses three fields to describe the cipher: V (algorithm version), R (revision), Length (key bits). Combined with the optional CFM field on V=4 and V=5, these unambiguously identify the encryption tier:

• V=1, R=2, Length=40: PDF 1.1-1.3 RC4 40-bit (Hashcat 10400)
• V=2, R=3, Length=128: PDF 1.4-1.6 RC4 (Hashcat 10500). The rare 40-bit Length variant (V=1 or 2, R=3) is Hashcat 10510 (RC4-40)
• V=4, R=4, Length=128, CFM=AESV2: PDF 1.5+ AES-128 (Hashcat 10500; 25400 when user and owner passwords must both be satisfied). The revision 3/4 password check is the RC4-based /U algorithm, so the AES content cipher does not change the attack
• V=5, R=5, Length=256, CFM=AESV3: PDF 1.7 ext 3 AES-256 (Hashcat 10600). R=5 is deprecated in PDF 2.0 and shall not be used
• V=5, R=6, Length=256, CFM=AESV3: PDF 1.7 ext 8 AES-256 (Hashcat 10700)

Why the password's role changes by generation

For mode 10400 (40-bit), the password essentially doesn't matter for recovery. The cipher key is 40 bits and the entire keyspace is searchable. Whether you set 'apple' or '8&#wQ@9zR$1qE!' as your password, recovery operates on the 2^40 key space, not on the password's character pattern.

For modes 10500-10700, the password becomes everything. The cipher is sound and the key space is beyond brute force, so the only path is to test candidate passwords through the key-derivation function. Short or predictable passwords are recoverable; strong random passwords aren't.

This is the single most important practical insight when looking at a forgotten-password PDF. The encryption tier predicts whether the password matters.

What about future PDF encryption?

PDF 2.0 (ISO 32000-2:2020) remains the current specification and treats 256-bit AES as the standard for new files; AES-GCM for PDF 2.0 (ISO/TS 32003, 2023) exists but is not widely supported. Hybrid post-quantum schemes are research-stage only.

For most current PDFs, mode 10700 (AES-256, V=5/R=6) remains the modern strong tier. New password-protected PDFs created in 2024-2026 are predominantly in this mode by default in Adobe products.

Frequently Asked Questions

Related Reading