Discussion:
[Podofo-users] what is the status of AES Decrypt/Encrypt
Andreas Brzesowsky
2014-02-25 13:25:45 UTC
Permalink
Hi,

I have added some code to decode AESV2 InputStream, some fixes for RC4
decoding and handling of the EncryptMetadata flag for RC4 and AESV2.
So some more encrypted pdf could be handled by PoDoFo.
I want to contribute my changes.
Are there any rules like coding rules or additional test cases I should
consider before contribution?
And how to contribute the best way?

Thanks and kind regards

Andy
--
dots <http://www.dots.de/en/>

Andreas Brzesowsky

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55

***@dots.de <mailto:***@dots.de>
http://www.dots.de <http://www.dots.de/>

Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
Geschäftsführer (Managing Directors): Olaf Lorenz, Ken Osuga

Follow us on: Twitter <http://www.dots.de/?id=twitter> Youtube
<http://www.dots.de/?id=youtube> Xing <http://www.dots.de/?id=xing>
zyx
2014-02-27 07:23:48 UTC
Permalink
Post by Andreas Brzesowsky
I have added some code to decode AESV2 InputStream, some fixes for RC4
decoding and handling of the EncryptMetadata flag for RC4 and AESV2.
So some more encrypted pdf could be handled by PoDoFo.
I want to contribute my changes.
Hello,
thanks for looking into this (I'm not a PoDoFo developer, but I'd like
to answer the below questions and thank you for your work).
Post by Andreas Brzesowsky
Are there any rules like coding rules or additional test cases I
should consider before contribution?
I do not think there is any written guide on coding style being used in
the PoDoFo code base, I did not find any at least, but the best would be
to pick some core file, like PdfDocument.c/.h and mimic its coding
style.

With respect of adding test cases, it's always a good thing to have more
tests, to spot regressions, thus they are welcome, but not mandatory.
Post by Andreas Brzesowsky
And how to contribute the best way?
You can send the patch to this list, thus more people will be able to
test it, or send it directly to Dominik for a review.
Bye,
zyx
--
http://www.litePDF.cz ***@litePDF.cz
Andreas Brzesowsky
2014-03-05 17:11:21 UTC
Permalink
Okay, so attacht are my changes to add decryption support for AESV2 and
fix some issues with RC4V2 decryption.
With that you can now handle a lot more PDF files with PoDoFo.

