Summary: | 256 bit AES support | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Ralph Giles <ralph.giles> |
Component: | PDF Interpreter | Assignee: | Lars Uebernickel <lars> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | henry.stiles, jplavocos |
Priority: | P4 | Keywords: | bountiable |
Version: | master | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | Word Size: | --- | |
Attachments: |
aes256.pdf - sample file
aes256-patch AES encrypted file AES file with user password |
Description
Ralph Giles
2009-08-11 09:24:25 UTC
Created attachment 5296 [details]
aes256.pdf - sample file
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. |