[
https://issues.apache.org/jira/browse/PDFBOX-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: [email protected]
For additional commands, e-mail: [email protected]