Changes:
- Added AESV2 decryption (PdfAESInputStream and
PdfEncryptAESBase::BaseDecrypt)
- Added "EncryptMetadata" is false support, for RC4V2 and AES (In
Acrobat the option has the name: "Encrypt all document contens except
metadata")
- Added support for RC4V2 with enryption features that are only
compatible with Acrobat 6 ("V" > 2 and "R" > 3, but "CFM" = "V2")

Remarks:
- Needed to change the last parameter of PdfEncrypt::Decrypt to a
reference (pdf_long &outLen). Because the output length is not the same
as the input length for AES (initial IV and padding is in the input).
- Needed to extend PdfInputStream::Read with a pTotalLeft parameter for
the AES decryption. Because the decryption needs to know when to
finalize the last chunk and to adjust the resulting length (initial IV
and padding).
- Still open is the support for AESV3 decyption, which should not be so
complicated anymore, because of the now existing AESV2 descryption.

So please check my changes and add them to the repository.

Kind regards

Andreas
Post by zyx
Post by Andreas Brzesowsky
I have added some code to decode AESV2 InputStream, some fixes for RC4
decoding and handling of the EncryptMetadata flag for RC4 and AESV2.
So some more encrypted pdf could be handled by PoDoFo.
I want to contribute my changes.
Hello,
thanks for looking into this (I'm not a PoDoFo developer, but I'd like
to answer the below questions and thank you for your work).
Post by Andreas Brzesowsky
Are there any rules like coding rules or additional test cases I
should consider before contribution?
I do not think there is any written guide on coding style being used in
the PoDoFo code base, I did not find any at least, but the best would be
to pick some core file, like PdfDocument.c/.h and mimic its coding
style.
With respect of adding test cases, it's always a good thing to have more
tests, to spot regressions, thus they are welcome, but not mandatory.
Post by Andreas Brzesowsky
And how to contribute the best way?
You can send the patch to this list, thus more people will be able to
test it, or send it directly to Dominik for a review.
Bye,
zyx
--
dots <http://www.dots.de/en/>

Andreas Brzesowsky

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55

***@dots.de <mailto:***@dots.de>
http://www.dots.de <http://www.dots.de/>

Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
Geschäftsführer (Managing Directors): Olaf Lorenz, Ken Osuga

Follow us on: Twitter <http://www.dots.de/?id=twitter> Youtube
<http://www.dots.de/?id=youtube> Xing <http://www.dots.de/?id=xing>
Dominik Seichter
2014-03-06 08:11:29 UTC
Permalink
Hi Andreas, Hi zyx,

Andreas, thanks for your fixes and updates. @zyx: Could you please review
them and maybe commit them to the repository? I don't have any time right
now to follow patches.

Best regards,
Dominik


On Wed, Mar 5, 2014 at 6:11 PM, Andreas Brzesowsky <
Post by Andreas Brzesowsky
Okay, so attacht are my changes to add decryption support for AESV2 and
fix some issues with RC4V2 decryption.
With that you can now handle a lot more PDF files with PoDoFo.
- Added AESV2 decryption (PdfAESInputStream and
PdfEncryptAESBase::BaseDecrypt)
- Added "EncryptMetadata" is false support, for RC4V2 and AES (In Acrobat
the option has the name: "Encrypt all document contens except metadata")
- Added support for RC4V2 with enryption features that are only compatible
with Acrobat 6 ("V" > 2 and "R" > 3, but "CFM" = "V2")
- Needed to change the last parameter of PdfEncrypt::Decrypt to a
reference (pdf_long &outLen). Because the output length is not the same as
the input length for AES (initial IV and padding is in the input).
- Needed to extend PdfInputStream::Read with a pTotalLeft parameter for
the AES decryption. Because the decryption needs to know when to finalize
the last chunk and to adjust the resulting length (initial IV and padding).
- Still open is the support for AESV3 decyption, which should not be so
complicated anymore, because of the now existing AESV2 descryption.
So please check my changes and add them to the repository.
Kind regards
Andreas
I have added some code to decode AESV2 InputStream, some fixes for RC4
decoding and handling of the EncryptMetadata flag for RC4 and AESV2.
So some more encrypted pdf could be handled by PoDoFo.
I want to contribute my changes.
Hello,
thanks for looking into this (I'm not a PoDoFo developer, but I'd like
to answer the below questions and thank you for your work).
Are there any rules like coding rules or additional test cases I
should consider before contribution?
I do not think there is any written guide on coding style being used in
the PoDoFo code base, I did not find any at least, but the best would be
to pick some core file, like PdfDocument.c/.h and mimic its coding
style.
With respect of adding test cases, it's always a good thing to have more
tests, to spot regressions, thus they are welcome, but not mandatory.
And how to contribute the best way?
You can send the patch to this list, thus more people will be able to
test it, or send it directly to Dominik for a review.
Bye,
zyx
--
[image: dots] <http://www.dots.de/en/>
Andreas Brzesowsky
dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55
http://www.dots.de
Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
Geschäftsführer (Managing Directors): Olaf Lorenz, Ken Osuga
Youtube] <http://www.dots.de/?id=youtube> [image: Xing]<http://www.dots.de/?id=xing>
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to
Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and
the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Podofo-users mailing list
https://lists.sourceforge.net/lists/listinfo/podofo-users
zyx
2014-03-06 14:54:55 UTC
Permalink
review them and maybe commit them to the repository? I don't have any
time right now to follow patches.
Hi,
sure thing, I'll be glad to help.

I applied the patch to current trunk (r1582), which worked like a charm.
Unfortunately, invoking the build fails with below errors. Please see
also warnings from gcc.

Andreas, is it possible any chunks are missing in the patch? I also
tried "make clean" after applying your patch and before building, but it
did not help.

By the way, I have some encrypted PDF documents with forms, where PoDoFo
doesn't seem to decrypt form field values properly, using both RC and
AES encryption (two documents). I'm eager to see whether your patch will
address this as well.
Thanks and bye,
zyx

---------------------------------------------------------------------------------

