PDF has a reputation as the boring, dependable file format – the one you reach for when you need a document to look exactly the same on every computer, forever. What gets forgotten is that PDF’s security model has been shaky since version 1.0, and its history includes an FBI arrest, a federal jury trial that helped define how the DMCA actually works, and – twenty years later – a fake GIF that hid a tiny working computer inside an image compression stream. This is that story, roughly in order, including the part where we were personally on the receiving end of it.

Where it all started: Adobe’s eBook experiment

Back in 1999–2001, Adobe was chasing the “eBook” market with the Acrobat eBook Reader (originally the GlassBook Reader) and a back-end called the Adobe Content Server. Publishers could lock a book down with any of several plug-in “security handlers” – Adobe’s own PDF Merchant and EBX, plus third-party schemes like FileOpen and SoftLock – restricting printing, copying, lending, or text-to-speech.

All of them shared the same underlying weakness, and it wasn’t really about key length. A PDF reader has to decrypt the file to show it to you, which means the decryption key has to exist, in the clear, somewhere on your own computer at some point. Dongles, server calls, asymmetric key exchange – didn’t matter. The key always ended up local. Our own explanation at the time boiled the whole problem down to one line: any security plug-in, no matter how it was built, ultimately had to “return a decryption key to Adobe Acrobat Reader.”

That single observation is basically the entire history of PDF security in one sentence, and it’s still true today.

The tool that broke it all

In 2001, Dmitry Sklyarov, who worked at ElcomSoft at the time, built the Advanced eBook Processor (AEBPR) – a $99 utility that took a legitimately purchased, locked-down eBook and re-saved it as a plain, unrestricted PDF. Technically, it worked by locating the point where a reader computed its document key (derived via MD5 from the user/owner passwords, the permission flags, and a file ID) and simply grabbing the key right there in memory, before it got used. Sklyarov demonstrated it worked against half a dozen different DRM schemes of the day.

The underlying PDF encryption wasn’t helping matters either. Early PDF used 40-bit RC4 – a key length capped by 1990s US export rules, the same restriction that gave Microsoft Office its infamously weak 40-bit mode. Sklyarov calculated a single PIII-450 could brute-force one 40-bit key in about 40 days; commercial “password crackers” of the era were already offering to do it in under 25 days for $500. When Stephen King released the eBook-only novella Riding the Bullet in 2000, pirated copies were circulating within days. The writing, so to speak, was on the wall well before AEBPR came along.

Sklyarov presented all of this at DEF CON 9 in Las Vegas, in a talk called “eBook Security: Theory and Practice.” The point wasn’t piracy – it was that Adobe had built a commercial protection scheme on a foundation no cryptographer would have signed off on.

July 16, 2001

As the conference wrapped and Sklyarov was checking out to fly home to Moscow, the FBI arrested him on Adobe’s complaint, under the newly minted DMCA anti-circumvention provisions. He was held in Las Vegas, then transferred through a federal facility in Oklahoma City, then to San Jose. He made bail – $50,000 – on August 6, but was barred from leaving Northern California, separated from his family in Russia, for over four months.

The arrest of a programmer for a conference talk did not go over quietly. “Free Sklyarov” campaigns and an Adobe boycott sprang up almost overnight, run out of sites like freesklyarov.org. About a week later, after meeting with the EFF, Adobe actually withdrew its support for the case. The Association of American Publishers went the other way and publicly backed the prosecution. It was a genuinely strange few weeks.

United States v. ElcomSoft

Adobe dropping its complaint didn’t end the case – the Department of Justice, under then–US Attorney Robert Mueller (who’d become FBI Director later that same year), decided to proceed anyway. The legal hook was that ElcomSoft, a Moscow company, had contracted with an American reseller, RegNow, to process US payments – enough for a US court to claim jurisdiction, even though the software was entirely legal to write and sell in Russia.

The charges against Sklyarov personally were dropped in exchange for testimony against his employer and permission to go home, which he did on December 13, 2001. ElcomSoft went to trial alone. After a two-week trial in San Jose, a federal jury acquitted the company of all four DMCA charges on December 17, 2002 – one of the first real courtroom tests of the DMCA’s anti-circumvention clause, and a genuinely awkward moment for a law that had assumed nobody would push back this hard.

Our then-president, Alex Katalov, didn’t mince words about what the case meant for any foreign software company doing business online: absent clearer rules, he said, it was “advisable… to avoid going to the United States.” Adobe’s own CEO at the time, Bruce Chizen, later admitted in an interview that better communication before the case became public could have avoided most of it.

