P1 signature: that is, a naked signature, the signature value only contains signature information.

p7 signature: that is, the signature can contain other additional information, such as signature certificate information and original signature text information, timestamp information, etc.

So be careful not to use p7’s signature and use p1’s method to verify the signature. This is not right. It is wrong.

1. Right For the information to be signed, use the specified hash algorithm to obtain the hash value of the information.

2. Use the private key to encrypt the hash value and output the encrypted string (that is, the signature value).

The above method is also a naked signature, PKCS#1

1. For the information to be signed (that is, the original signature), use the specified hash algorithm to obtain the hash value of the information.

2. Use the public key information to decrypt the signature value, obtain the encrypted hash string from it, and compare it with the hash value obtained above. If they are consistent, the signature verification is passed, and if they are inconsistent, the signature verification is not passed.

Required Note that if you call a remote signature (such as an electronic signature), because the format of the data to be signed is different, when we verify the signature locally, we must also verify it based on different signature methods (that is, their signature Where does the byte array actually used for signature come from?)

Several common methods at present: (P1 signature verification)

CT_HASH: Tell the signer that I This is a hash string that has been hashed of the original signature text. You can directly encrypt this value without hashing it.

So in this way, when we verify the signature locally, we need to encrypt the original text Put it in for signature verification instead of the hash value after hashing (because it will hash again when verifying the signature)

CT_MESSAGE: That is, tell the signer that the content I sent is the signed one Original text. Generally speaking, because the signature values ??are all byte arrays, the signer will encode the original signature text according to the agreed encoding method, take its byte array, and then sign it

< p> When we verify the signature locally, we also need to do the same operation on the original text

CT_BASE64_DATA: Because sometimes, the original text we want to sign is just a byte[], but for the convenience of transmission, the signature is generally What both parties require to accept is a string. So there is this signature method. That is: we need to base64 encode the byte[] of the original signature. After the signing party receives it, it decodes it and converts the decoded byte [] to sign.

So when we verify the signature ourselves, we only need to pass in byte[].

The signature value returned by the third party is generally the signature value byte[] Base64 encoded string, so we need to base64 decode to get the signature value byte[].

The P7 signature is actually based on the P1 signature, with some other information added (because P1 is A naked signature only has an encrypted string. Except for myself, no one knows the signature certificate, public key, signature algorithm, hash algorithm used for signature, timestamp, original signature text, etc. It is inconvenient to verify the signature, so you need P7 The signature is a supplement. In fact, after P1, on the basis of the encrypted string, this information is appended)

So we can see in the source code of itextpdf, in fact, when it does the signature, that is First construct a string to be signed, and then throw it to a private key for signature to obtain the signature value. It then appends: certificate chain, timestamp and other information to the signature value, then constructs a P7 signature, and then puts Into the PDF file.

PKCS#1: Defines the RSA public key algorithm encryption and signature mechanism, mainly used to organize digital signatures and digital envelopes described in PKCS#7 [22].

PKCS#7: Defines a common message syntax, including digital signatures and encryption for enhanced encryption mechanisms. PKCS#7 is compatible with PEM, so encryption can be performed without other cryptographic operations. Messages are converted into PEM messages [26].