You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Andreas Lehmkühler (JIRA)" <ji...@apache.org> on 2014/11/11 22:48:34 UTC
[jira] [Comment Edited] (PDFBOX-2456) create
TestSymmetricKeyEncryption.java
[ https://issues.apache.org/jira/browse/PDFBOX-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207142#comment-14207142 ]
Andreas Lehmkühler edited comment on PDFBOX-2456 at 11/11/14 9:47 PM:
----------------------------------------------------------------------
PDFBox can't save a decrypted pdf as encrypted without some input from the user. The difference between the old and the non-sequential parser is quite simple. The old one simply removes all encryption information right after the decryption (see PDDocument#openProtection) and the pdf is saved without being encrypted again. The non-sequential parser on the contrary doesn't remove the encryption information. It's still in place if someone tries to save the document. As those information are incomplete (e.g. the userpassword and/or the ownerpassword is missing) the code crashes. Either one provides the missing information or disables the encryption by calling setAllSecurityToBeRemoved() before savin the pdf.
We should disable the encryption automatically but without removing the encryption information. If someone wants to save the pdf encrypted, the missing information somehow has to be provided by the user when calling save. We should handle that in PDFBOX-1453
was (Author: lehmi):
PDFBox can't save a decrypted pdf as encrypted without some input from the user. The difference between the old and the non-sequential parser is quite simple. The old one simply removes all encryption information right after the decryption (see PDDocument#openProtection) and the pdf is saved without being encrypted again. The non-sequential parser on the contrary doesn't remove the encryption information. It's still in place if someone tries to save the document. As those information are incomplete (e.g. the userpassword and/or the ownerpassword is missing) the code crashes. Either one provides the missing information or disables the encryption by calling setAllSecurityToBeRemoved() before savin the pdf.
We should disable the encryption automatically but without removing the encryption information. If someone wants to save the pdf encrypted, the missing information somehow has to be provided by the user when calling save.
> create TestSymmetricKeyEncryption.java
> --------------------------------------
>
> Key: PDFBOX-2456
> URL: https://issues.apache.org/jira/browse/PDFBOX-2456
> Project: PDFBox
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 1.8.7, 1.8.8, 2.0.0
> Environment: java7 debian7
> Reporter: Ralf Hauser
> Labels: AES256
> Fix For: 1.8.8, 2.0.0
>
> Attachments: AES256.diff, TestSymmetricKeyEncryption.java, enc128bit_20141025_115145.pdf, enc256bit_20141025_105451.pdf, preEnc_20141025_105451.pdf, preEnc_20141025_115145.pdf
>
>
> similarly to org.apache.pdfbox.encryption.TestPublicKeyEncryption, also test password based encryption
> 1) 128bit
> 2) 256bit AES PDFBOX-1594
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)