[ 7%] Building CXX object src/CMakeFiles/podofo_static.dir/base/PdfEncrypt.cpp.o
podofo-trunk/src/base/PdfEncrypt.cpp: In constructor ‘PoDoFo::PdfAESStream::PdfAESStream(unsigned char*, size_t)’:
podofo-trunk/src/base/PdfEncrypt.cpp:405:7: warning: ‘PoDoFo::PdfAESStream::bOnlyFinalLeft’ will be initialized after [-Wreorder]
bool bOnlyFinalLeft;
^
podofo-trunk/src/base/PdfEncrypt.cpp:403:15: warning: ‘const size_t PoDoFo::PdfAESStream::keyLen’ [-Wreorder]
const size_t keyLen;
^
podofo-trunk/src/base/PdfEncrypt.cpp:336:5: warning: when initialized here [-Wreorder]
PdfAESStream( unsigned char* key, const size_t keylen )
^
podofo-trunk/src/base/PdfEncrypt.cpp: In member function ‘PoDoFo::pdf_long PoDoFo::PdfAESStream::Decrypt(unsigned char*, PoDoFo::pdf_long, PoDoFo::pdf_long*)’:
podofo-trunk/src/base/PdfEncrypt.cpp:372:88: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptUpdate(EVP_CIPHER_CTX*, unsigned char*, int*, const unsigned char*, int)’
status = EVP_DecryptUpdate( aes, pBuffer, &lOutLen, pBuffer + keyLen, lLen - keyLen );
^
podofo-trunk/src/base/PdfEncrypt.cpp:378:73: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptUpdate(EVP_CIPHER_CTX*, unsigned char*, int*, const unsigned char*, int)’
status = EVP_DecryptUpdate( aes, tempBuffer, &lOutLen, pBuffer, lLen );
^
podofo-trunk/src/base/PdfEncrypt.cpp:391:72: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptFinal_ex(EVP_CIPHER_CTX*, unsigned char*, int*)’
status = EVP_DecryptFinal_ex( aes, pBuffer + lOutLen, &lStepOutLen );
^
podofo-trunk/src/base/PdfEncrypt.cpp: In member function ‘virtual void PoDoFo::PdfEncryptMD5Base::CreateObjKey(unsigned char*, int*) const’:
podofo-trunk/src/base/PdfEncrypt.cpp:911:68: error: ‘ePdfEncryptAlgorithm_AESV3’ was not declared in this scope
if (m_eAlgorithm == ePdfEncryptAlgorithm_AESV2 || m_eAlgorithm == ePdfEncryptAlgorithm_AESV3)
^
podofo-trunk/src/base/PdfEncrypt.cpp: In member function ‘void PoDoFo::PdfEncryptAESBase::BaseDecrypt(const unsigned char*, int, const unsigned char*, const unsigned char*, PoDoFo::pdf_long, unsigned char*, PoDoFo::pdf_long&)’:
podofo-trunk/src/base/PdfEncrypt.cpp:1301:70: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptUpdate(EVP_CIPHER_CTX*, unsigned char*, int*, const unsigned char*, int)’
status = EVP_DecryptUpdate(aes, textout, &outLen, textin, textlen);
^
make[2]: *** [src/CMakeFiles/podofo_static.dir/base/PdfEncrypt.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/podofo_static.dir/all] Error 2
--
http://www.litePDF.cz ***@litePDF.cz
Andreas Brzesowsky
2014-03-07 13:05:01 UTC
Permalink
Hi,

thanks zyx for testing and reporting the errors.
I have used Visual Studio for compiling and don't get these errors and
warnings there.
So I have now tried compiling with latest MinGW and don't get these
errors either, but the warning.
Fixed the warning.
- error: ‘ePdfEncryptAlgorithm_AESV3’ was not declared in this scope
Ok, I have forgot one "#ifdef PODOFO_HAVE_LIBIDN" around it.
- error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’
for argument ‘3’
Ok, int could have a different size than pdf_long depending on the
architecture.

I think a have fixed them and created a new patch.
Please send me the errors if you still have some.

Bye

