Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
One can sign a file using PGP, using clearsign option by performing following command in CMD
gpg --clearsign filename
What kind of algorithm does GnuPG uses for clearsign option such that even after performing signature, the output signature is in readable fromat?
I read a manual that said how clearsign option works but I am not able to understand it. It is available here.
According to manual, armor is applied to signature which makes signature unreadable. But the question was how clearsign make signature readable.
But, how can one control output of a signature, composed of a hash algorithm and an encryption function, as cleartext?
By using hash and encryption function, how can output be guaranteed into range of ASCII characters that are readable?
The signature is always binary, really. The clearsign only means that the signature is computed not over the compressed message but over the original message, if it is in text format. This means that the signed message is still readable to the recipient (after the ----BEGIN PGP SIGNED MESSAGE---- header) which means that in a mail the recipient can still read the message without going through a PGP program. The recipient still needs such a program to verify the signature.
As the signature is always binary but needs to be sent in a text format sometimes, this means that the signature is encoded as base64, to ensure it's also in text format. If you don't do clearsign, but sign, the whole message is compressed first and then signed and the total is base64 encoded. The message would still be readable to anyone (after base64 decoding and decompression). So the standard ASCII armour encoding is used to guarantee printable ASCII output. But this final encoding is just for convenience, the underlying binary form is the actual signature that is verified.
Related
Preamble: I am not trying to merge different PDFs.
I was wondering. Does the signature of a PDF modify the signed portion of the document or is it appended to some other section of the file?
If the signed portion of the document does not include the signatures, it should be possible to transfer the signature of a document to another file containing the exact same document:
In practice, sending identical PDF to person A and B or signing, I get PDF[A] and PDF[B] back, I can then transfer signature of B to PDF[A], getting PDF[A, B].
Is that theoretically possible? Has someone already tried it?
First of all, I assume you mean a special case of electronic signatures which often are referred to as digital signatures: These signatures allow verification using the hash of the bytes signed by the signature.
Furthermore, I assume you mean the interoperable types of digital PDF signatures as specified in the PDF specifications and related documents with the extra condition that the signed bytes encompass the whole signed revision except only the placeholder for the signature container. (The PDF specification allows to sign less but common validators forbid that.)
Under these assumptions:
No, what you want to do is not possible.
Signing does not merely append a signature container somewhere; instead it first extends the PDF with some extra objects to represent the signature and hold its signature container, and then it creates a signature for that prepared PDF, not for the original one.
The preparations by two different persons A and B most likely are not identical, so the ranges signed by them differ.
Furthermore, real "parallel signing" of the identical content is not possible in interoperable digital PDF signing, only a consecutive, serial signing. Thus, if you have a PDF with multiple signatures, the bytes signed by the second one actually include the first signature:
Thus, you cannot simply transfer the signature of B as a second signature to the PDF already signed by A because a second signature has to sign something completely different than a first one.
(That being said, there is a larger signing software house whose software used to create signed PDFs with multiple SignerInfos in a single signature container; this is forbidden in the PDF specification for interoperable signatures but a situation validators seldom check for. During validation Adobe Acrobat here only validated the first SignerInfo; some other software only validated the last; in the end this only caused a lot of confusion.)
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
How can I find out what's wrong with my PDF file. I'm making a web application for digitally signing pdf documents. To do that, I'm doing a lot of stuff in the code like adding signature fields before inserting the actual signature. The code is too long to post here. The code is working fine for most of the pdf documents. However, for some pdf's it breaks the pdf, so it can't be opened with the Acrobat Reader.
Is there any way I can find out what's wrong with my pdf. The problem is that Acrobat Reader is giving me very general errors without further explanation.
The error I get is: There was an error opening this document. There was a problem reading this document (14).
Here is the signed pdf file that is making problems if someone wants to take a look:
https://easyupload.io/1a0i8x
There are many errors in the cross references of the PDF.
Actually it looks like the source PDF had a cross reference stream (or at least hybrid cross references) and your program stored the cross reference data from the stream as a cross reference table, ignoring the fact that the entries referring to objects in object streams make no sense in a cross reference table.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I received a PDF file that uses unusual fonts.
The fonts look fine to the human eye,
but if I try to cut-past them, I get a string of '???'
Is it possible to replace the PDF document's defined fonts with normal fonts (e.g., on Foxit Phantom PDF editor)?
This may be possible, e.g. with PitStop Pro from Enfocus. However, as others indicated in the comments, it is possible that the fonts in the pdf and the pdf itself have had all information to make this possible removed.
Some more detail about this maybe:
The encoding in the PDF could tell software which character is to be shown, and then that character would be selected from the font for display, but it is also possible to create a pdf so it only says 'show glyph number 3 in of the embedded font'. That is what the 'Identity-H' encoding you see in the summary does.
Note that the word glyph and not 'character' is specifically used when talking about the individual 'drawings' that make up a font to indicate that these things are only 'random' drawings until some information is added in the font to indicate which letter (or other character, like a number) they represent.
E.g. for the character 'lower-case-a', the font you currently look at has this glyph:
a
but other fonts will have something that may look completely different. Only because we have learned to read these different images as the letter lower-case-a do we think they are/represent 'the same letter'.
If this information is not present in the PDF, as is your case, it is still possible that this information can be gotten from the font included in the pdf: a font on your computer needs some way to allow a program to select the right glyph if it wants to display 'lower-case-a'. However, if the pdf is set up to simply say 'show glyph number 3 in of the embedded font', this information isn't necessary anymore, and can be removed from the font before the font is put inside the pdf. This is done either to make the pdf smaller, or to prevent people from copying the text, e.g. of copyrighted works.
In this case, only OCR can help. I think Adobe Acrobat (the full version, not Adobe Reader) has added exactly that in one of the latest versions; however this means it is trying to guess the letter from the 'image' shown, so this may make mistakes.
With iText 5.5.4, if I choose to embed CRLs during the signature process, it breaks the PDF/A-2B conformance because of a String too long error :
Adobe Preflight http://img4.hostingpics.net/pics/234201so5.jpg
As you can see in the preflight from Adobe Acrobat Pro 11.0.09, the CRL is 67107 characters long whereas this specific PDF standard require that the maximum length for strings must not exceed 32767 bytes.
Is it a bug in Itext or is there a way to keep PDF/A-2B conformance in that case?
Is it a bug in Itext?
As you can see in the preflight from Adobe Acrobat Pro 11.0.09, the CRL is 67107 characters long whereas this specific PDF standard require that the maximum length for strings must not exceed 32767 bytes
Considering that the problem string is referenced as 1 0 obj/Contents seems to indicate that it actually is the string reserved for the CMS signature container, not the plain CRL.
Looking at the PDF/A specification (I only have part 3 at hands but the parts 2 and 3 should coincide here) there are two sections which seem to contradict each other:
A conforming file shall not contain any string longer than 32767 bytes.
(section 6.1.13 Implementation limits)
and
timestamping and revocation information should be included [in the PDF Signature (a DER-encoded PKCS#7 binary data object)] in order to improve the long-term non-repudiation properties of the signature.
(Annex B Requirements for digital signatures in PDF/A)
In your case following the latter recommendation breaks the former requirement because the PKCS#7 / CMS object is embedded as a string in the PDF.
But as we have a requirement against a recommendation, the recommendation need only be followed as long as the requirements are not violated. The specification even explicitly says so:
When generating signature appearances and any other PDF objects as part of the signing process, a
conforming reader shall ensure that it does not invalidate compliance with this part of ISO 19005
(section 6.4.3 Digital signatures)
Thus indeed, iText signing should fail during the signing process... if you have used the PDF/A aware API, that is. Unfortunately you have not provided your source code, so it is not clear whether or not you have used the PdfAStamper or merely the PdfStamper.
Or is there a way to keep PDF/A-2B conformance in that case?
You didn't supply your source code, so this can only be answered in a more general way.
First of all check whether the space reserved for the signature container is really required or whether there are many padding bytes. In the latter case fine tune the reservation code.
If that does not suffice, embedding the CRL into the signature container automatically results in a violation of PDF/A conformance and, therefore, is not allowed.
One option would then be to try to use OCSP responses instead of CRLs here. OCSP responses usually contain information for only one or at most very few certificates while CRLs can become quite big.
If the CA does not have OCSP servers, I don't see a true PDF/A-2'ish solution. You might want to try to embed validation related information in PAdES part 4 (ETSI TS 102 778-4) DSS (Document Security Store) structures instead of in the signature container. Plain PDF/A viewers most likely won't recognize, let alone use, the CRL there but more versatile viewers, e.g. current Adobe Reader versions, should.
I am using PKCS#1 2.0 (OAEP) standard (signature with appendix), but there are some issues not clear to me.
What is the physical object that is beeing signed? I know it's hash function value and so on (I do know the algorithm), but is it calculated from the binary fform of the file, no matter what is the content?
What is the physical result of signing? A file containing the signed hash? Should this file be placed in a specified location? What is the format or extension of such thing?
If I have several files that I want to sign, should this operation be performed separately for each of them? Or should they be concatenated? Once again - what is the result of such operation (file?) ?
PKCS#1 is sometimes called 'raw RSA' and is a low-level cryptographic primitive: it doesn't work on files and doesn't produce files, it works on raw data: input is a number smaller than the public key and output is a number of the size of the public key (e.g. 1024 bit for RSA-1024).
If you want a signature file, you probably want to use PKCS#7/CMS format, as that's the most used signature format both for attached and detached signatures (even signatures in PDF files are usually PKCS#7 envelopes actually).
PS: I don't know much about OAEP, but from what I read it seems to be a padding scheme (something you do to data before the raw signature) so my argument should be still valid.