[
https://issues.apache.org/jira/browse/PDFBOX-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212565#comment-14212565
]
Tilman Hausherr commented on PDFBOX-2456:
-----------------------------------------
More on my comment about the MD5 hash loop:
- gs uses the method I mention, not the one from Adobe spec
- one open source password finder (I won't mention the name) uses the method I
mention
- pdf.js uses the adobe method, is unable to open one file we produce by using
the owner password
- i*epdf uses the adobe method, but does it differently to the spec at another
place
To make it even more confusing, a file that Maruan created for me can (with a
short password) be opened by using both hash methods.
Looking at the Adobe spec I get this in "Algorithm 3: Computing the encryption
dictionary’s O (owner password) value":
{quote}
c)(Security handlers of revision 3 or greater) Do the following 50 times: Take
the output from the previous MD5 hash and pass it as input into a new MD5 hash.
{quote}
A look at StandardSecurityHandler.computeOwnerPassword() shows this:
{code}
md.update( digest, 0, length );
{code}
So our code there would be wrong for years, and would have to be changed in
{code}
md.update( digest );
{code}
Now I can open the file I created in pdf.js (which uses the method described in
the spec to get the user password from the owner password) and in a closed
source product, but no longer in Adobe Reader.
The problem with the current code is that "steps (a) to (d) of "Algorithm 3:
Computing the encryption dictionary’s O (owner password) value" is at two
different places, with different digest parameters, once the one in the spec,
and once the one that works.
The old repository is no longer available, so maybe we'll never know what the
original developers thought. The parameters they used to encode the owner
password are the ones that allows to open the file in AR. The "no length
parameter" described in the spec doesn't. Thus I'll keep the parameters that
work, and use these for the decoding, and refactor that part so it exists only
once. The files we create won't change, but they can now be opened with the
owner password. And I'll be able to check the permissions in this test. (All
coming tonight)
> create TestSymmetricKeyEncryption.java
> --------------------------------------
>
> Key: PDFBOX-2456
> URL: https://issues.apache.org/jira/browse/PDFBOX-2456
> Project: PDFBox
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 1.8.7, 1.8.8, 2.0.0
> Environment: java7 debian7
> Reporter: Ralf Hauser
> Assignee: Tilman Hausherr
> Labels: AES256
> Fix For: 1.8.8, 2.0.0
>
> Attachments: AES256.diff, PasswordSample-256bit.pdf,
> TestSymmetricKeyEncryption.java, enc128bit_20141025_115145.pdf,
> enc256bit_20141025_105451.pdf, preEnc_20141025_105451.pdf,
> preEnc_20141025_115145.pdf
>
>
> similarly to org.apache.pdfbox.encryption.TestPublicKeyEncryption, also test
> password based encryption
> 1) 128bit
> 2) 256bit AES PDFBOX-1594
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
