I'm using itext MakeSignature.signDeferred to add signature to pdf.
I use deferred signig because i use external signature container.
How is possible to add timestamp in this case, the method not support tsaclient parameter like signDetached
MakeSignature.signDetached(sap, externalDigest, externalSignature, chain, crlList, ocspClient, tsaClient, estimatedSize, sigtype);
The method doesn't support a tsaclient for obvious reasons: you use external signature functionality to create the signature bytes. These bytes may not be altered, but need to be inserted into the PDF "as-is". This means that it's up to your external signature container to support timestamps. If it doesn't, you're out of luck.
Related
I am implementing my own version of RSA-OAEP with SHA-256. I want to test it by comparing it to the output of the Cipher class in Java using RSA-OAEP and SHA-256. According to PKCS #1, RSA-OAEP requires a label, which by default is an empty string. However, I can't find a way to input a label in the built-in class. My implementation seems to work correctly for both encryption and decryption, but Cipher class produces different output. Is there a default label which the Cipher class uses?
What is called label L in PKCS1v2.1 RSAES-OAEP was called encoding parameters P in v2.0; see the description of pSourceAlgorithm in A.2.1. The Java API keeps the old terminology, presumably for compatibility, and the default is indeed an empty octet string, implemented in Java as a byte array of length 0. See https://docs.oracle.com/javase/7/docs/api/javax/crypto/spec/PSource.PSpecified.html . Note that even when P-call-me-L is empty, its hash which goes in DB before masking is not empty.
When you say 'different output', you do realize that OAEP is randomized (in a way that provably does not leak information to the adversary) and every encryption of the same plaintext should produce a unique ciphertext, but all of them should decrypt back to the same plaintext, right?
How can this be done in iText? I have a PDF with a signature from a client. I need to add an ocsp response to unsigned attributes.
I know how to change the signature itself using
org.bouncycastle.cms.CMSSignedData.replaceSigners(...).getEncoded()
but I don't know how to replace PdfName.CONTENTS in the PDF using new PdfString(newSignature).setHexWriting(true). If I use this code:
PdfDictionary other = new PdfDictionary();
other.put(PdfName.CONTENTS, new PdfString(newSignature).setHexWriting(true));
dicSignature.merge(other);
where dicSignature is the dictionary which contains the signature, then the signature (when the document is opened in Adobe Reader) is broken.
When iText manipulates a document using aPdfStamperin normal mode, it can (and often does) re-arrange the existing PDF objects. This obviously breaks the hash value of any existing integrated signature. Furthermore the byte ranges which would have to be signed, change. This most likely is your problem.
When iText manipulates a document using aPdfStamperin append mode, it leaves the PDF as is and only appends its additions and changes. While this in general is the way to go to keep integrated signatures from breaking, you cannot change the content of a signature this way because there are stricter rules concerning embedding signatures than for PDFs in general. Switching to append mode, therefore, would not fix your problem.
Thus, iText has an explicit method doing a signature insertion without otherwise changing the PDF:
MakeSignature.signDeferred(PdfReader reader,
String fieldName,
OutputStream outs,
ExternalSignatureContainer externalSignatureContainer)
throws DocumentException, IOException, GeneralSecurityException
Its name is due to the fact that this method originally is intended for the use case of deferred signing, i.e. first preparing the PDF for signing (i.e. adding all dictionaries and other necessary structures required to hash the byte ranges, including leaving a gap into which a signature container eventually shall be injected), calculating the hash value, and sending it to some other service while storing the prepared PDF locally. As soon as that other service returns the signature, the prepared PDF is located and the retrieved signature is inserted into it using this method.
The only difference to your use case is that there already is a signature in the gap. That signature, though, will be overwritten by your updated one when using signDeferred.
Having said all this, you may be in for a surprise if you expect that after you add an ocsp response to unsigned attributes, Adobe Reader uses these information for verification. In the context of integrated PDF signatures according to ISO-32000-1, section 12.8.3.3 PKCS#7 Signatures as used in ISO 32000,
the PKCS#7 object should contain [...] Revocation information as an signed attribute (PDF 1.6): This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature. This means that the software used by the signer must be able to construct the certification path and the associated revocation information. If one of the elements cannot be obtained (e.g. no connection is possible), a signature with this attribute will not be possible.
When using gwt-maven-plugin's generateAsync, is it possible to apply an annotation (or something) to an individual gwt-rpc service so that the corresponding async isn't auto-generated and can be written manually?
Alternatively, is there an annotation (or something) that makes the generated asyncs have the "Request" return type?
From the gwt-maven-plugin's documentation you need to adjust the servicePattern configuration property, or you can ask it to always generate methods returning Request.
Or, even better, don't use this goal!
(or only call it manually once in a while and copy the generated classes to your sources)
The GWT Generators will never create a class if one already exists with that name. This means you can ask GWT to compile and generate the code, then copy the classes into your sources and customize them, and later compiler runs will not attempt to generate sources.
This may have other side effects - if the proxy, typeserializer, or fieldserializer is prevented from being generated, then the RPC generators may assume that other dependencies have also all been correctly generated, so you may find yourself missing classes if you don't also copy those other classes. Likewise, of course any changes that require your serializers being modified or rebuilt will have to be done manually, such as changing a serializable type, or modifying a RPC method.
Your async interface can always declare a return type of Request or RequestBuilder instead of void. If you declare RequestBuilder, then the request will not be sent automatically, and you must call send(), whereas a Request returned means that the request has been sent.
I'm wondering whether it is at all possible to make the client ask the server for a given string, and incorporate it into another string ?
I don't see how to do that using the async approach.
As far as I know there is no really simple way to do this, because the i18n machanism of GWT replaces strings at compile-time and not at runtime.
You can try one of the following approaches:
Load the i18n in your entrypoint, store all messages in a local Map and create the Label etc, with the values from you cache. PRO: all GWT standard CONS: one request more, before you can show a translated page
Use JSP and no HTML at serverside. Wthin you jsp can create a JSON from your
message.properties and put it into your hostpage. PRO: You can synchronous read te values CONS: You will need to write a JSP which reads the properties for the correnct language, You will need to write a JSNI method to load the translated values.
Rethink, if you need a different way of translation. The built-in i18n will create tranlated versions of your app at compile-tim
I think I would use the second approach.
I have requests like
5|0|7|http://localhost:8080/testproject/|29F4EA1240F157649C12466F01F46F60|com.test.client.GreetingService|greetServer|java.lang.String|myInput1|myInput2|1|2|3|4|2|5|5|6|7|
I would like to know how GWT generates the md5 value 29F4EA1240F157649C12466F01F46F60? Is it based on the client ip and date? Can anyone point me to the correct code? I just find stuff regarding the history token, but that looks different to me.
OK, after some research I think I found the answer.
The keywords you should have been looking for are "strong name" (or "strongName") and/or permutation, since it seems that with the RPC request they send out the permuatation strong name (that MD5 hash), so that you can possibly distinguish on the server side from which permutation the request was send.
The core function is Util.computeStrongName, it computes an MD5 hash (d'oh) of the provided byte array, with the added catch:
/*
* Include the lengths of the contents components in the hash, so that the
* hashed sequence of bytes is in a one-to-one correspondence with the
* possible arguments to this method.
*/
From there, I tracked back to the linkers and then to PermutationResult which is feeding Util.computeStrongName via this function:
/**
* The compiled JavaScript code as UTF8 bytes.
*/
byte[][] getJs();
Eh, I hope that was at least a bit helpful ;) If this still doesn't answer your question (or you were looking for something different), try in trunk/user/src/com/google/gwt/user/client/rpc (start in RpcRequestBuilder.java).
As Igor said, GWT uses MD5 hashes of your application code to produce unique names for each permutation of each version of your application. The specific hash you referenced is a part of the GWT RPC request payload that identifies a .gwt.rpc serialization policy file on the server. That policy file says which Java objects can be serialized as part of the request, response, or thrown exceptions in the GWT RPC service.