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 was not a cryptographic choice but a regulatory one. US export rules treated strong cryptography (above 40 bits) as munitions under ITAR before jurisdiction moved to the Export Administration Regulations in 1996; until the 2000 relaxation, exporting it required a licence. Software shipped worldwide with the weakened variant, and Adobe followed that convention through PDF 1.3 (1999).

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

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

2001: 128-bit RC4 after the export rules changed

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 straight away.

The cipher stayed RC4; only the key length grew. This is mode 10500 in Hashcat. A 2^128 key space 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 share of business PDFs in circulation used 128-bit RC4, and many still sit 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 designed specifically to replace ageing ciphers. There are no known practical attacks against 10-round AES-128 or 14-round AES-256 at full strength. Adopting AES future-proofed PDF encryption against cipher-level breakthroughs.

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

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

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 derivation 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 earlier generations: AES-256 has 2^256 possible keys, astronomically larger than 2^128 and both far beyond brute force, and quantum-resistant; and the SHA-256 derivation chain throttles password-search throughput on GPUs.

The combination matters more than either part alone. AES-256 with a fast derivation would still be password-bound and recoverable for weak passwords. The slow derivation cuts the number of attempts per second, which lengthens 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) and Length (key bits). Together with the optional CFM field on V=4 and V=5, they identify the encryption tier unambiguously:

• 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 does not matter for recovery. The cipher key is 40 bits and the whole key space is searchable. Whether you set 'apple' or '8&#wQ@9zR$1qE!' as your password, recovery works on the 2^40 key space, not on the password's character pattern.

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

This is the single most important practical insight when you look 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) is the modern strong tier. New password-protected PDFs created in 2024-2026 are predominantly in this mode by default in Adobe products.