The relationship between RSA digital signature and encryption and decryption

Referring to RSA, you will think of public key, private key, encryption, decryption, digital signature, digital envelope ...
But perhaps everyone and I have, some of the understanding of which there are misunderstandings, recently looked at the RSA RFC 2313 document, coupled with some of their own tests, finally cleared up some of these relationships, mainly including the following points:
1, the relationship between the public key and the private key;
2, the relationship between digital signature and private key encryption;

3, the verification of the digital signature is exactly how the process;\

 Public and private keys

In general, we can use the RSA algorithm to generate a pair of keys, public key issued to external clients, the private key to keep their own; there are some scenarios:
"Public key cryptography, private key decryption" or "private key encryption, public key authentication"
There seems to be no doubt as to the first scenario, but for the second scenario, the validation of the public key is a personal statement, and I used to think that it was the same as a digital certificate (this is, of course, a mistake, as detailed in the follow-up to the digital certificate), and can only verify that it cannot be decrypted. But after my test proved that:

private key encryption can be decrypted with the public key; 

Therefore, for the RSA algorithm, with either side of the key encryption can be decrypted with another key, which is also explained from another angle, in fact the public and private keys are relative., releasing one of the keys out, the other one naturally becomes the private key; For this view, many students have already mentioned, but I used to think this is a misunderstanding, Khan himself;
In addition, when we use the certificate, such as PFX, CER, JKS, RSA, etc., from which we can see that the private key exposes more information than the public key, we can export XML view, of course, many of the parameters are used to accelerate, the basic information or key;
For example, the public key export format is:
<RSAKeyValue>
<Modulus>...</Modulus>
<Exponent>...</Exponent>
</RSAKeyValue>
The private key export format is:
<RSAKeyValue>
<Modulus>...</Modulus>
<Exponent>...</Exponent>
<P>...</p>
<Q>...</q>
<DP>...</DP>
<DQ>...</DQ>
<InverseQ>...</InverseQ>
<D>...</D>
</RSAKeyValue>

digital signature and private key encryption

Digital signature: It is only the sender of information can produce, others can not forge a string of numbers, it is also the sender of the information sent by the authenticity of a proof.
When signing a piece of information, the hash function is usually used to calculate the only hash result value of the signed information (for practical purposes, reduce the encryption cost, RSA encryption does not apply to large data volume encryption). Finally, the hash result value is converted to a digital signature using the private key. The resulting digital signature is unique to both the signed information and the private key used to create the digital signature.
According to the above, digital signature = private key encryption (hash (raw data)), but I use the same raw data, the same hash algorithm, the same key to calculate the results are inconsistent, so I always suspected that this description has a problem.
In this, I search a lot, ch, en, but did not find a convincing explanation, most of which is the above explanation; Finally, to the official description document RFC 2313, let's look at what the digital signature is all about:
A digital signature consists of 4 steps:

  message hashing, der Data encoding, RSA private key encryption, and byte string in-place string conversions .
This can also explain the above formula why the results of both sides of the operation is inconsistent, because the middle of a lot less computation, then I also downloaded the Bouncycastle JCE implementation source, the process is true;
With respect to DER Data encoding, this will be detailed in subsequent articles, which is a code specification that follows the ASN.1 specification; 

the verification process of digital signature

When validating a digital signature, we typically enter the signature data, the raw data, the public key together as parameters, and return the validation to TRUE or false, which creates the illusion that the public key cannot be decrypted, as stated above. But the actual verification process is not the case;
Similarly, he is completely the reverse process of digital signature, look at the official description of the RFC, the verification process consists of four steps: 

bit string to byte string conversion, RSA public key decryption, Der data decoding, the decrypted hash value, and finally compared with the original data hash value , Returns true if each bit is the same, otherwise returns false;