You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Moritz Flöter (Jira)" <ji...@apache.org> on 2021/11/04 15:07:00 UTC
[jira] [Updated] (PDFBOX-5312) Decryption for V4 fails when no
Length entry is set in Encryption Dictionary
[ https://issues.apache.org/jira/browse/PDFBOX-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Moritz Flöter updated PDFBOX-5312:
----------------------------------
Description:
The PDF standard defines the "Length" entry in the encryption dictionary to only have an effect in V2 or V3.
However, PDFBox relies on that value for V4 as well and fails to decrypt files that do not define this length entry. It does not consider the length entry in the crypt filter dictionary instead that could be used to get information about the length:
<</StdCF
<</CFM
/AESV2/Length
16>>>>
It should be noted that Adobe Acrobat generates files with the required "Length" entry in the encryption dictionary even when V4 is used. It would however be desirable for PDFBox to also handle other output that conforms to the PDF-Standard.
I attached a file that is encrypted with an empty password and fails to be decrypted by pdfbox. However, you can open it with SumatraPDF, Acrobat Reader, Okular etc. (ignore the text on the actual page of the pdf-file ... our application read an RC4 file and wrote the output as AES 128Bit)
was:
The PDF standard defines the "Length" entry in the encryption dictionary to only have an effect in V2 or V3.
However, PDFBox relies on that value for V4 as well and fails to decrypt files that do not define this length entry. It does not consider the entry in the crypt filte dictionary instead:
<</StdCF
<</CFM
/AESV2/Length
16>>>>
It should be noted that Adobe Acrobat generates files with the required "Length" entry in the encryption dictionary even when V4 is used. It would however be desirable for PDFBox to also handle other output that conforms to the PDF-Standard.
I attached a file that is encrypted with an empty password and fails to be decrypted by pdfbox. However, you can open it with SumatraPDF, Acrobat Reader, Okular etc. (ignore the text on the actual page of the pdf-file ... our application read an RC4 file and wrote the output as AES 128Bit)
> Decryption for V4 fails when no Length entry is set in Encryption Dictionary
> ----------------------------------------------------------------------------
>
> Key: PDFBOX-5312
> URL: https://issues.apache.org/jira/browse/PDFBOX-5312
> Project: PDFBox
> Issue Type: Bug
> Reporter: Moritz Flöter
> Priority: Major
> Attachments: ausdat.pdf
>
>
> The PDF standard defines the "Length" entry in the encryption dictionary to only have an effect in V2 or V3.
> However, PDFBox relies on that value for V4 as well and fails to decrypt files that do not define this length entry. It does not consider the length entry in the crypt filter dictionary instead that could be used to get information about the length:
> <</StdCF
> <</CFM
> /AESV2/Length
> 16>>>>
> It should be noted that Adobe Acrobat generates files with the required "Length" entry in the encryption dictionary even when V4 is used. It would however be desirable for PDFBox to also handle other output that conforms to the PDF-Standard.
> I attached a file that is encrypted with an empty password and fails to be decrypted by pdfbox. However, you can open it with SumatraPDF, Acrobat Reader, Okular etc. (ignore the text on the actual page of the pdf-file ... our application read an RC4 file and wrote the output as AES 128Bit)
--
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