PDF-Files, which are encrypted with 128-Bit AES ( beginning with PDF1.6 ) cannot be interpreted with GhostScript. The interpretation terminates with following message: Error: /ioerror in --token-- Operand stack: --dict:11/17(L)-- 2 --dict:82/82(ro)(G)-- --nostringval-- Execution stack:
Created attachment 2558 [details] example for a PDF-file with 128Bit AES encryption, which cannot be interpreted
*** Bug 688959 has been marked as a duplicate of this bug. ***
*** Bug 688960 has been marked as a duplicate of this bug. ***
Reassigning to Alex and adjusting priority to reflect a customer bug (not and enhancement, but a capability that is not yet supported in Ghostscript).
*** Bug 689639 has been marked as a duplicate of this bug. ***
Created attachment 4505 [details] aes-1.diff Attaching a patch for review. With this patch and the AES support additions of r8870-2, r9117, and r9118 Ghostscript properly decodes the file. The patch pulls the CFM out of the Encrypt dictionary every time it needs to know which cipher to use. Would it be more elegant to stash it in a global or stream key?
IMHO a few dictionary look-ups per an encrypted object should not have a noticeable effect on PDF interpreter performance. I see 2 minor improvements to the patch: - every object in the file can be an indirect object including the values of /StmF , /CF , /CFM - A few changes are in the spaces only and can be omitted.
Created attachment 4540 [details] 22169.pdf This is another AES-128 encrypted file that Ghostscript cannot read. With the unpatched gshead (r9180) reads 22169.pdf with the following warning repeated multiple times; **** Error reading a content stream. The page may be incomplete. and produces blank pages. With the patch from comment #6 applied the following error is produced: GPL Ghostscript SVN PRE-RELEASE 8.64 (2008-08-02) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 15. Page 1 Error: /undefined in --run-- Operand stack: --nostringval-- --dict:7/7(L)-- --dict:48/48(ro)(L)-- --nostringval-- PageSpotColors --dict:7/7(L)-- --dict:0/0(L)-- --dict:1/4(L)-- 1127 (\200t\345!\263\362,\251n>\034\272\2052j\307) 69 0 --nostringval-- Subtype Form Length 576 OC --nostringval-- PieceInfo --nostringval-- ADBE_CompoundType --nostringval-- Private Watermark LastModified (\200t\345!\263\362,\251n>\034\272\2052j\307) (H\221@\016\275\330\022\000\020\000\000\000\275\330\022\000\261\376\235\3068zA\326\177\201A\356,\304\327\322\374\226E\213}\235\271\201\251\201Y\023V*J\273) --dict:6/6(L)-- Encryption Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1846 1 3 %oparray_pop 1845 1 3 %oparray_pop 1829 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 15 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- %loop_continue --nostringval-- --dict:1/1(L)-- --nostringval-- 1 %dict_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1142/1684(ro)(G)-- --dict:1/20(G)-- --dict:74/200(L)-- --dict:74/200(L)-- --dict:106/127(ro)(G)-- --dict:278/300(ro)(G)-- --dict:22/25(L)-- --dict:3/5(L)-- Current allocation mode is local GPL Ghostscript SVN PRE-RELEASE 8.64: Unrecoverable error, exit code 1
Created attachment 4607 [details] PLANTILLA_PLANOS.pdf Another customer, #531, submitted a file with AES-128 encryption. I've updated the priority and attached the file.
The new file fails with the current patch similarly to 22169.pdf.
note that 22169 and PLANTILLA_PLANOS are the same file.
We anticipate progress in the August 2009 release.
NB the first customer's file works fine after r9232, and support for this will be in the February 8.70 release.
*** Bug 690447 has been marked as a duplicate of this bug. ***
Created attachment 4973 [details] patch Fix 2 oversights in AES decryption code: - add enumeration of ctx member in AES state. Unmovable blocks are still garbage collected and need enumeration. - use correct names to access /CFM attribute. Apparently, this branch has not been exercised before. With this patch all sample files from this and duplicate bug report run to completion.
The path is committed as a rev. 9689. Regression testing shows no differences, in part, because we don't have a single AES encrypted PDF file in the regression suite.
Changing customer bugs that have been resolved more than a year ago to closed.