Encrypted/protected pdf failing on Microsoft Edge (Windows) and Adobe Acrobat (Android)
We have files that uses the following settings to disallow modifications:
encrypt_document(
permissions: {
modify_contents: false,
modify_annotations: false,
},
owner_password: :random
)
While the file appears to be fine, it will not open correctly in Microsoft Edge (Version 133.0.3065.51, 64-bit / Microsoft Windows 11 Pro Version 10.0.26100), and Acrobat Reader on Android. Attempting to open the file will cause an error message in those readers. No other PDF software is having problems, although some checks complain about the missing document id in the trailer.
Without the encryption settings, the document opens fine, and there does not seem to be any obvious errors.
Test file attached.
First off: You should not use Prawn to protect PDF files!. The algorithm Prawn uses is deprecated and should not be used anymore (it is the oldest possible version). If you need to do this, use a separate step afterwards with an application/library that supports a current encryption algorithm.
The document is encrypted with the algorithm /V 1 and a key length of 40bits. This means that algorithm 1 of section 7.6.3.2 of the PDF 2.0 specification is applied for encrypting/decrypting.
Furthermore, the value /R 2 means that the standard security handler revision 2 is to be used (see section 7.6.4.2). This handler calculates the file encryption key using the algorithm specified in section 7.6.4.3.2 which needs the /ID key of the trailer in step e. Also, table 15 in section 7.5.5 mentions that the /ID key is required if a file is encrypted.
This all means that you should make sure that there is an /ID entry in the trailer before encrypting the file to avoid issues because the file as it is is not compliant.
Many PDF libraries/viewers work around the problem by assuming that an empty string was used if the /ID key in the trailer is missing.
Thank you for looking into this. First off: We are fully aware that about the limitations of the encryption used. We need to set the "no edit" bit for compliance reasons. (And frankly, if no user password is given, the file is essentially unencrypted anyway - regardless of the algorithm used).
I have already attempted to include an \ID array, both by passing it to state.trailer in prawn, and by adding it directly to the file (both with an empty first element). This didn't fix the document.
As it is, prawn doesn't automatically generate the file identifier. Moreover, even if it were manually included, the implementation of the 7.6.4.3.2 algorithm in https://github.com/prawnpdf/prawn/blob/master/lib/prawn/security.rb#L179 omits the step that includes the ID into the encryption key, so a compliant reader shouldn't be able to derive the key from anything than an empty string on the /ID.