[PDFBOX-5312] Decryption for V4 fails when no Length entry is set in Encryption Dictionary

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.24
• Fix Version/s: 2.0.25, 3.0.0 PDFBox
• Component/s: Crypto
• Assignee: Tilman Hausherr
• Reporter: Moritz Flöter
• Created: 04/Nov/21 15:06
• Updated: 17/Dec/21 06:50
• Resolved: 08/Dec/21 09:38

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. 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)

Issue Links

• is related to: PDFBOX-5345 IllegalArgumentException: Input buffer too short in StandardSecurityHandler.computeRC4key