Relationship between RSA Digital Signature and encryption and decryption

When talking about RSA, you will think of public keys, private keys, encryption, decryption, digital signatures, and digital envelopes...
However, I may have some misunderstandings about some of my understandings, just like I used to. I recently read the RFC 2313 document on RSA and added some tests of my own, finally, some relationships are clarified, including the following:
1. Relationship between the public key and the private key;
2. Relationship between digital signatures and private key encryption;
3. What is the process of digital signature verification;

Public Key and Private Key

Generally, we can use the RSA algorithm to generate a pair of keys. The public key is issued to external customers and the private key is kept by ourselves. There are some application scenarios:
[Public key encryption, Private Key decryption] or [private key encryption, public key verification]
There seems to be no doubt about the first scenario. But for the second scenario, how does one verify the public key authentication, I used to think that it is the same as a digital certificate (of course, this understanding is incorrect and will be detailed later on the digital certificate). It can only be verified and cannot be decrypted! However, my test proves that:Private Key Encryption can be decrypted using the public key.For this reason, the RSA algorithm can be decrypted using another key for encryption by any party.The public key and private key are relative.If one of the keys is issued, the other will naturally become the private key. Many people have mentioned this point, but I have always thought this is a misunderstanding and I am sweating myself;
In addition, when we use certificates, such as pfx, CER, jks, and RSA, we can see that the private key exposes more information than the public key, you can export and view the XML on your own. Of course, many of the parameters are used for acceleration, and the basic information is still the key;
For example, the public key export format is:
<Rsakeyvalue>
<Modulus>... </modulus>
<Exponent>... </exponent>
</Rsakeyvalue>
Private Key export format:
<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: A digital string that can only be generated by the sender of information. It cannot be forged by others. It also proves the authenticity of the information sent by the sender.
When a piece of information is signed, the hash function is used to calculate the unique hash result value of the signed information (for practical purposes, to reduce encryption costs, RSA encryption is not applicable to Big Data Encryption ). finally, use the private key to convert the hash result value to a digital signature. the obtained digital signature is unique for the signed information and the private key used to create the digital signature.
According to the above statement, Digital Signature = private key encryption (Hash (raw data )); however, I used the same raw data, the same hash algorithm, and the same key to calculate the results are inconsistent, so I have always suspected that this description is correct?
In this regard, I have searched a lot, CH, en, but I have not found a convincing explanation, most of which is the above explanation. I finally turned to the official description documentation RFC 2313, next let's take a look at the digital signature:
The digital signature consists of four steps:Message hash, der data encoding, RSA private key encryption, and byte String Conversion.
In this way, we can explain why the calculation results on both sides of the formula are inconsistent, because a lot of computation is missing in the middle. Later, I also downloaded the JCE implementation source code of bouncycastle, so the process is indeed true;
Der data encoding will be detailed in subsequent articles. It is an encoding standard that complies with the ASN.1 standard;

Digital signature verification process

When verifying a digital signature, we usually take the signature data, original data, and Public Key together as the parameter input, and return true or false for verification. This creates an illusion, as mentioned above: the public key cannot be decrypted! However, the actual verification process is not like this;
Similarly, it is a reverse process of digital signature. Let's take a look at the official description of RFC. The verification process consists of four steps:Bit String to byte String Conversion, RSA Public Key decryption, der data decoding, get the decrypted hash value, and finally compare it with the original data Hash ValueIf each bit is the same, true is returned; otherwise, false is returned;