Hi Matthew, On Sun, 27 Jan 2019 at 23:41, Matthew Brincke <[email protected]> wrote: > > EVP_CIPHER_block_size() and EVP_CIPHER_CTX_block_size() return the block size > of a cipher > when passed an EVP_CIPHER or EVP_CIPHER_CTX structure. The constant > EVP_MAX_IV_LENGTH is > also the maximum block length for all ciphers." The 1.1.0 documentation > doesn't have this > last sentence anymore, but says instead EVP_MAX_BLOCK_LENGTH is the maximum > block length. > Already in 1.0.2 (I don't have 1.1.* yet) the latter constant is 32, so if it > is that in > 1.1.* too, your patch could break with 32 extra bytes required instead of 16 > (what you're > giving). > [...] > This is because I don't think AES-256 (32 bytes key length) would > smaller-than-key > cipher blocks
Matthew, from wikipedia[1] : "For AES, NIST selected three members of the Rijndael family, each with a block size of 128 bits, but three different key lengths: 128, 192 and 256 bits." still from wikipedia [2]: "The winner of the AES contest, Rijndael, supports block and key sizes of 128, 192, and 256 bits, but in AES the block size is always 128 bits. The extra block sizes were not adopted by the AESstandard." So your concern should actually be relieved. I think the discussion could extend to why PdfEncrypt has all these hard to use Encrypt()/Decrypt() signatures that imply that the caller will know exactly the size of the input/output buffers to be passed, basically having a fragile design that can (and will) break depending on the internal implementation of inheritors of PdfEncrypt, which is what I'm observing. Without a better API EncryptTest::TestEncrypt is having an hard time trying to be abstract for all the decryption/encryption methods without PdfEncrypt providing more facilities to be abstract itself. In my tests, PdfEncrypt::CalculateStreamLength() was returning the correct size for the input buffer that will eventually be passed to EVP_DecryptUpdate(). This is a coincidence of the fact CalculateStreamLength() in PdfEncryptAESV2/PdfEncryptAESV3 is oversizing buffer than AES_IV_LENGTH, which is IV vector for AES and coincidentally is the same size of cipher block. A better API would hide these details and allocate input/output buffers of the right size (which of course can differ) for the user on demand. To be honest I'm not seeing anyone to change/improve the API for PdfEncrypt right now, and my fix is actually fixing a *test*, not core code, so I think an hotfix verified by the tests run with address sanitizer[3], which is similar that what I basically did in VisualStudio, should be enough for now. Cheers, Francesco [1] https://en.wikipedia.org/wiki/Advanced_Encryption_Standard [2] https://en.wikipedia.org/wiki/Block_size_(cryptography) [3] https://github.com/google/sanitizers/wiki/AddressSanitizer _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
