Digital signature Workflow

If asymmetric encryption is usedAlgorithmCommunication between the two Parties will introduce third-party attacks. For example, you can obtain the public keys of both A and B, A and B.

A actively communicates with B and obtains B's public key first.

 

A --> B. Use the public key of B to encrypt and append your own public key.

B --> after receiving a and B, A and B also obtain the public key of a and use the public key of a to encrypt and send it back to

 

This prevents third parties from listening to the content of the sender. However, the problem is that third-party attacks cannot be solved. For example, there is a m in the middle, and m impersonates a to send content to B.

In fact, the problem cannot be solved!

 

The solution is to encrypt the sent content twice, and both parties have a reliable way to know the other party's public key.

When a is sent to B, it is encrypted with the private key of A and then encrypted with the public key of B.

After receiving the message, B decrypts it with B's private key and uses a's public key to obtain the plaintext.

 

There are different ways to obtain a public key.

1. The communication parties have the public key of the other Party in advance. This method is troublesome and requires face-to-face exchange. Obviously it is not suitable for large-scale applications. It is better to use it between husband and wife!

2. The third-party digital signature is better. Everyone puts the public key in the third-party ca. The communication initiator asks the CA for the public key of both parties and sends it to the other party.

For example, a initiates a request to B. A first goes to the third place to put the CA's request to B's public key. After Ca returns the request to a, a encrypts the request with the private key to B. After receiving the request, B decrypts the request to Ca and decrypts the request to B. B knows the public key of a and can verify whether a's own public key is correct.

 

Man-in-the-middle attack is impossible: B cannot impersonate a, and B cannot use the public key of a to unbind any man-in-the-middle impersonate.

A credit is not possible: B can present the encrypted message after receiving the message. Only a has its own private key.

B cannot say he hasn't received the message: He has been to a third party, or he has already presented the received message from B, because only B has its own private key.

 

This articleArticleJava implementation, good http://blog.csdn.net/lijiecong/archive/2011/04/21/6337932.aspx