This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Table 13.1 in the book lists the different PDF versions along with the most important functionality that was introduced in these versions.
40-bit encryption were introduced in Acrobat 2 (PDF 1.1).
128-bit encryption was introduced in Acrobat 5 (PDF 1.4).
AES encryption was introduced in Acrobat 7 (PDF 1.6). The algorithm used for the above encryption is (alleged) RC4.
All these types of encryption are supported in iText:
12.3 Encrypting a PDF document
12.3.1 Creating a password encrypted PDF
-> table 12.2 Overview of the permission parameters
-> table 12.3 Overview of the encryption parameters:
* 40-bit ARC4 encryption
* 128-bit ARC4 encryption
* 128-bit AES encryption
12.3.2 Public-key encryption
* this is also known as certificate encryption
Please understand that password protection in PDF isn't real security. It's very easy to crack a password, and since PDF became an ISO standard Adobe no longer has any legal basis to pursue companies that provide cracking software.
The ElcomSoft/Sklyarov case is something of the past.
Whoever is asking for PDF password protection should know that this concept is purely psychological, and that iText can't be blamed if somebody succeeds in decrypting a PDF that was password encrypted by iText.
Certificate encryption is a better means to protect the document, but this concepts has its flaws too: you can use certificate (aka public-key) encryption to add restrictions (for instance: the user is not allowed to print the PDF), but these restrictions can be removed by the person owning the private key corresponding with the public key that was used to encrypt the document. As a matter of fact, I explain how to remove these restrictions in the book (after I checked with Adobe and with a lawyer if I was allowed to describe how to do this).
iText doesn't offer any DRM solution as DRM is not part of ISO-32000-1.
Note that chapter 12 also discusses digital signatures. I'm not sure if your question about security was only about encryption or if you also wanted to know about digital signatures to protect the integrity of a PDF document.
12.4: Digital signatures, OCSP and timestamping
* 12.4.1: Creating an unsigned signature field
* 12.4.2: Signing a PDF
* 12.4.3: Adding multiple signatures
* 12.4.4: Verifying the signatures in a document
* 12.4.5: Creating the digest and signing externally
* 12.4.6: CRLs, OCSP, and timestamping
* 12.4.7: PDF Advanced Electronic Signature profiles (PAdES)
iText supports both author and recipient signatures. All of the technologies mentioned in the above TOC are supported, except for PAdES.
Some developers have already created PDFs that are compliant with the different ETSI standards regarding PAdES, but as PAdES is only supported in Acrobat X, we've only just begun developing high-level methods. These will probably be available in 11Q1.
Joined: Dec 16, 2003
Thank you for your reply.
Yes, I'm also interested in digital signatures, because one of the recurring business requirements
is paperless and besides of getting rid of paper procedures digital signatures need to replace
blue ink signatures...
I am working on a project that requires password-based encryption for PDF file. The PDF file contains sensitive data, and the requirement is to add a open-level password. I have been thinking that using PDF Password Protection (choose AES128) is the same as encrypting the file itself using AES128, until I saw your post here:
"Whoever is asking for PDF password protection should know that this concept is purely psychological, and that iText can't be blamed if somebody succeeds in decrypting a PDF that was password encrypted by iText."
Here is my question:
Option 1: Use a symmetric encryption (password already communicated and satisfies desired complexity rule) to encrypt a PDF file. This way, I would have to require the recipient install the same software I use to decrypt the file.
Option 2: Use the built-in PDF "user password" a.k.a. "open password" (password already communicated and satisfies desired complexity rule)
The only difference between option 1 and 2 may be the length of the password (Option 2 built-in PDF password has to be less than 32 chars - but 32 chars are plenty for me). So, are there any other difference between option 1 and option 2, from a security perspective?
If there is no difference, I think the concept of asking for PDF password protection is NOT purely psychological then because it is very hard to crack the password.
I bought your book (second edition), and read chapter 12.3 "Protecting your PDF". As far as I understand, the
"user password" is quite secure, as long as you have a strong password...
Joined: Oct 23, 2006
Zhang Ye wrote:As far as I understand, the "user password" is quite secure, as long as you have a strong password...
That's a misconception. Any PDF encrypted with a "user password" and/or "owner password" can easily be decrypted (not by using brute force, just because password security in PDF is... flawed).
It's a mystery why there are still people who think it makes sense to password protect a PDF.
Joined: Feb 06, 2011
Thanks a lot for your reply.
I am quite shocked (clearly, you are very knowledgeable on this) because I read a lot of companies are sending password-protected PDFs containing sensitive data such as Credit Card number. Yet you just said the whole user/owner password for PDF is flawed and cracking the password requires NO brutal force.
Here are two companies (one of them, Arcot, was just acquired by CA for $200Million) doing this: