RC4, AES-128, AES-256: what PDF password protection actually does

"Password-protected PDF" gets treated as a single category, but the format has gone through three genuinely different encryption schemes since it was introduced, and the strength of the protection you get depends entirely on which one a given tool actually uses — a detail almost no tool interface shows you, and one worth understanding before you rely on it for something that matters.

A short, relevant history

The original PDF encryption, from the 1990s, used RC4 with a 40-bit key — a length that was already considered weak by cryptographic standards of the time, chosen partly because of US export restrictions on stronger cryptography that were in effect when the format was designed. A 40-bit key has roughly a trillion possible values, which sounds like a lot until you remember that modern hardware can attempt billions of keys per second; a 40-bit RC4-encrypted PDF can be brute-forced in a practical amount of time on an ordinary computer today.

Later revisions of the specification introduced RC4 with a 128-bit key, and then AES — the Advanced Encryption Standard, the same cipher used to protect classified government information and most modern secure web traffic — first at 128 bits and later at 256. AES-256 is, as far as current cryptography is concerned, not brute-forceable with any hardware that exists or is likely to exist in the foreseeable future. The key space is large enough that even a highly optimistic estimate of future computing power does not bring an exhaustive search within reach.

The practical implication: "password-protected PDF" spans a range from genuinely trivial to break, to as strong as anything used to protect a bank's infrastructure, and the label alone does not tell you which end of that range you are on. If a tool or a document does not specify which cipher it uses, there is no way to know from the outside.

The asterisk almost nobody mentions: two passwords, one lock

The PDF specification actually defines two separate passwords, and this is the detail that catches people out. The user password is required to open the document at all. The owner password, also called the permissions password, is meant to restrict what someone can do once the document is open — printing, copying text, editing — without preventing them from opening it in the first place.

Here is the part worth being direct about: those permission restrictions are enforced by the reader software honouring flags stored in the file, not by the encryption itself preventing the actions. A PDF encrypted with only an owner password (no user password set, meaning anyone can open it) is fully readable the moment it opens — the encryption's job there is just to protect those permission flags from casual tampering, not to gate access to the content. Tools exist specifically to strip owner-password-only restrictions, and doing so does not require breaking AES at all, because the content was never actually locked behind the cipher — only the permission flags were, and a compliant tool can simply choose not to enforce them, or a non-compliant one can rewrite them.

This is precisely why our own protect tool sets the user password and the owner password to the same value: a document protected with only a permissions password creates an illusion of restriction that does not require breaking any encryption to bypass. If you actually need the document unreadable without a password, encrypting with a user password — the same password, functioning as both — is the version of "protected" that the cipher itself is doing real work to enforce.

What this means for a document you are protecting today

• Check which cipher a tool uses before trusting it with something sensitive. AES-256 is what current tools should default to; RC4 in any key length should be treated as legacy and insufficient for anything you would call confidential.
• A user password (required to open the file) is what actually gates access. An owner-only password (permissions without a required user password) is a courtesy restriction, not a security boundary, and should not be relied on as one.
• Password strength still matters more than cipher strength in practice. AES-256 with the password "password123" is broken the moment someone tries the ten most common passwords, which takes seconds regardless of how strong the underlying cipher is. The cipher protects against brute-forcing every possible key; it does nothing if the actual password is guessable.
• There is no recovery path for a forgotten strong password, by design — that is what makes it strong. Store it in a password manager rather than relying on memory or a sticky note.

Removing protection: what "unlocking" actually is

There is one more wrinkle worth knowing about, for anyone whose job involves sending sensitive files regularly: several regulatory frameworks (US HIPAA for health information, PCI DSS for payment card data, various sector-specific rules elsewhere) treat encryption of data in transit and at rest as either a required or a strongly recommended safeguard. A correctly-configured user password with AES-256 satisfies the spirit of that requirement for a PDF being emailed or stored; an owner-password-only file, despite technically being an encrypted PDF, generally does not, because the content is not actually gated. Anyone relying on password protection to meet a compliance obligation should confirm which kind their tool is actually applying.

A legitimate unlock tool does exactly one thing: given the correct password, it decrypts the document and writes out an unencrypted copy. This requires knowing the password — there is no way around that requirement for a properly AES-256-encrypted file, and any service claiming to unlock a PDF without the password is either attempting a dictionary of common passwords (which only works if the password was weak) or is specifically targeting the owner-password-only weakness described above, not actually breaking encryption.

Understanding this distinction matters because it tells you what to expect: if you have forgotten a genuinely strong user password on an AES-256 file, no tool, ours or anyone else's, can recover the content. That is not a limitation of a particular product; it is the cipher functioning as designed.

Why we set both passwords to the same value

Given the owner-password-only weakness described above, a protection tool that offers a permissions-only mode without clearly explaining what it does and does not accomplish is arguably worse than offering no permissions controls at all, because it creates false confidence. Our own choice is to keep this simple rather than clever: one password, required to open the file, doing the one job encryption can genuinely guarantee. If you specifically need permission flags — say, allowing printing but discouraging casual copying, for an internal audience that will not go looking for a workaround — that is a real and legitimate use case, but it is worth entering into with the accurate expectation that it is a courtesy, not a lock.