Hi Tilman On Thu, Feb 18, 2016 at 5:24 PM, Tilman Hausherr <[email protected]> wrote:
> It isn't supported. > > There are two alternatives if you use 2.0: > > 1) use keylength 256 => AES256 will be used > or > 2) change the source code. In StandardSecurityHandler.java there is a line > > //TODO return 4 if keyLength is 128 to enable AES128 functionality > > replace it with this: > > else if (keyLength == 128) > return 4; > > and your files can be encrypted with AES128 if you use keylen 128. > > There is no "official" way to enable AES128 encryption with a setter. The > AES128 encryption/decryption was implemented very recently by me (as part > of an issue that dealt with signing encrypted documents - PDFBOX-2729), I > didn't want to make too much changes before the 2.0 release because it > wouldn't have been tested enough. Took a quick comparison look at https://github.com/itext/itextpdf/blob/2aca066ea38a96a26ed9213655f667b2091f9bab/itext/src/main/java/com/itextpdf/text/pdf/PdfEncryption.java and pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/StandardSecurityHandler.java, and regarding the TODO you have mentioned above, I would have two questions: 1. In the version and revision number handling, you have prepared everything already for AES-128, so why did you not enable the "return 4" for keyLength == 128 in computeVersionNumber()? 2. The PDF reference 1.7 on page 119 in Algorithm 3.1 step 2 at the second paragraph mentions the backwards compatible salt composed of the byte sequence 0x73, 0x41, 0x6C, 0x54. I cannot find it in the StandardSecurityHandler.java in pdfxbox. Is this missing or am I shooting blanks here? Cheers Roberto
