PDF 1.4-1.6 RC4 128-bit Encryption — Hashcat Mode 10500

What PDF 1.4 changed

Released in 2001 alongside Acrobat 5.0, PDF 1.4 introduced V=2 and R=3 in the Standard Security Handler. The cipher remained RC4, but the key length became configurable from 40 bits up to 128 bits in 8-bit steps. From this point onward, virtually every commercial tool that produced password-protected PDFs defaulted to 128-bit.

PDF 1.5 (Acrobat 6, 2003) and PDF 1.6 (Acrobat 7, 2004) reused V=2/R=3 for password protection. Acrobat 7 also introduced V=4/R=4 with AES-128 as an option, but RC4 remained the default for several more years for compatibility.

The encrypt dictionary now carries `/V 2 /R 3 /Length 128`. The Length field is mandatory for V=2 because it is no longer fixed by the algorithm version.

• V (algorithm version) = 2
• R (revision) = 3
• Length: 40-128 bits (almost always 128)
• Cipher: RC4 with full configurable key length
• Padding: same Standard Security Handler 32-byte string

Why 128-bit recovery is fundamentally different

At 128 bits, the keyspace expands to 2^128 ≈ 3.4 × 10^38 — a number large enough that no realistic compute budget can exhaust it. The relevant constraint shifts from the cryptographic key to the password itself: the key derivation function (still based on MD5 and the 32-byte padding) is deterministic, so given a candidate password, a verifier can be computed and compared against the stored O/U values from the encrypt dictionary.

Practically, this means recovery for mode 10500 follows the rules of password attack rather than cryptographic attack. If the original password is short, predictable, dictionary-based, or built from common patterns (year, name, simple substitutions), recovery is feasible on reasonable timescales. If it is long, random, and high-entropy, recovery becomes asymptotically intractable.

There is no shortcut at the cipher level. RC4 has theoretical biases (FMS attack on related-key reuse, for example), but PDF's key-derivation function isolates the cipher key from the user password's input directly, so these attacks do not apply.

What 'feasibility' actually means here

Recovery feasibility for 128-bit RC4 PDFs lives on a spectrum, not a binary outcome. The single biggest predictor is whether you can give the recovery service hints about what the password is likely to look like — common pattern, length range, an old password you used to use, the year the file was created, the document author's name. Hints that narrow the search space turn an intractable brute force into a directed search.

A 6-character lowercase-only password is recovered very quickly because the keyspace is tiny (26^6 ≈ 308 million). A 12-character mixed-case password with digits and symbols is roughly 10^23 times harder. The same algorithm; the same hardware; entirely different recovery curves.

We don't publish specific recovery probabilities because they depend heavily on what the password is. What we will say: if you remember the rough shape of the password (length, character classes, a few words you might have used), provide that context up front. It is the difference between a practical recovery and a calculation that finishes after the heat-death of the sun.

Acrobat 6 and the 'compatibility tier' problem

Acrobat 6 (2003) was the first version to default to 128-bit RC4 for password-protected exports. It also introduced the per-permission encryption controls (printing allowed, copying allowed, modification allowed) that organisations relied on for distribution control.

Permission flags are stored in the P field of the encrypt dictionary as a signed 32-bit integer. They can be read without the password. However, the cipher itself encrypts strings and streams unconditionally — so even if you can read the permissions field, you can't read content without decrypting first.

A common misconception is that 'owner password' is fundamentally different from 'user password' for recovery purposes. They aren't: the owner password is hashed into a key that decrypts a 'real' user password (the O/U pair), and the document is encrypted with the user-password-derived key. Mode 10500 recovers the user password, which provides full read access regardless of which password type was originally set.

Files commonly in this revision

PDF 1.4-1.6 with 128-bit RC4 dominates the 'corporate-era' encrypted PDF population: mid-2000s tax filings, legal disclosure exports, payroll bundles, contractor SOWs, and bank statements from the 2003-2010 window. Many small-business document management systems standardised on Acrobat 6 or 7 and continued producing this format for years afterward.

Government archives are heavy in this revision because procurement cycles for desktop software are long. UK HMRC PDFs, Australian ATO documents, US IRS notices, and Canadian CRA notices from this era are predominantly mode 10500 with 128-bit keys.

Modern Acrobat (XI, DC, Pro 2020+) defaults to AES-256 (mode 10700), so freshly generated files are usually not in this category. But anything re-saved from an older template, or generated by an automation pipeline that wasn't updated, can still emerge as 128-bit RC4.

Practical questions for owners considering recovery

Three questions determine whether recovery is realistic in your case. First: do you have any memory of the password's general shape? A length range, a likely word, a favourite number — these narrow the search dramatically. Second: was the password generated by a password manager, or chosen by a human? Manager-generated passwords are random and high-entropy by design and typically out of reach; human-chosen passwords cluster around predictable patterns. Third: what is the document worth? A free check costs nothing and gives you a quick technical readout; a paid attempt is justified when the document has clear value.

The honest assessment for mode 10500 is that recovery success rates depend on password type. We won't quote a single number. We will tell you what we found in the free-check phase before you commit to anything paid.

Frequently Asked Questions

Related references