I can confirm that changing the encryption to RSA 128bit on the program that is generating the pdf (TCPDF on PHP) fixes the problem

The length of the stream is invalid and the padding byte is invalid.
With all the checks disabled, the file renders OK.

Tom: Can you tell us what program you used to generate the pdf file please?
Could you also attach the same thing, saved with a different encryption (ideally no encryption) please?

That would enable us to double check that we really are decoding the streams correctly.

(In reply to comment #3)
> Tom: Can you tell us what program you used to generate the pdf file please?

It's using the PHP library called TCPDF, see http://sourceforge.net/projects/tcpdf/ or http://www.tcpdf.org/

> Could you also attach the same thing, saved with a different encryption
> (ideally no encryption) please?

I can send through the RSA 128bit version, for some reason I can't get it to not encrypt it at the moment.
Regards,
Tom

Created attachment 7670 [details]
Working PDF RSA 128bit

Alex, can you verify that the original attachment can be opened by other software (i.e. Adobe Acrobat)?  If not please close as invalid.

Acrobat 9 can open the sample file. Otherwise I'd closed the bug long ago.

Created attachment 8308 [details]
seattle_coversheet.pdf

A customer has reported the same problem; I've attached their sample file and changed the priority to P2.

Additional information from the customer:

This is a PDF form created by Adobe LifeCycle Designer ES 8.2. It is protected by a password and encrypted 128-bit AES. From what I can gather, encryption is performed in chunks, and all chucks must be the same length (via padding if necessary). It appears there's a problem with one of the padding bytes.  Ghostscript 9.04 reports "invalid aes padding byte".

If you open this file with Acrobat Pro 9.4.7, then "save a copy" (not "save as"), the following dialog appears: "This document enables extended features in Adobe Reader. 'Save A Copy' will create a copy of the document which does not enable extended features in Adobe Reader." The new copy (still AES encrypted) can be processed without error in Ghostscript 9.0

Cluster testing a workaround now:


diff --git a/gs/base/saes.c b/gs/base/saes.c
index d703961..25ceebe 100644
--- a/gs/base/saes.c
+++ b/gs/base/saes.c
@@ -147,9 +147,12 @@ s_aes_process(stream_state * ss, stream_cursor_read * pr,
              plaintext gives the number of bytes to discard */
           pad = temp[15];
           if (pad < 1 || pad > 16) {
-            gs_throw1(gs_error_rangecheck, "invalid aes padding byte (0x%02x)",
-                  (unsigned char)pad);
-            return ERRC;
+            /* Bug 692343 - don't error here, just warn. Take padding to be
+             * zero. This may give us a stream that's too long - preferable
+             * to the alternatives. */
+            gs_warn1("invalid aes padding byte (0x%02x)",
+                     (unsigned char)pad);
+            pad = 0;
           }
         } else {
           /* not using padding */

commit 0fb4785ef74fd22b8c1cced5ec16bd28d5bcc666
Author: Robin Watts <robin.watts@artifex.com>
Date:   Wed Jan 25 19:58:52 2012 +0000

    Fix Bug 692343 - ignore invalid padding length bytes.

    AES streams contain padding at the end to bring them up to 16
    byte chunks. The last byte of the plaintext is supposed to be
    a value between 1 and 16 telling us how many bytes to ignore
    from the last one? (Why 16? 15 would make more sense).

    If the padding byte was out of range we would previously have
    thrown an error. Here we change to just warn and set the
    padding length to 0. This means we'll err on the side of making
    the stream too long, which is better than the alternative.