Question:
We have noticed that when we sign a PDF with PDFNet, the signature always has 64 more bytes than the actual signature size and all of these bytes are filled with zero. We would like to know if there’s any reason why these bytes are there and if we should take them into account in some situation.
Answer:
The extra bytes you are seeing are called “padding bytes”. They are necessary because when signing a document with PDFNet, it is always done in two passes - the first pass is to save the file so that the bytes to sign are finalized and a space (somewhere in the PDF) is reserved for the signature, then the second pass will then calculate the signature for the specified byte ranges (always skipping the reserved space), then after the signature is calculated, it will be written on the reserved space. As there is no way to know the exact size of the final signature during the first pass, PDFNet will reserve more than enough space for the final signature to fit in (in PDFNet’s case, it is more or less 64 bytes). On the first pass, PDFNet acquires an estimated size of the signature by calling the CreateSignature method the first time. The main reason for the extra bytes is because there is no guarantee that CreateSignature will always return the same amount of bytes each time this method is invoked. Some signature handlers might return more bytes when the time stamp (signature creation date) changes. This is why PDFNet inserts these padding bytes - so that the second time CreateSignature is called, there will always be more than enough space for the signature to fit it.
Our recommendation is to not assume that there will always be an extra 64 bytes of padding. If you have a guarantee that your signing tool will always provide fixed-length signatures (even if there are changes in the time stamp) , then you can most likely strip these extra padding bytes if you wish, but as mentioned, some signature handlers may not return the same length each time a signature is created.