探讨ECC加密被破译的可能性 续

ECC被破译的难度的探讨

1、从上面的分析来看，要想制作出ECC的注册机，似乎需要知道私钥才有可能，这需要穷举。如果是私钥数据长度非常大或是数据对，这基本上是不可能的。

2、sn和Hash,H等都是关联的，能说是牵一发而动全身。

3、Hash经过复杂运算后，还要使计算的***结果等于自身，即H=Hash，否则将验证失败。

4、带ECC程式的本身只有公钥，而没有私钥。私钥只在注册机中存在。

5、开始的感觉是，带ECC的程式似乎有一种东西游离于程式之外，又在控制着程式验证的运行。知道他，却又抓不住他，这就是私钥。破译一个字，难！

因此，目前常用的方法是爆破和补丁。

ECC被破译的可能性的探讨

细想一下，这有点奇怪。程式在我的机子上运行，代码我的机子上跑，而他的验证运行却受程式之外的某种规律（公钥－私钥关系）的控制。非常是不爽，我本地运行凭什么受外面的某种关系制约啊，哪里有这种逻辑呢？典型的霸王条款！发挥逆向思维想想，既然验证成功的程式能在我的机子上运行，说明他肯定符合某种规律，而这种规律存在于本机的程式中，并不一定是程式之外的那种约束关系！如果这种假设成立的话，那么就说明有非常多种规律能适合于验证关系！

1、分析注册机：

K=k*G 

R=rG

Hash=F(user,R)=F(user,r,G)=SHA(user,x,y) 

sn=r-Hash*k

sn,Hash,user三者关联，即：sn=r-Hash*k=r-k*SHA(user,x,y)。

2、分析程式验证：

sn,Hash 

R=sn*G+Hash*K 

H=F(user,R)=SHA(user,x,y)

验证H是否等于Hash。

3、验证程式的关联：

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

如果确定user，确定G，确定K（这些都能从软件中逆向出来的），既然验证需求H=Hash，那么我们就令H=Hash，则有H=F(user,sn,G，H，K)＝F(…,sn,…,H），即 H＝F(…,sn,…,H）。这其中，只有H和sn是变化的，给定sn，就能给出相应的H；其他量都是常量。

4、关键的问题：搞清晰F函数的关系，逆向出程式中已有的信息，用符合条件的user，任意sn（只要符合长度等基本限制），理论上就能计算出符合这个关系的Hash。这样的话，就和私钥没有关系了。也就是用某个关系间接代替了公私钥的关系。

5、ECC是穷举，也就是说可能举出非常多符合条件的；实际上穷举也就是没有固定的对应值，因此，这即是其***的漏洞。因此，有无穷对满足H＝F(…,sn,…,H）关系的密码对。

6、进一步探讨：

对于方程H＝F(…,sn,…,H），有些时候并不一定有解析解。如果有解析解的情况，就是 H＝HASH=f(sn…)，其他量为常值看待，非常容易给出。这样的注册机，其实是需求输入user和sn两个量来确定HASH，而不是通常的一个量。如果方程没有解析解的情况，似乎也要穷举？比如 X=a+b**(X+c)，这里X为变量，a,b,c为常量。 例如HASH=user+2**（a*sn+b*HASH)等通常是没有解析解的。

如果我们要相信私钥起作用的话，那肯定没有办法了。穷举也许是最笨的办法，我们为什么不能构建其他的关系来满足方程达到能产生解析解呢？只要这些构建的关系能够通过程式的诸如数据长度等基本的验证机制就行了。上面的方程能这样构建额外的关系就能简化并构成简单的联立方程组，而构成这样的关系方程实在太多，比如：

令a*sn+b*Hash=0 方程(1)就变为HASH=user＋1联立求解上面方程，够简单的吧。如果有某种限制条件，我们同样能令a*sn+b*Hash=1，2……….既然穷举，我们举几个特例就能饶过这些基本的判断了。

7、ECC验证

真正的ECC加密比上面的复杂，但基本原理相同。只不过他采用了椭圆曲线映射验证机制，过程更复杂，也需要更多的构建搭桥技术。

ECC加密被破译的可能性的探讨结论

ECC能否破解？答案是肯定的只是如果程式验证函数的复杂程度如果够难的话，那就看你的逆向功底和数据函数构建能力了。理论上，只要另外构建一个或多个关系函数，这样就能代替私钥了，凡是穷举似乎都能这样做，而且做出的注册机应该有无穷多个。

ECC加密被破译的可能性的探讨的更多内容请看：探讨ECC加密被破译的可能性