.PDF File Format – Encryption

The encryption dictionary

The encryption dictionary must not be in an object stream. It is often a direct object in the trailer or cross-reference stream dictionary, or a plain indirect object.

Keys for each object

Every string and stream belongs to an indirect object, and is decrypted with a key made for that object. Up to V 4 (Algorithm 1):

1. Take the file key, n bytes long (5 for V 1, otherwise Length / 8, or 16 for AESV2).
2. Append the low three bytes of the object number and the low two bytes of the generation, each low byte first.
3. For AES, append the four bytes 73 41 6C 54, “sAlT”.
4. Take the MD5 hash, and use its first min(n + 5, 16) bytes as the key.

For V 5 (AES-256) there is no per-object key: the 32-byte file key is used for every object. A string or stream inside an object stream is not encrypted on its own, since the whole object stream is. Stream data is encrypted after the filters are applied, so a reader decrypts first and then decodes.

Crypt filters

From V 4, the CF dictionary names crypt filters, and StmF, StrF and EFF choose which is the default for streams, strings and embedded files. A stream can choose its own with a Crypt filter. The name Identity is built in and means no encryption. The usual name is StdCF.

<< /Filter /Standard /V 4 /R 4 /Length 128
   /CF << /StdCF << /Type /CryptFilter /CFM /AESV2 /AuthEvent /DocOpen /Length 16 >> >>
   /StmF /StdCF /StrF /StdCF
   /O <…32 bytes…> /U <…32 bytes…> /P -1084 >>

Only embedded files can be left for later with EFOpen: a file whose StmF and StrF are Identity and whose EFF is a real filter has readable pages and encrypted attachments.

AES