We wrote a blog post on it at the time: Defending Americans’ Right to Decrypt.

One thing still makes us shake our heads a little, all these years later, and it has nothing to do with Adobe or the DOJ. A couple of the digital-rights and free-speech groups that rallied around the case at the time collected donations earmarked in our name. As far as we’ve ever been able to tell, none of that money made it to us. We’re not naming anyone or holding a grudge about it – it was a long time ago, and it’s probably more a cultural/organizational quirk than anything sinister. Just a genuinely odd footnote to a case that was odd from start to finish.

The encryption kept “improving” – mostly

Setting the lawsuit aside, PDF encryption itself kept evolving, not always in a straight line toward “better”:

• PDF 1.0–1.3 (Acrobat 2–4): 40-bit RC4 only, again thanks to export restrictions. Trivially brute-forceable, as above.
• PDF 1.4 (Acrobat 5, 2001): bumped to 128-bit RC4.
• PDF 1.7 (Acrobat 9, 2008): introduced 256-bit AES – but the password-check routine boiled down to a single unsalted SHA-256 hash, which actually made password guessing faster than it had been against the older 128-bit scheme. ISO eventually fixed this with a proper multi-round hash in PDF 2.0 (Acrobat X and up, “Revision 6”).
• Throughout all of this: the “owner”/permissions password – the one meant to lock printing, copying, and editing – has never actually gated the decryption key. Any compliant reader gets the key regardless, which is why permission restrictions on a PDF can be stripped instantly, with no password needed at all, on any version of the format, to this day.

We ended up building a fair amount of our own company history directly on top of that last point. Advanced PDF Password Recovery got the ability to strip owner restrictions instantly early on, and in 2007 we introduced Thunder Tables – precomputed tables (built on the time-memory tradeoff idea Philippe Oechslin popularized in 2003, itself an extension of Martin Hellman’s original 1980 work) that turned recovering a 40-bit PDF key from days of brute force into under a minute, shipped on a 4 GB DVD. As encryption strengths grew, so did our approach – GPU acceleration became standard once 256-bit AES arrived. When Acrobat X’s flavor of AES-256 needed support, Sklyarov – by then ElcomSoft’s crypto analyst – was characteristically understated about it: “It wasn’t all that difficult.”

PDF kept finding new ways to misbehave

The lawsuit and the weak-encryption story aren’t the only chapters. PDF has kept surprising researchers well into the modern era, unrelated to anything ElcomSoft has built:

PDFex (2019). Researchers from Ruhr University Bochum and FH Münster found that PDF’s spec allows mixing encrypted and unencrypted content in the same file, combined with unauthenticated CBC-mode encryption. The result: an attacker who doesn’t know the password can still tamper with an encrypted PDF so that, the moment the legitimate recipient opens it, its plaintext gets quietly phoned home. They tested 27 mainstream PDF viewers – including Acrobat, Chrome, and Firefox’s built-in readers – and found every single one vulnerable to at least one variant.

FORCEDENTRY (2021). The most dramatic PDF story of the last decade wasn’t about encryption at all. NSO Group’s Pegasus spyware delivered a zero-click iMessage exploit disguised as a .gif file that was actually a PDF containing a JBIG2 image stream. Google’s Project Zero found the attackers had abused JBIG2’s compression logic to emulate a small, functioning computer – logic gates and all – entirely inside the image data, well enough to hijack the phone with no user interaction at all. Google researchers who reverse-engineered it called it “pretty terrifying.” Twenty years after Sklyarov’s DEF CON talk, PDF was still finding new ways to be more than just a document format.

Where this leaves us

Twenty-five years on, the throughline hasn’t really changed: PDF’s biggest vulnerabilities have almost always been architectural, not mathematical – keys that have to exist locally, permissions that were never really enforced, encryption that mixes trusted and untrusted content in the same container. We’ve spent a good chunk of our history on the “figuring this out” side of that story.

If you’re locked out of your own PDF today – a forgotten open password, restrictions left over from a document you no longer have the original of – Advanced PDF Password Recovery handles the whole range, from instant removal of owner/permission locks to GPU-accelerated attacks against 128- and 256-bit AES. And if you’re dealing with this at scale – a forensic lab, a corporate IT case, a pile of files rather than one – Elcomsoft Distributed Password Recovery spreads the job across every GPU and machine you’ve got, scaling linearly up to thousands of workstations. Two products, same underlying lesson we first ran into back in 2001: PDF “security” and PDF encryption have never quite been the same thing.