Please post the files you mention below (one that works and one that does not). Can’t really help w/o seeing real documents.
Here is the crypt filter file I generated https://www.dropbox.com/s/zpo7tlj6uog76yb/cryptfilter.pdf?dl=0
Here is an acrobat crypt filter file, just in case https://www.dropbox.com/s/99k6qrux99ladkd/acrobatX.pdf?dl=0
All of them have user password "userpassword1234", owner password is blank.
Thanks for taking a look at this, I appreciate it.
FYI I posted a reply to this thread but I guess I replied to me and not to you, hopefully you got notified.
Just wondering if you've had time to pull the files and reproduce the problem.
After two years, my dropbox links have expired, I will re-up them:
I will also link to two additional, considerably older versions of this question:'
PDF is supposed to be an ISO standard, but this behavior is undocumented, as is the behavior of encryption R 6. Fortunately, a skilled third-party managed to reverse-engineer that in a way that actually works. For this, I am at a loss.
Any chance a software engineer might be able to look at this sometime this decade?
Have you looked at ISO 32000-2, the latest version of the PDF standard? Are you still feeling as if this information is not clear?
Thank you for replying.
I didn't realize that ISO-32000-2 had been published, I bought a copy and did some reading. It looks like it documents /R 6, although I didn't step through the algorithm to see if it matches the (working) implementation. It doesn't document anything unusual about "encrypt-attachments only".
Today I did some additional testing for "encrypt-attachments only".
My software (CentraDoc) can read attachments from /R 5 and /R 6 files created by Acrobat X.
Acrobat X can read attachments from /R 5 and /R 6 files created by CentraDoc.
CentraDoc cannot read attachments from /R 4 files created by Acrobat X.
Acrobat X cannot read attachments from /R 4 files create by CentraDoc.
As described previously, the /R 4 example files are *identical* except for the "attachments only" settings and the lack of encryption on most of cryptfilter.pdf. Same file /ID (<00000000000000000000000000000000> <00000000000000000000000000000000>) same object id's (attachment stream is 16), same O and U keys, etc. etc.
Here are the differences in the encryption dictionary:
* fullencrypt.pdf ("encrypt everything except metadata"):
* cryptfilter.pdf ("encrypt-attachments only"):
cryptfilter.pdf includes the /Crypt filter on the relevant stream, and fullencrypt does not:
16 0 obj
/DecodeParms [ <<
/Filter [ /Crypt ]
/Length 17 0 R
AcrobatX won't read the encrypted attachment from the "encrypt-attachments only" file, but it will from "encrypt everything except metadata".
Once again: the bytes in the encrypted attachment streams are **identical** in the two files. They both look like this:
B7 37 E7 97 5B 18 62 EA
36 EC 6A 71 18 07 FA 35
B3 14 D0 9B 8E 6F 90 8C
3B A3 26 50 20 3E C8 2D
7C D0 7C C8 14 F2 4E C5
C4 25 99 6F D5 9D 97 38
There's nothing in the documentation that would account for these two sets of bytes being different.
This implies the calculated encryption key is somehow different for Acrobat in these two cases, since the algorithm (AES 128) should stay the same.
What's am I missing?
Some minor clarifications:
* The 16 byte random initializer for both files was set the same for testing
* There's nothing in the documentation that would explain why these these two sets of bytes *should* be different, when everything else is the same.
* R 5 and R 6 cases work if the stream bytes are the same for similar tests.
I’m having our security team take a look…
Thanks! Please keep me posted.
Just a ping to see if there is any feedback....
So I was reading the 32000-2 and saw something interesting that appears to conflict with the file you provided:
From the spec:
If a security handler of revision 4 or 5 is specified, then the standard security handler supports crypt filters.
The support appears to be limited to the Identity crypt filter and crypt filters named StdCF whose dictionaries contain an AuthEvent value of DocOpen.
Your StdCF dictionary contains /AuthEvent /EFOpen
For Crypt filters, the limitation seems to imply that EFOpen is not supported.
If I have misread or missed something please let me know. It's possible.
Somehow I missed the notification of your response. Just happened to be looking at the thread... Anyway:
/AuthEvent /EFOpen is how "encrypt attachments only" is specified. (Perhaps the new spec is disallowing this case because it isn't documented and/or doesn't work as documented). I just created a file with "encrypt attachments only" in Acrobat X Pro. The /Encrypt dictionary looks like this:
<< /CF <<
So I believe I have found the problem with the files you uploaded:
I had the same issue you described. Extracting the embedded text file from cryptfilter.pdf did not error but it wrote a 0-length file to disk.
I manually extracted and decrypted the file with no issue.
After reading the spec ISO_32000-2_2017(en) "very carefully" I noticed something that's going to make me have to change my own code as well...
In section 220.127.116.11.b
"For all strings and streams without crypt filter..." etc.
This section is the "usual" case. Most of the time, PDF objects are encrypted with the file level encryption dictionary.
And under those circumstances the key you use will be modified by the object number, generation number and lastly, a 4-byte salt, increasing the size of the file key by 9 bytes before you hash it.
That new key is used for decryption.
But when you use a crypt filter in the objects definition like:
16 0 obj
/DecodeParms [ <<
/Filter [ /Crypt ]
then section 18.104.22.168 no longer applies.
To test this, I created a document with one embedded file and did what you did; "encrypt attachments only".
I got the same structure you defined in your last post with the /EFOpen.
Ignoring section 22.214.171.124 and using only the file key as the decryption key, I was able to get the original file.
Long story short:
Due to the above section of the spec, it is impossible to have the same encrypted data in cryptfilter.pdf:[16 0 obj] that you have in fullencrypt.pdf:[16 0 obj]
2 different keys would have been used to encrypt the data.
Thanks for your prompt reply. Following your approach I have successfully decrypted an R 4 V 4 attachment created from Acrobat X with "encrypt attachments only".
This info is in PDF 32000-1:2008 section 7.6.2, but not in the Adobe PDF reference sixth edition. I didn't read the specs carefully enough.
I appreciate your assistance, let me know where to send the beer.