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.