Andreas
Post by zyx
review them and maybe commit them to the repository? I don't have any
time right now to follow patches.
Hi,
sure thing, I'll be glad to help.
I applied the patch to current trunk (r1582), which worked like a charm.
Unfortunately, invoking the build fails with below errors. Please see
also warnings from gcc.
Andreas, is it possible any chunks are missing in the patch? I also
tried "make clean" after applying your patch and before building, but it
did not help.
By the way, I have some encrypted PDF documents with forms, where PoDoFo
doesn't seem to decrypt form field values properly, using both RC and
AES encryption (two documents). I'm eager to see whether your patch will
address this as well.
Thanks and bye,
zyx
---------------------------------------------------------------------------------
[ 7%] Building CXX object src/CMakeFiles/podofo_static.dir/base/PdfEncrypt.cpp.o
podofo-trunk/src/base/PdfEncrypt.cpp:405:7: warning: ‘PoDoFo::PdfAESStream::bOnlyFinalLeft’ will be initialized after [-Wreorder]
bool bOnlyFinalLeft;
^
podofo-trunk/src/base/PdfEncrypt.cpp:403:15: warning: ‘const size_t PoDoFo::PdfAESStream::keyLen’ [-Wreorder]
const size_t keyLen;
^
podofo-trunk/src/base/PdfEncrypt.cpp:336:5: warning: when initialized here [-Wreorder]
PdfAESStream( unsigned char* key, const size_t keylen )
^
podofo-trunk/src/base/PdfEncrypt.cpp:372:88: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptUpdate(EVP_CIPHER_CTX*, unsigned char*, int*, const unsigned char*, int)’
status = EVP_DecryptUpdate( aes, pBuffer, &lOutLen, pBuffer + keyLen, lLen - keyLen );
^
podofo-trunk/src/base/PdfEncrypt.cpp:378:73: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptUpdate(EVP_CIPHER_CTX*, unsigned char*, int*, const unsigned char*, int)’
status = EVP_DecryptUpdate( aes, tempBuffer, &lOutLen, pBuffer, lLen );
^
podofo-trunk/src/base/PdfEncrypt.cpp:391:72: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptFinal_ex(EVP_CIPHER_CTX*, unsigned char*, int*)’
status = EVP_DecryptFinal_ex( aes, pBuffer + lOutLen, &lStepOutLen );
^
podofo-trunk/src/base/PdfEncrypt.cpp:911:68: error: ‘ePdfEncryptAlgorithm_AESV3’ was not declared in this scope
if (m_eAlgorithm == ePdfEncryptAlgorithm_AESV2 || m_eAlgorithm == ePdfEncryptAlgorithm_AESV3)
^
podofo-trunk/src/base/PdfEncrypt.cpp:1301:70: error: cannot convert ‘PoDoFo::pdf_long* {aka long int*}’ to ‘int*’ for argument ‘3’ to ‘int EVP_DecryptUpdate(EVP_CIPHER_CTX*, unsigned char*, int*, const unsigned char*, int)’
status = EVP_DecryptUpdate(aes, textout, &outLen, textin, textlen);
^
make[2]: *** [src/CMakeFiles/podofo_static.dir/base/PdfEncrypt.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/podofo_static.dir/all] Error 2
--
dots <http://www.dots.de/en/>

Andreas Brzesowsky

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55

***@dots.de <mailto:***@dots.de>
http://www.dots.de <http://www.dots.de/>

Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
GeschÀftsfÌhrer (Managing Directors): Olaf Lorenz, Ken Osuga

Follow us on: Twitter <http://www.dots.de/?id=twitter> Youtube
<http://www.dots.de/?id=youtube> Xing <http://www.dots.de/?id=xing>
zyx
2014-03-07 14:01:28 UTC
Permalink
Post by Andreas Brzesowsky
I think a have fixed them and created a new patch.
Please send me the errors if you still have some.
Hi,
thanks for the update, it compiles cleanly now. I'll test the
functionality during the weekend, the most at the beginning of the next
week, and let you know.
Bye,
zyx
--
http://www.litePDF.cz ***@litePDF.cz
zyx
2014-03-09 13:18:31 UTC
Permalink
I'll test the functionality during the weekend, the most at the beginning
of the next week, and let you know.
Hello,
I created a little test program for the encryption (see the attached
test.cpp), which is testing all encryption algorithms. Your patch works
as you said, it fixes AESv2 decryption and keeps the AESv3 unchanged
(still broken). There is one change in behaviour, it exists with an
exception for AESv3:

PoDoFo encounter an error. Error: 8 ePdfError_InternalLogic
Error Description: An internal error occurred.
Callstack:
#0 Error Source: .../src/base/PdfEncrypt.cpp:1314
Information: Error AES-decryption data final

instead of failing silently, which is better in my opinion.

