Exploring the possibility of ECC encryption being deciphered

Discussion on the difficulty of ECC deciphering

1. From the above analysis, it seems necessary to know how to create an ECC registration machine.Private KeyThis is possible. If the private key data length is very large or the data pair is used, this is basically impossible.

2. sn, Hash, H, and so on are all associated.

3. After complex operations, make the final result of the calculation equal to itself, that is, H = Hash. Otherwise, the verification fails.

4. the ECC program only has a public key, but not a private key. The private key only exists on the registration machine.

5. At first, it seems that the program with ECC seems to have something out of the program and is controlling the running of program verification. He knows, but he cannot catch him. This is the private key. It's hard to crack a word!

Therefore, brute force cracking and patching are commonly used.

Exploring the possibility of ECC deciphering

This is a bit strange. The program runs on my machine, the code runs on my machine, and his verification runs under the control of a regular public key-Private Key relationship outside the program. I am very upset. Why is my local operation restricted by some external relationship? Where is this logic? Typical overlord terms! Think about it in reverse thinking. Since successfully verified programs can run on my machine, it means they must comply with certain rules, and such rules exist in local programs, it is not necessarily a constraint outside the program! If this assumption is true, there are many rules that can be used to verify the relationship!

1. Analyze the registration machine:

 
 

  
  
K=k*G  
  
  
 
  
  
R=rG 
  
  
 
  
  
Hash=F(user,R)=F(user,r,G)=SHA(user,x,y)  
  
  
 
  
  
sn=r-Hash*k 
 
 

Sn, Hash, and user are associated, that is, sn = r-Hash * k = r-k * SHA (user, x, y ).

2. Analysis Program Verification:

 
 

  
  
sn,Hash  
  
  
 
  
  
R=sn*G+Hash*K  
  
  
 
  
  
H=F(user,R)=SHA(user,x,y) 
 
 

Verify that H is equal to Hash.

3. Verification Program Association:

 
 

  
  
H=F(user,R))=F(user,sn,G,Hash,K)=SHA(user,x,y） 
 
 

If the user is identified, G is determined, and K can all be reversed from the software), since the authentication requirement H = Hash, then we make H = Hash, H = F (user, sn, G, H, K) = F (..., sn ,..., h), that is, H = F (..., sn ,..., H ). In this case, only H and sn are changed. Given sn, the corresponding H can be given. Other constants are used.

4. Key issues: clarify the relationship between F Functions, reverse the existing information in the program, and use the qualified user, any sn as long as it meets the length and other basic restrictions ), theoretically, the Hash matching the relationship can be calculated. In this way, it has nothing to do with the private key. That is, the relationship between the public and private keys is indirectly replaced by a link.

5. ECC is exhaustive, that is, a lot of qualified items may be cited. In fact, there is no fixed corresponding value. Therefore, this is the biggest vulnerability. Therefore, there is an infinite number of password pairs that meet the H = F (..., sn,..., H) relationship.

6. Further discussion:

For the equation H = F (..., sn,..., H), sometimes there is not necessarily a resolution solution. If there is a resolution solution, it is H = HASH = f (sn...), and other values are treated as common values, which is very easy to give. Such a registration machine requires entering the user and sn numbers to determine the HASH, rather than the normal number. If the equation does not have an analytical solution, does it seem to have to be exhaustive? For example, X = a + B ** (X + c). Here, X is a variable, a, B, and c are constants. For example, HASH = user + 2 ** a * sn + B * HASH) is usually not parsed.

If we want to believe that the private key works, there is definitely no way. It may be the most stupid way to make a poor effort. Why can't we build other relationships to meet the needs of the equation to produce analytical solutions? As long as the relationships built can pass the basic verification mechanisms such as the Data Length of the program. The above equations can be used to construct additional relationships to simplify and form a simple simultaneous equations. There are too many relational equations, such:

Make the * sn + B * Hash = 0 equation (1) and convert it to HASH = user + 1 to solve the above equation simultaneously. It is simple enough. If there are some restrictions, we can also make a * sn + B * Hash = 1, 2 .......... since we are doing our best, we can take a few special cases to repeat these basic judgments.

7. ECC verification

Real ECC encryption is more complex than above, but the basic principle is the same. However, he uses the elliptic curve ing verification mechanism, which is more complex and requires more bridge construction technologies.

Conclusion on the possibility of ECC encryption deciphering

Can ECC be cracked? The answer is yes, but if the program verifies the complexity of the function, if it is difficult enough, it depends on your reverse skills and data function building capabilities. In theory, as long as one or more relational functions are built, this can replace the private key. It seems that every effort can be done, and there should be an infinite number of registration machines.

For more information about the possibility of ECC encryption deciphering, see: Exploring the possibility of ECC encryption deciphering.