[
https://issues.apache.org/jira/browse/PDFBOX-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr reassigned PDFBOX-5312:
---------------------------------------
Assignee: Tilman Hausherr
> 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
> Components: Crypto
> Affects Versions: 2.0.24
> Reporter: Moritz Flöter
> Assignee: Tilman Hausherr
> Priority: Major
> Fix For: 2.0.25, 3.0.0 PDFBox
>
> 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. Therefore
> PDFBox correctly processes output from Adobe Acrobat. 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.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
