A new encryption method was added to PDF 1.8 (well, post ISO 32000 pdf, anyway) which supports 256 bit keys. It also modifies the various key calculation algorithms. It would be nice to support this in Ghostscript.
Created attachment 5296 [details] aes256.pdf - sample file
Cf http://pdf.editme.com/pdfISO-FR0040
Created attachment 5653 [details] aes256-patch This patch adds support for the new AES-256-based encryption method, including Unicode passwords (see below). It uses Aaron Gifford's BSD-licensed SHA-2 implementation. The new encryption method allows Unicode passwords, which need to be converted to UTF-8 and normalized with SASLprep before use. I've implemented this, but I made it optional -- here's what you get, depending on your OS and libraries: * ASCII passwords always work, no matter what. * If you're using a UTF-8 locale, or you're on Windows, then most Unicode passwords will work too (specifically, those that are already in the normalized form specified by SASLprep). * If you build with GNU libidn, and either you're on Windows or you have iconv, then all Unicode passwords will work regardless of locale or normalization. The nice part of this is that there are no new dependencies. Ghostscript should still build on all the platforms it built on before, and at worst you'll just be stuck with ASCII passwords. Since libidn isn't crucial, I didn't add it to the source tree; for now, there's just an autoconf test that will enable support for it if you have it installed. (If you want to use libidn on non-autoconf platforms, you have to edit the makefile by hand.) If you'd rather have libidn in the source tree, so you can get full Unicode password support out of the box on non-autoconf systems, let me know and I can add it to the patch. As you can probably guess, a fair amount of the complexity in this patch comes from supporting Unicode passwords on the various platforms. The actual encryption algorithm is simple -- the bulk of it is implemented as pdf_check_r5_password in Resource/Init/pdf_sec.ps, which is just a direct translation of Adobe's Algorithm 3.2a into PostScript. If you want, I can easily split the Unicode password stuff out into a separate patch, so you can evaluate the encryption code on its own. With this patch, Ghostscript successfully decrypts the PDF file above.
Note the Adobe document that specifies AES-256 extension is: http://www.adobe.com/devnet/acrobat/pdfs/adobe_supplement_iso32000.pdf
Created attachment 6249 [details] AES encrypted file AES 256 encrypted PDF file, password is 'Password'
Created attachment 6250 [details] AES file with user password AES 256 encrypted file with user password = Pasword
I have reviewed and merged Michael's patch as revision 11171. Some minor modifications were necessary to apply it to the current trunk. Thank you, Michael!
As far as I can tell, this should have been closed. BTW, the PDFPassword for Ken's file (attachment ID 6250) should be: -sPDFPassword=Password (not Pasword)
(In reply to comment #6) > Created attachment 6250 [details] > AES file with user password > > AES 256 encrypted file with user password = Pasword Ken I have downloaded Ghostcript 9.10. Using it for years to password encrypt RC3 128 bit..... -dEncryptionR=3 -dKeyLength=128 However, I cannot find the documentation as to the -dEncryptionR and -dKeyLength settings for 256-bit AES. Thank you for your time. John Plavocos
(In reply to comment #9) > (In reply to comment #6) > > Created attachment 6250 [details] > > AES file with user password > > > > AES 256 encrypted file with user password = Pasword > > Ken > I have downloaded Ghostcript 9.10. Using it for years to password encrypt > RC3 128 bit..... > > -dEncryptionR=3 -dKeyLength=128 > > However, I cannot find the documentation as to the > -dEncryptionR and -dKeyLength settings for 256-bit AES. There is no support for *creating* encrypted files with this method, this bug was for decrypting them.