EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Using own crypto class for signing PDF via PDFBlackBox

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
Posted: 01/14/2014 09:45:44
by Petr Stransky (Standard support level)
Joined: 09/24/2012
Posts: 19

Thanks for your advice and workaround - it is working now. I also had to set Signature.ExtraSpace to 65536 and the hash needed to be DER encoded before the actual signing but that is no problem for me.
So now the only disadvantage is the file size. I do agree that the funcionality is more important so I just want to ask if there is anything on my side that can be done to decrease it. One of the typical sizes of documents my users are going to sign is about 100-150KB. When I sign 121KB large PDF file with "simple" PDF Handler the signed PDF is about 135KB. When I do it with the advanced one, it gets to cca 286KB. But I think it will not be a big problem.
Just out of curiosity, is there any short explanation?
Posted: 01/14/2014 10:37:15
by Ken Ivanov (Team)

Good, thank you for letting us know. Now we can move on to the file size issue.

The problem with PDF signing is that the signing component must allocate a 'signature window' in the PDF document *before* initiating the signing process. Unfortunately, it is not always possible to predict the accurate size of the future signature on this stage (as they can't predict the size of an external timestamp blob, for instance), so the components try to allocate a window big enough to accommodate the largest possible signature. The advanced handler has to reserve even a larger window, to provide for auxiliary validation elements (CRLs, OCSP responses) it obtains from online sources.

Now, if you plan to always use the same or similar signing configurations (same certificate, same TSA, same handler setup), you can tune up the component to generate the minimal signature window overhead. This can be done by adjusting the SignatureSizeEstimationStrategy property to match your environment best. In particular, you can set it to psesPredefinedSize and specify the fixed window size (e.g. 16384) via the PredefinedSignatureSize property of the handler. The exact window size in this case can be established in experimental way.

The ExtraSpace property you discovered also helps to fine-tune the signature window. It specifies how many bytes the handler should *add* to the size estimated internally by the components, and might be useful in situations where one of validation components (TSA reply, CRL or OCSP response) exceeds mean statistical sizes used for estimation internally by PDFBlackbox.



Topic viewed 2404 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!