I wouldn't worry about the new extensions at this time. It was just a heads up in terms of design, to make sure that you didn't code yourself into a corner given today's situation.
Leonard -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Vazquez Sent: Saturday, August 02, 2008 11:49 AM To: [EMAIL PROTECTED] Cc: pdf-devel@gnu.org Subject: Re: [pdf-devel] Crypt module discussion [EMAIL PROTECTED] writes: > Just a note that Acrobat 9 includes a new encryption option that is > based on AES256, but with a completely different methodology for > generating the seed/initialization vector _AND_ which also now supports > Unicode passwords. > > David, do libgcrypt support AES256? > Yes, it does. However, jemarch. The question is that PDF Reference allows define new encryption methods known as security handlers, possibly provided by an external mechanism. We have discussed only the standard described by PDF Reference, which provides both V2 and AESV2 methods. Perhaps we could support others security handlers but it will not be work for pdf-crypt, but for higher layers, I think. Since we do not know anything about the methodology they will use. They could require more knowledge of pdf objects, for example. It occurs already in the standard security level too. The key is get from the object's id. The IV (for AESv2) is get from 16 first bytes from object itself. Pdf-crypt does not know anything about it. So, we can implement several methods in pdf-crypt now. But if we want to implement several security levels, perhaps it should be better write a interface to security handlers in the future. Cheers! --