This doesn't seem to fix decrypt of an AcroForm elements, but that might
not be related to your changes at all (it didn't work even before).

In any case, I committed your patch to trunk as revision 1583:
http://sourceforge.net/p/podofo/code/1583

Thanks and bye,
zyx
--
http://www.litePDF.cz ***@litePDF.cz
Andreas Brzesowsky
2014-03-10 16:59:03 UTC
Permalink
Hi,

thank you very much.
I have now got some AESV2 encrypted PDF, that are created with Acrobat X.
These currently crash in PoDoFo because they have multiple XRef streams
and XRef streams are never encrypted.
But in PdfParser::ReadObjectsInternal m_pEncrypt is set for these XRef
objects.
I have added a patch to skip all XRef objects in
PdfParser::ReadObjectsInternal.
With that AESV2 encryption from Acrobat X should work.

Bye

Andreas
Post by zyx
Hello,
I created a little test program for the encryption (see the attached
test.cpp), which is testing all encryption algorithms. Your patch works
as you said, it fixes AESv2 decryption and keeps the AESv3 unchanged
(still broken). There is one change in behaviour, it exists with an
PoDoFo encounter an error. Error: 8 ePdfError_InternalLogic
Error Description: An internal error occurred.
#0 Error Source: .../src/base/PdfEncrypt.cpp:1314
Information: Error AES-decryption data final
instead of failing silently, which is better in my opinion.
This doesn't seem to fix decrypt of an AcroForm elements, but that might
not be related to your changes at all (it didn't work even before).
http://sourceforge.net/p/podofo/code/1583
Thanks and bye,
zyx
--
dots <http://www.dots.de/en/>

Andreas Brzesowsky

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55

***@dots.de <mailto:***@dots.de>
http://www.dots.de <http://www.dots.de/>

Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
Geschäftsführer (Managing Directors): Olaf Lorenz, Ken Osuga

Follow us on: Twitter <http://www.dots.de/?id=twitter> Youtube
<http://www.dots.de/?id=youtube> Xing <http://www.dots.de/?id=xing>
zyx
2014-03-11 07:50:04 UTC
Permalink
Post by Andreas Brzesowsky
I have now got some AESV2 encrypted PDF, that are created with Acrobat X.
These currently crash in PoDoFo because they have multiple XRef
streams and XRef streams are never encrypted.
But in PdfParser::ReadObjectsInternal m_pEncrypt is set for these XRef
objects.
I have added a patch to skip all XRef objects in
PdfParser::ReadObjectsInternal.
With that AESV2 encryption from Acrobat X should work.
Hi,
thanks, I committed the patch to trunk as revision 1584:
http://sourceforge.net/p/podofo/code/1584

By the way, would you mind to look on AESv3 too? As you mentioned
earlier, with AESv2 being done the AESv3 should not be a big problem,
and you have the code fresh in your mind, thus it might be even easier
for you? Maybe :)
Bye,
zyx
--
http://www.litePDF.cz ***@litePDF.cz
Andreas Brzesowsky
2014-03-17 14:33:34 UTC
Permalink
Post by zyx
By the way, would you mind to look on AESv3 too?
Maybe yes, if I find some time for it.
But before I have an other patch:
My last patch should handle multiple XRef object for encrypted PDFs. But
it breaks merged unencryted PDFs with multiple XRef objects.
So instead of not adding XRef object to m_vecObjects, this patch sets
the encryption to NULL for these objects.

Bye

Andreas
--
dots <http://www.dots.de/en/>

Andreas Brzesowsky

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55

***@dots.de <mailto:***@dots.de>
http://www.dots.de <http://www.dots.de/>

Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
Geschäftsführer (Managing Directors): Olaf Lorenz, Ken Osuga

Follow us on: Twitter <http://www.dots.de/?id=twitter> Youtube
<http://www.dots.de/?id=youtube> Xing <http://www.dots.de/?id=xing>
zyx
2014-03-18 08:56:45 UTC
Permalink
Post by Andreas Brzesowsky
My last patch should handle multiple XRef object for encrypted PDFs.
But it breaks merged unencryted PDFs with multiple XRef objects.
So instead of not adding XRef object to m_vecObjects, this patch sets
the encryption to NULL for these objects.
Hi,
thanks, I committed it as r1585
http://sourceforge.net/p/podofo/code/1585
Bye,
zyx
--
http://www.litePDF.cz ***@litePDF.cz
Andreas Brzesowsky
2014-03-31 12:05:02 UTC
Permalink
Post by zyx
By the way, would you mind to look on AESv3 too? As you mentioned
earlier, with AESv2 being done the AESv3 should not be a big problem,
and you have the code fresh in your mind, thus it might be even easier
for you? Maybe :)
Hi,

okay now I have the patch for AESv3 decryption finished:
- PdfAESStream::Decrypt - Corrected block size to 16, as AESv3 block
size and IV size is still 16, not key length
- PdfEncryptMD5Base::CreateObjKey - Removed ePdfEncryptAlgorithm_AESV3
condition, because AESv3 does never use object key, it always uses the
file key
- PdfEncryptAESV3::Authenticate - Getting the file key (m_encryptionKey)
was missing
- PdfEncryptAESV3::CreateEncryptionInputStream - Create
PdfAESInputStream with m_encryptionKey, because AESv3 does never use
object key, it always uses the file key

