PDF encryption makes use of the following encryption algorithms:
RC4, a symmetric stream cipher (i.e. the same algorithm can be used to encrypt and decrypt). RC4 no longer offers adequate security and has been deprecated in PDF 2.0.
Since the actual encryption keys are unwieldy binary sequences, they are derived from more user-friendly passwords which consist of plain characters. In the course of PDF and Acrobat development the PDF encryption methods have been enhanced to use stronger algorithms, longer encryption keys, and more sophisticated passwords.
Encryption algorithms, key length, and password length in PDF versions
|PDF and Acrobat version||encryption algorithm and key length||max. password length and|
|PDF 1.1 - 1.3 (Acrobat 2-4)||RC4 40-bit (weak, should not be used)||32 characters (Latin-1)|
|PDF 1.4 (Acrobat 5)||RC4 128-bit(weak, should not be used)||32 characters (Latin-1)|
|PDF 1.5 (Acrobat 6)||same as PDF 1.4, but different application of encryption method (weak, should not be used)||32 characters (Latin-1)|
|PDF 1.6 (Acrobat 7) and PDF 1.7 = ISO 32000-1 (Acrobat 8)||AES-128||32 characters (Latin-1)|
|PDF 1.7 Adobe Extension Level 3 (Acrobat 9)||AES-256 with weakness in password handling||127 UTF-8 bytes (Unicode)|
PDF 1.7 Adobe Extension Level 8 (Acrobat X/XI/DC) and PDF 2.0 = ISO 32000-2 (specification not yet publicly available)
|AES-256, with shortcomings in password handling (weak, should not be used)||127 UTF-8 bytes (Unicode)|
Note that AES-256 is not supported by the native PDF viewers on OS X/macOS (tested up to OS X 10.10.3) and iOS (tested up to iOS 8.1.3).
PDF encryption doesn’t apply the user or master password directly for encrypting the document contents, but calculates an encryption key from the password and other parameters including the permission settings. The length of the encryption key used for actually encrypting the document is independent from the length of the password (see table above).
PDF encryption internally works with encryption keys of 40, 128, or 256 bit depending on the PDF version. The binary encryption key is derived from a password provided by the user. The password is subject to length and encoding constraints:
Up to PDF 1.7 (ISO 32000-1) passwords were restricted to a maximum length of 32 characters and could contain only characters from the Latin-1 encoding.
PDF 1.7 Adobe Extension Level 3 introduced Unicode characters and bumped the maximum length to 127 bytes in the UTF-8 representation of the password. Since UTF-8 encodes characters with a variable length of 1-4 bytes the allowed number of Unicode characters in the password is less than 127 if it contains non-ASCII characters. For example, since Japanese characters usually require 3 bytes in UTF-8 representation, up to 42 Japanese characters can be used in passwords.
In order to avoid ambiguities, Unicode passwords are normalized by a process called SASLprep (specified in RFC 4013 based on Stringprep in RFC 3454). This process eliminates non-text characters and normalizes certain character classes (e.g. non-ASCII space characters are mapped to the ASCII space character U+0020). The password is normalized to Unicode normalization form NFKC, and special bidirectional processing is applied to avoid ambiguities which may otherwise arise if right-to-left and left-to-right characters are mixed in a password.
The strength of PDF encryption is not only determined by the length of the encryption key, but also by the length and quality of the password. It is widely known that names, plain words, etc. should not be used as passwords since these can easily be guessed or systematically tried using a so-called dictionary attack. Surveys have shown that a significant number of passwords are chosen to be the spouse’s or pet’s name, the user’s birthday, the children’s nickname etc., and can therefore easily be guessed.
Please see here for more detailed recommendation regarding secure PDF password protection.