安全基础之探讨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)

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）关系的密码对。