Bye

Andreas
--
dots <http://www.dots.de/en/>

Andreas Brzesowsky

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55

***@dots.de <mailto:***@dots.de>
http://www.dots.de <http://www.dots.de/>

Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
Geschäftsführer (Managing Directors): Olaf Lorenz, Ken Osuga

Follow us on: Twitter <http://www.dots.de/?id=twitter> Youtube
<http://www.dots.de/?id=youtube> Xing <http://www.dots.de/?id=xing>
zyx
2014-04-01 19:07:29 UTC
Permalink
Hi,
thanks a lot for the follow-up. I applied your patch to trunk and run
the test program I sent earlier [1], which creates some encrypted PDF
files in PoDoFo and then tries to read them, and the AESv3 still fails,
this time with a different error:


Testing aesv3.pdf:
Failed with error:

PoDoFo encounter an error. Error: 8 ePdfError_InternalLogic
Error Description: An internal error occurred.
Callstack:
#0 Error Source: .../src/base/PdfParser.cpp:1028
Information: Error while loading object 2 0 Offset = 59 Index = 2

#1 Error Source: .../src/base/PdfEncrypt.cpp:1286
Information: Error AES-decryption data length not a multiple of the key length

I hope it helps with a diagnose.
Bye,
zyx

[1] http://sourceforge.net/p/podofo/mailman/message/32079121/
--
http://www.litePDF.cz ***@litePDF.cz
Andreas Brzesowsky
2014-04-03 09:43:02 UTC
Permalink
Hi,

that's weird.
Because if the patch is applied correctly the error message "Error
AES-decryption data length not a multiple of the key length" does not
exists anymore
In the patch are these lines:
- if( lLen % keyLen != 0 )
- PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error
AES-decryption data length not a multiple of the key length" );
+ if( lLen % 16 != 0 )
+ PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error
AES-decryption data length not a multiple of 16" );

So can you please make sure that the patch is correctly applied.
Thanks.

Bye

Andreas
Post by zyx
Hi,
thanks a lot for the follow-up. I applied your patch to trunk and run
the test program I sent earlier [1], which creates some encrypted PDF
files in PoDoFo and then tries to read them, and the AESv3 still fails,
PoDoFo encounter an error. Error: 8 ePdfError_InternalLogic
Error Description: An internal error occurred.
#0 Error Source: .../src/base/PdfParser.cpp:1028
Information: Error while loading object 2 0 Offset = 59 Index = 2
#1 Error Source: .../src/base/PdfEncrypt.cpp:1286
Information: Error AES-decryption data length not a multiple of the key length
I hope it helps with a diagnose.
Bye,
zyx
[1] http://sourceforge.net/p/podofo/mailman/message/32079121/
--
dots <http://www.dots.de/en/>

Andreas Brzesowsky

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany
Phone: +49 (0)30 695 799-34, Fax: +49 (0)30 695 799-55

***@dots.de <mailto:***@dots.de>
http://www.dots.de <http://www.dots.de/>

Amtsgericht (District Court): Berlin Charlottenburg HRB 65201
Geschäftsführer (Managing Directors): Olaf Lorenz, Ken Osuga

Follow us on: Twitter <http://www.dots.de/?id=twitter> Youtube
<http://www.dots.de/?id=youtube> Xing <http://www.dots.de/?id=xing>
zyx
2014-04-06 17:24:24 UTC
Permalink
Post by Andreas Brzesowsky
Because if the patch is applied correctly the error message "Error
AES-decryption data length not a multiple of the key length" does not
exists anymore
- if( lLen % keyLen != 0 )
- PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error
AES-decryption data length not a multiple of the key length" );
+ if( lLen % 16 != 0 )
+ PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error
AES-decryption data length not a multiple of 16" );
So can you please make sure that the patch is correctly applied.
Hi,
the message you changed was at PdfAESStream::Decrypt(), but that message
I get is from PdfEncryptAESBase::BaseDecrypt(). I changed it the same as
you did above and it works as expected, thus I committed it to trunk as
r1595: http://sourceforge.net/p/podofo/code/1595

Thanks a lot for the help on this.
Bye,
zyx
--
http://www.litePDF.cz ***@litePDF.cz
Loading...