[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119658#comment-17119658 ] Andreas Lehmkühler commented on PDFBOX-4784: [~tilman] thanks for doublechecking , [~bsanchezb] thanks for the fast fix > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119657#comment-17119657 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878278 from le...@apache.org in branch 'pdfbox/branches/issue45' [ https://svn.apache.org/r1878278 ] PDFBOX-4784: unit test fix as proposed by Aleksandr Beliakov > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119655#comment-17119655 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878277 from le...@apache.org in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1878277 ] PDFBOX-4784: unit test fix as proposed by Aleksandr Beliakov > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119652#comment-17119652 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878276 from le...@apache.org in branch 'pdfbox/trunk' [ https://svn.apache.org/r1878276 ] PDFBOX-4784, closes #85: unit test fix as proposed by Aleksandr Beliakov > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119647#comment-17119647 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878275 from le...@apache.org in branch 'pdfbox/trunk' [ https://svn.apache.org/r1878275 ] PDFBOX-4784: javadoc fix > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119646#comment-17119646 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878274 from le...@apache.org in branch 'pdfbox/branches/issue45' [ https://svn.apache.org/r1878274 ] PDFBOX-4784: javadoc fix > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119645#comment-17119645 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878273 from le...@apache.org in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1878273 ] PDFBOX-4784: javadoc fix > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119384#comment-17119384 ] Aleksandr Beliakov commented on PDFBOX-4784: Hello [~tilman] , Good catch, indeed there was a problem on a step of CMSSignedData creation, the signing time for which has been instantiated on every call. Therefore, if you was not lucky to execute the test during one second, the test failed. I added a fix for that: [https://github.com/apache/pdfbox/pull/85/commits/0a88aded0b33c06c41d8fb52d2782f3b64548f47] in order to skip this step, because the CMSSignedData is not really needed for the test (the main PDF document content integrity is important). Also I've added a fix for JavaDoc. I hope this helps. Regards, Aleksandr. > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119251#comment-17119251 ] Tilman Hausherr commented on PDFBOX-4784: - Also javadoc problem in setCustomSecureRandom() (wrong "@param") > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119021#comment-17119021 ] Tilman Hausherr commented on PDFBOX-4784: - The build sometimes fails in a test. I suspect this happens when several builds run on the same machine. java.lang.AssertionError at org.apache.pdfbox.examples.pdmodel.TestCreateSignature.testPDFBox4784(TestCreateSignature.java:580) > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115733#comment-17115733 ] Aleksandr Beliakov commented on PDFBOX-4784: [~lehmi] , thank you for the collaboration! Looking forward for the next release. > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114671#comment-17114671 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878053 from le...@apache.org in branch 'pdfbox/branches/issue45' [ https://svn.apache.org/r1878053 ] PDFBOX-4784: add optional usage of an external SecureRandom for AES encryption as proposed by Aleksandr Beliakov > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114663#comment-17114663 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878051 from le...@apache.org in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1878051 ] PDFBOX-4784: add optional usage of an external SecureRandom for AES encryption as proposed by Aleksandr Beliakov > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114658#comment-17114658 ] ASF subversion and git services commented on PDFBOX-4784: - Commit 1878049 from le...@apache.org in branch 'pdfbox/trunk' [ https://svn.apache.org/r1878049 ] PDFBOX-4784, closes #83: add optional usage of an external SecureRandom for AES encryption as proposed by Aleksandr Beliakov > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111803#comment-17111803 ] Andreas Lehmkühler commented on PDFBOX-4784: [~mkl], [~bsanchezb] thanks for the explanation. I hoped that those single steps might be somehow connected so that we might find a way to "cache" the needed information during processing, but obviously those steps are separately processed. [~bsanchezb] Your proposal looks similar to the solution I've had in mind. I'm going to merge it soon. > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement > Components: Crypto >Affects Versions: 2.0.19 >Reporter: Pierrick Vandenbroucke >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 2.0.20, 3.0.0 PDFBox > > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108192#comment-17108192 ] Aleksandr Beliakov commented on PDFBOX-4784: [~lehmi] , please take a look on a pull request I have created : [https://github.com/apache/pdfbox/pull/83] I added a unit test to show our use case. As Michael have explained, in DSS we sign a signature in three steps: 1) Compute data to be signed; 2) Compute Signature Value; 3) Sign the document. The PDF creation is required on steps 1 and 3, therefore in order to have a cryptographically valid signature, the both steps must produce a PDF with the same binaries. Based on this, we need to have a possibility to use AES encryption in a deterministic way, i.e. by providing a custom SecureRandom. > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement >Reporter: Pierrick Vandenbroucke >Priority: Major > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107545#comment-17107545 ] Michael Klink commented on PDFBOX-4784: --- [~lehmi] eSignature DSS does not sign like it's done in the CreateSignature example. eSignature DSS during signing adds the extra objects (signature field, field value, ...) for the signature *twice* to the same base PDF; the first time to calculate the hash to sign, the second time to inject the signature container generated into that prepared PDF. DSS does so twice because they don't want to keep additional intermediary data like the PDF prepared with those extra objects. Usually this presents no problem, both versions end up identical, but in case of AES encryption there are random numbers used to initialize the encryption of each string and stream, so the first and second version of the prepared PDF differ in their serialized, encrypted form. Thus, the hash value determined for the first version differs from the hash of the second version but gets a signature container based on the first hash. Thus, the generated signature is invalid. To get around this, they would like to have an option to provide identically initialized SecureRandoms for both versions to make sure the same random numbers are used in both runs. As PDFs often are encrypted using a default password, simply to restrict permissions, this is not a too seldom case. > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement >Reporter: Pierrick Vandenbroucke >Priority: Major > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098425#comment-17098425 ] Andreas Lehmkühler commented on PDFBOX-4784: [~pvandenbroucke] Can you elaborate on the main implementation details please? The signing of the AES protected PDF from the [commit|https://ec.europa.eu/cefdigital/code/projects/ESIG/repos/dss/commits/12160a133ac2f912595122dbe1ed029181eff902] mentioned in DSS-1962 works using the CreateSignature example from the 2.0 branch of PDFBox. The only thing I've to change is the pass the password to the load-method when opening the pdf. I'd really like to reproduce the issue to understand it and maybe to find an alternative solution without necessarily providing a custom SecureRandom instance in such cases. > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement >Reporter: Pierrick Vandenbroucke >Priority: Major > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049920#comment-17049920 ] Pierrick Vandenbroucke commented on PDFBOX-4784: Thanks for your reply. The goal is the second one. We would like to provide a custom instance of SecureRandom to PDFBox. The instance will be initialized on our side and that will allow us to generate more than once the same binaries. Currently, between the first and the second call on an encrypted document and with the same signature configurations (signing time,...), we obtain different binaries and that breaks created signatures. > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement >Reporter: Pierrick Vandenbroucke >Priority: Major > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4784) Possibility to provide the SecureRandom to SecurityHandler
[ https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049543#comment-17049543 ] Andreas Lehmkühler commented on PDFBOX-4784: As I'm not an encryption expert I'm not sure if I got the point. What exactly is the goal? * use the very same instance of SecureRandom for a SecurityHandler * use a custom instance of SecureRandom which is passed to the SecurityHandler during initialization The first could be achieved but adding a getter always returning the same SecureRandom instance for an instance of SecurityHandler. The second one could be achieved by extending the first solution with a setter which overrides the default instance of SecureRandom. Or do you have a totally different solution in your mind? > Possibility to provide the SecureRandom to SecurityHandler > -- > > Key: PDFBOX-4784 > URL: https://issues.apache.org/jira/browse/PDFBOX-4784 > Project: PDFBox > Issue Type: Improvement >Reporter: Pierrick Vandenbroucke >Priority: Major > > In DSS, we build electronic signatures with two stateless operations > (computation of the data to be signed and incorporation of the signature > value). Currently, the signature creation fails with encrypted documents > (AES) due to the Initialization Vector generations which produce different > values at each call. > We would need a way to "stabilize" this part. We discussed about that on our > [issue tracker|https://ec.europa.eu/cefdigital/tracker/browse/DSS-1962] and > the idea would be to provide a custom instance of the SecureRandom to the > [SecurityHandler|https://github.com/apache/pdfbox/blob/2.0.19/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java#L381]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
