[
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:55 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?
> 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: [email protected]
For additional commands, e-mail: [email protected]
