Protect a PDF

Choose a PDF, decide whether people should need a password to open it or only be limited in what they can do with it, and get back an encrypted copy. The encryption is carried out by your own machine, which matters more here than anywhere else on this site: the file you would have to hand a conversion service is the one that is not protected yet.

The two settings on this page are different things, not strong and weak

Requiring a password to open produces a document whose pages are unreadable to anyone without that secret. There is no partial state and no honour system. Software that does not have the password has nothing to display, and that stays true no matter which program someone reaches for.

Limiting what people can do produces something else entirely. The document opens for everyone, and it carries a set of flags saying which operations should be offered. A reader consults them and adjusts what it offers accordingly. The pages themselves are readable the whole time, which is why this option is worth choosing for a completely different reason from the first one: it marks intent. A report that opens for the whole company but is marked not-for-editing tells its next reader something true about how it is meant to be used.

Picking between them comes down to one question that has nothing to do with technology. Are you trying to keep the contents away from someone, or are you trying to tell the people who already have the contents what they should do with them? The first needs a password. The second does not, and adding one to it usually just means twelve people asking you for the password over the following week.

The password is the entire security decision, and the arithmetic is short

It is tempting to read AES-256 as the answer to how strong is this. It is not. The cipher is not what anyone attacks, because attacking it is not a thing anybody knows how to do. What gets attacked is the password, by trying candidates until one works, and how long that takes is decided by you at the moment you type it.

The useful way to think about it is how many possibilities somebody would have to work through. A password you invented yourself is worth much less here than its length suggests, because the ways humans build memorable passwords are few and well catalogued. Four words picked at random from a two thousand word list is about forty-four bits, since two thousand to the fourth power is roughly seventeen trillion. Adding a fifth word takes it to fifty-five. Swapping an o for a zero in something predictable adds one bit and costs you the ability to say it over the phone.

This matters more here than on documents produced by some other tools, for a reason that is spelled out in the next section, and the practical form of the advice is unglamorous: prefer length that comes from randomness over cleverness that comes from substitution. The box on this page counts the characters as you type, and says so when the total is under twelve.

Why the result line names a revision number

After a successful run this page reports something like AES-256, revision 5. The second half is not decoration, and no other tool we are aware of shows it, so it is worth explaining what it means before someone assumes it is a version of our software.

The standard security handler has been revised several times, and revisions 5 and 6 both use AES with a 256-bit key. They differ in how a candidate password is checked. Revision 5 hashes the password with its salt once. Revision 6, which arrived with the ISO version of the format, runs an iterated construction with dozens of rounds of hashing and a block cipher, specifically so that testing one guess costs meaningfully more than one hash. The content encryption is identical between them. The difference is entirely in the unit price of a guess.

This page writes revision 5, since that is what its audited encryption implementation produces, and the alternative would be for us to write our own implementation of a password derivation function. Hand-rolled cryptography in a tool whose whole job is protecting documents is a worse outcome than an honestly labelled older revision, so the number is on screen rather than hidden. It is also the reason the previous section pushes length so hard: with cheap verification, length is the variable you still control.

A password the recipient cannot get hold of protects nobody

The most common way protected documents fail has nothing to do with the encryption. The file goes out as an attachment, the password goes out in the body of the same message, and the result is a document that is exactly as private as the mail account it travelled through. Every step it passes takes both halves together.

Splitting them across two channels is what makes the protection real, and the channels have to be genuinely different. A follow-up email is the same channel. A message in the same chat thread is the same channel. A phone call, a text to a number you already had, or a rule the recipient was told once in person are different channels, and any of them is enough.

There is a related trap in how organisations pick passwords for batches of documents. A rule like four digits taken from the account number, or the recipient date of birth, is convenient because nobody has to be told anything, but the values it produces are drawn from a set small enough to work through completely, and often from information the recipient has given to a dozen other parties. If you are sending one document to one person, pick something random and tell them what it is. The rule is only worth having when you are sending thousands, and even then it is worth knowing that it is a filter rather than a lock.

Who will be able to open what you just made

AES-256 support arrived in mainstream readers around 2009 and is now everywhere that gets updated. Everywhere that gets updated is doing some work in that sentence. The places that lag are exactly the places documents tend to end up: the firmware in a multifunction printer, an e-reader bought years ago, a document management system that a department cannot upgrade without a project, the built-in preview in an older mail client.