Both AES methods use cipher block chaining (CBC) with 16-byte blocks. The first 16 bytes of each encrypted string or stream are a random initialisation vector, and the rest is the ciphertext. Before encrypting, the data is padded to a multiple of 16 with 1 to 16 bytes, each holding the number of bytes added (PKCS#5), so there is always padding, even when the data is already a multiple of 16. A reader drops it after decrypting. An empty string encrypts to 32 bytes.

The standard security handler

The Standard handler uses two passwords. The user password opens the document. The owner password opens it with every permission. Both may be empty; a user password that is empty opens the file without asking, and the permissions are then the only protection, which a reader respects or not.

Revisions 2 to 4 are deprecated by PDF 2.0, but readers must still open them, since most encrypted files in circulation use them.

The file key, revisions 2 to 4

Algorithm 2, from a password:

1. Pad or cut the password to 32 bytes: take up to 32 bytes of it and fill the rest from the start of this padding string. An empty password is the whole string.

   28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
   2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A

2. Start an MD5 hash of those 32 bytes.
3. Add the 32 bytes of O.
4. Add P as four bytes, low byte first.
5. Add the first string of the trailer’s ID.
6. For R 4, if EncryptMetadata is false, add FF FF FF FF.
7. Finish the hash.
8. For R 3 and 4, 50 times: hash the first n bytes of the result again.
9. The file key is the first n bytes: 5 for R 2, Length / 8 otherwise.

Passwords for these revisions are bytes in PDFDocEncoding; characters outside it cannot be used.

Checking the user password, revisions 2 to 4

• R 2 (Algorithm 4): make the file key from the password, encrypt the 32-byte padding string with RC4 and that key. If the result equals U, the password is right.
• R 3 and 4 (Algorithm 5): make the file key; take the MD5 of the padding string followed by the first ID string; encrypt those 16 bytes with RC4 and the key; then 19 more times with RC4, each time with the key’s bytes XORed with the round number 1 to 19. If the result equals the first 16 bytes of U, the password is right. The other 16 bytes of U are arbitrary.

To test whether a file opens without a password, try the empty password. Most encrypted PDFs open this way.

Checking the owner password, revisions 2 to 4

O is the padded user password encrypted with a key made from the owner password (Algorithm 3). To check an owner password (Algorithm 7):

1. Pad it to 32 bytes as above, take the MD5, and for R 3 and 4 hash the result 50 more times. The first n bytes are an RC4 key.
2. For R 2, decrypt O once with that key. For R 3 and 4, decrypt it 20 times, with the key XORed with 19, 18 and so on down to 0.
3. The result is the padded user password. Check it as a user password; if it is right, so is the owner password, and the file key is the one it gives.

If a file has no owner password set, writers use the user password in its place.

Revisions 5 and 6: AES-256

Here the file key is 32 random bytes, stored encrypted in UE and OE. The passwords are Unicode: a password is prepared with SASLprep (RFC 4013), encoded in UTF-8 and cut to 127 bytes.

To open the file (Algorithm 2.A):

1. Prepare the password as above.
2. Owner password: if hash(password, O[32–39], U) equals O[0–31], it is the owner password. The intermediate key is hash(password, O[40–47], U), and the file key is OE decrypted with AES-256 in CBC mode, with a zero IV and no padding.
3. Otherwise, user password: if hash(password, U[32–39]) equals U[0–31], the intermediate key is hash(password, U[40–47]), and the file key is UE decrypted the same way.
4. Decrypt Perms with the file key, AES-256 in ECB mode. Bytes 9 to 11 must be adb; bytes 0 to 3 should match P, and byte 8 is T or F for EncryptMetadata. A reader that finds a mismatch should treat the file as tampered with.

The hash is SHA-256 of the concatenated inputs for R 5. That proved too fast to resist guessing, and R 6 uses Algorithm 2.B instead:

1. K = SHA-256(password + salt + u), where u is the 48-byte U when checking the owner password and nothing otherwise.
2. Repeat, counting rounds from 0:
   1. K1 = (password + K + u) repeated 64 times.
   2. E = AES-128-CBC encryption of K1, with the first 16 bytes of K as the key and the next 16 as the IV, without padding.
   3. Take the first 16 bytes of E as an unsigned big-endian number, modulo 3 (the same as the sum of those bytes modulo 3). 0 gives K = SHA-256(E), 1 SHA-384(E), 2 SHA-512(E).
   4. Stop after at least 64 rounds, at the first round whose last byte of E is not greater than the round number minus 32.
3. The hash is the first 32 bytes of K.

To write a file, a program picks the file key and the four salts at random, computes U and UE (Algorithm 8), then O and OE using the new U (Algorithm 9), then Perms (Algorithm 10): P as four bytes low byte first, FF FF FF FF, T or F, a d b, and four random bytes, encrypted with the file key in ECB mode.

Permissions

P is a set of bits, bit 1 the lowest. Bits 1 and 2 must be 0, and bits 7, 8 and 13 to 32 must be 1, so P is a negative number when written: -4 allows everything, -3904 allows nothing (in PDF 2.0, where bit 10 is always set, the least is -3392).

Permissions are a request to the reader, not a lock. The owner password, or a program that ignores them, gives every permission, since the user password alone decrypts the whole file.

What is not encrypted

• Cross-reference streams, which a reader needs before it can decrypt anything.
• The strings in the encryption dictionary itself.
• The strings of the trailer’s ID, which the key depends on.
• Strings inside a stream that is itself encrypted, such as text in content streams and objects in object streams.
• Streams and strings whose crypt filter is Identity.
• The document’s XMP metadata stream, when EncryptMetadata is false.

Public-key security handlers

A public-key handler, from PDF 1.3, encrypts the file for a list of recipients by their certificates instead of a password. Filter names the handler, often Adobe.PubSec, and SubFilter the format:

Recipients is an array of PKCS#7 (CMS) enveloped-data objects, one for each group of recipients with the same permissions. Each holds, encrypted to the recipients’ public keys, a 20-byte seed and four bytes of permissions. The file key is the SHA-1 hash (SHA-256 for AES-256) of the seed, the bytes of every Recipients string, and FF FF FF FF if the metadata is not encrypted, cut to the key length. From then on objects are decrypted as with the standard handler.

Encryption in PDF 2.0

PDF 2.0 deprecates RC4 in every form, AES-128 (AESV2), revisions 2 to 5 of the standard handler and the Length entries; a new PDF 2.0 file should use revision 6 with AESV3. It also requires the trailer’s ID in every file and adds the unencrypted wrapper document, an ordinary PDF that carries an encrypted one as an attachment. ISO/TS 32003 extends it with AES-GCM (AESV4, V 6, R 7), and ISO/TS 32004 adds integrity protection with a KDFSalt and a message authentication code.