You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Christian Appl (Jira)" <ji...@apache.org> on 2020/09/16 08:57:00 UTC
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128
encryption for public key
[ 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, 8: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?
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
>
>
> 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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org