[ 
https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196790#comment-17196790
 ] 

Christian Appl edited comment on PDFBOX-4421 at 9/16/20, 9:56 AM:
------------------------------------------------------------------

It would be one of our requirements for this to work and maybe we could 
contribute to resolve this issue? I am currently evaluating what might be the 
exact problem here and how it could be resolved.

*As far as I understand it:*
 {color:#000000}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color} 
attempts to determine a key of the correct length and content using the method 
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a 
document's "Encryption" dictionary, which should work, if the dictionary value 
"V" is set to either 2 or 3.

But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will 
create a key of insufficient length and padding (length: 10 = 40/8+5) for 
AES128 encrypted documents (As e.g. currently created by Adobe DC)

!image-2020-09-16-10-32-11-060.png!

According to the Reference Manual "V" 4 should make use of the streams "CF" 
"StmF" "StrF" to provide information about the used algorithm:
 !image-2020-09-16-10-33-55-201.png!

*Questions:*
 - Is my analysis correct?
 - Is implementing "V" 4 the missing piece here?
 - Do you have further information, that could be helpful to implement this?
 - Is this something, that I could possibly help with, or is a solution coming 
anyway?

*Edit:*
Having read through PDFBOX-4413 and some related tickets, my guess is, that 
PublicKeySecurityHandler should be operating somewhat comparable to the 
StandardSecurityHandler, concerning algorithms and especially "V" (which 
already seems to define behaviour for V 0 through 6).
I think exactly here would be the place to start this: (?)
 !image-2020-09-16-11-55-33-275.png! 


was (Author: capsvd):
It would be one of our requirements for this to work and maybe we could 
contribute to resolve this issue? I am currently evaluating what might be the 
exact problem here and how it could be resolved.

*As far as I understand it:*
 {color:#000000}org.apache.pdfbox.pdmodel.encryption.SecurityHandler{color} 
attempts to determine a key of the correct length and content using the method 
"calcFinalKey", which is dependend on the "Length" COSDictionary entry of a 
document's "Encryption" dictionary, which should work, if the dictionary value 
"V" is set to either 2 or 3.

But as "Length" is optional, defaults to 40 and is not used by "V" 4, this will 
create a key of insufficient length and padding (length: 10 = 40/8+5) for 
AES128 encrypted documents (As e.g. currently created by Adobe DC)

!image-2020-09-16-10-32-11-060.png!

According to the Reference Manual "V" 4 should make use of the streams "CF" 
"StmF" "StrF" to provide information about the used algorithm:
 !image-2020-09-16-10-33-55-201.png!

*Questions:*
 - Is my analysis correct?
 - Is implementing "V" 4 the missing piece here?
 - Do you have further information, that could be helpful to implement this?
 - Is this something, that I could possibly help with, or is a solution coming 
anyway?

*Edit:*
Having read through PDFBOX-4413 and some related tickets, my guess is, that 
PublicKeySecurityHandler should be operating somewhat comparable to the 
StandardSecurityHandler, concerning algorithms and especially "V" (which 
already seems to define behaviour for V 0 through 6.
I think exactly here would be the place to start this: (?)
 !image-2020-09-16-11-55-33-275.png! 

> Add support for AES128 encryption for public key
> ------------------------------------------------
>
>                 Key: PDFBOX-4421
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-4421
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Crypto
>    Affects Versions: 2.0.13
>            Reporter: Tilman Hausherr
>            Priority: Major
>              Labels: AES128
>         Attachments: image-2020-09-16-10-32-11-060.png, 
> image-2020-09-16-10-33-55-201.png, image-2020-09-16-11-55-33-275.png
>
>
> Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 
> doesn't when the file is generated by an external software. (local tests 
> work) We should at least get the decryption to work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Reply via email to