Network key exchange and public key distribution method

First, the background

In the current network environment, in order to ensure that the data in the communication between two nodes is secure, the ETH network usually needs to use a public key algorithm (asymmetric encryption algorithm) for key exchange, and then use a symmetric encryption algorithm. Data encryption, using a one-way hash function to generate a data fingerprint, using a signature algorithm to generate a data signature, and then sending the encrypted data, data fingerprint, and data signature together to the other party.

This is the current general method of key exchange, but there is also an unavoidable problem, that is, a third party is required to ensure the correctness of the public key, and a trusted third party is required to provide the public key of the other party before the two parties communicate.

This article describes a method for performing key exchange without using a public key algorithm but with a workload proof. The entire process does not require the participation of a third party.

Second, the program

Assume that both sides of the communication are A and B. In the method, x is a random number, y is an n-bit encryption key to be exchanged, and n is a fixed value. The process is described as follows:

• Now and in the future, how many bitcoins are there to count as whales
• Xiao Lei: It’s wrong to hold bitcoin to see the world.
• Perspectives | The impact of digital assets on the global hosting market

1. A uses a random number algorithm to generate x, generates an n-bit key y, and uses y to symmetrically encrypt x to generate ciphertext Sx.

2. A repeats step 1 to perform m times and generates m Sx. Since x is randomly generated, m x, y, and Sx are all different.

3. A sends m x and Sx to B.

4. B randomly selects a pair from m x and Sx, and then performs exhaustive cracking to crack out y. The process of exhaustive cracking is proof of workload.

5. B sends the selected x to A. At this point, both A and B know the key y. Then use y to encrypt the data for communication.

The feasibility of this method is mainly in the complexity of a single exhaustive crack and the number m of messages. The complexity of the crack is too high, which will lead to too much time for the proof of work. The number of messages is too small, and too little will reduce the difficulty of cracking.

Of course, there are other problems with the above method. For example, if the data in step 5 is intercepted in step 3, although the specific x, y cannot be solved temporarily through the third step, the fifth step can crack x, y. If in the subsequent communication, only y is used to encrypt the data, there are also problems with data integrity and non-repudiation. There is a situation that is very suitable for this method. That is, when the two parties do not know the public key of the other party and do not want to rely on the third party, they can rely on this method for secure key exchange and public key distribution and secure communication. So we continue to improve the program:

Third, the optimization program

The preconditions of the above scheme are unchanged, and each of A and B generates its own public-private key pair.

1. The above steps 1, 2 are unchanged.

2. A sends m x, Sx, and Pxa to B, where Pxa is the result of encrypting Pa with y, and Pa is the public key of A.

3, B randomly chooses a brute force to crack y, and then decrypts Pxa according to y, and also knows Pa at this time.

4. B uses Pa to encrypt x, and uses y to encrypt Pb and send it to A.

5. A receives the private key to unlock x, then knows y, and uses y to know Pb. At this point, A, B know y, and the other party's public key.

From the security point of view, even in the second step, in step 4, even if the data packet is intercepted, the attacker cannot crack the required y from m x, Sx, and cannot know the public key of both parties.

Another solution to this optimization solution is the distribution of public keys. The commonly used public key distribution is to store the public key in the centralized database first, and then obtain the corresponding public key in the database, but since the user does not know who needs to communicate with it, the user computer and the database server must be guaranteed. It is connected. This method does not require a centralized database to support distribution, only the communication parties can know that the other party exists.

Author: thank HPB Blue Lotus team finishing feeds.

Note: If you have any questions, please leave a message below to contact our technical community.

Wang Xiaoming blog: http://wangxiaoming.com/

Wang Xiaoming: Founder of HPB core chain, Babbitt columnist. More than ten years of experience in financial big data and blockchain technology development, he has participated in the creation of UnionPay big data. The main creative blockchain teaching video program "Ming Shuo" more than 30 issues, compiled the "Ethernet official website document Chinese version", and as the main author wrote the "blockchain development guide", in the Chinese blockchain community with ID "blue lotus "famous.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!