That is what the AES-128 option is for. It is a genuinely older design, and choosing it is a deliberate trade of margin for reach rather than a mistake. If the document is going to one person on a current phone or laptop, there is no reason to use it. If it is going into a workflow you do not control and cannot test, it opens in more places.

One detail is handled for you. AES-256 was added to PDF 1.7 as an Adobe extension, and a file that simply claims to be version 1.7 gives a strict reader no way to know that a newer encryption scheme is inside. Files produced here declare that extension level in the document catalogue, which is what the specification asks for. Most tools skip it and get away with it because most readers do not check.

One thing no setting can change: the encryption does not survive being converted. If somebody opens your protected file and exports it to Word, or prints it to a new PDF, what comes out the other side has no password on it. That is not a hole in the format. It is what happens when a person who is allowed to read something makes a new copy of what they read.

Four checkboxes, and one flag that is deliberately not a checkbox

Printing, copying text, editing and commenting are the four choices that map onto something a person can picture. They start ticked, because a lock is what you asked for and a document you cannot print is not. Several tools default the other way, which is how people end up unable to print their own file and unsure what they did.

Underneath, the format offers more switches than that, and two of them are not worth their own control. Reordering pages travels with editing, and filling in a form field travels with commenting, because a document you may edit but may not reorder is a distinction nobody has ever wanted. They are set to match the box above them.

One switch is missing on purpose. There is a flag whose job is to say whether assistive technology may extract the text, and it is what people most often switch off by accident when they are aiming at copy protection. Turning it off does very little to someone determined to get the words out, and it makes the document unreadable to somebody using a screen reader. That is not a trade-off worth offering, and the current version of the specification agrees, having deprecated the flag and instructed readers to treat it as always permitted. It is always left on here.

Note also what the flags are and are not. Every one of them is a message to the reading software, honoured by programs that choose to honour it. They are worth setting because most software does, and because they record what you intended. They are not worth relying on as a barrier.

What is left uncovered once the file is encrypted

The protection applies to the contents. It does not apply to the name of the file, which travels in the clear and is often the most informative thing about it — a filename with a client name and a settlement amount in it has already said the interesting part. The page count and the approximate size are also apparent without the password.

It does not apply to anything the recipient chooses to do afterwards either. A person who can read a document can photograph the screen, retype a paragraph, or read it aloud on a call. Encryption is a good answer to interception and to a file reaching the wrong person; it is not an answer to a reader you should not have trusted, and no format-level feature is.

And it does not apply to your original. This page hands you a new encrypted copy and leaves the file you selected exactly as it was, sitting where it was, unprotected. That is the right default — silently modifying the file somebody dragged in would be a bad surprise — but it means the last step is yours. If the point of the exercise was that this document should not be lying around readable, the unprotected one is still lying around readable.

Two things done differently here, and why

The first concerns the owner password, the second secret in the format, the one that governs whether the permission flags can be changed. Many tools reuse the open password for it, which quietly means anyone who can open the document can also lift every restriction on it. Because there is no situation in which you need to know that value, this page generates a long random one, shows it to nobody, and discards it. The result line tells you how many bits of randomness went into it. The restrictions survive contact with the people who can read the document, which is the only version of that feature that means anything.

The second concerns files that already carry a permissions lock. Re-protecting one is not a matter of writing new settings over the old, because the old encryption dictionary carries values derived from the previous password. Left in place, the new file would ship a working offline check for a secret you were in the middle of retiring. The previous handler is taken apart before the new one goes on.

Both of these are invisible in the output. A file protected carelessly and a file protected carefully open the same way, look the same, and are the same size to within a rounding error. That is precisely why they are written down here rather than left as an implementation detail.

Where the document is while all this happens

Encryption, key derivation and the writing of the new file are all carried out by code already running on your own machine. Nothing is uploaded, nothing waits in a queue, no temporary copy lands on hardware belonging to somebody else, and no account exists. The general argument for that, together with the steps for checking it yourself, is set out on the page about tools that never upload rather than restated here.

What is specific to this page is which copy would have to travel. On a tool that removes protection, whatever you hand over is at least encrypted. Here it is the opposite: the file you would upload is the one that has no protection on it yet, and it is by definition a document you have just decided is sensitive enough to need a password. Uploading it to acquire protection means the unprotected version has already been somewhere you do not control, which is a strange sequence of events to accept in exchange for a lock.

The password you type has the same property and one more. It never enters a form field, never accompanies the file anywhere, and stops existing when the tab closes — and unlike a document password you are merely reusing, this one is a secret you are creating right now, for a document you are about to send to somebody.