看到很多文章说ENCRYPTION_SEED3～ENCRYPTION_SEED4与私钥相关，得到了这两个key就可以搞定ecc，但通过初步分析，情况并没有这么乐观。
分析了一下，至少有两种情况：
1，同时定义了LM_SEED1～LM_SEED3和ENCRYPTION_SEED3～ENCRYPTION_SEED4，则私钥只与LM_SEED1～LM_SEED3有关，与ENCRYPTION_SEED3～ENCRYPTION_SEED4没有关系。
2，如果只定义了LM_SEED1～LM_SEED3，没有定义ENCRYPTION_SEED3～ENCRYPTION_SEED4，则ENCRYPTION_SEED3～ENCRYPTION_SEED4是由LM_SEED1～LM_SEED3产生且唯一。
对于情况2，私钥是通过genkeys产生的，函数如下
其中的seed为croseeds，croseeds来源于以下代码：
newseeds通过l_genrand产生，进而得到croseeds，seed3～seed4(ENCRYPTION_SEED3～ENCRYPTION_SEED4)。
从以上分析可以看出，私钥/公钥只与lmseed1～lmseed3有关，与seed3～seed4没有直接关联。
由此有如下结论：
1，seed3～seed4和私钥种子croseeds都是由LM_SEED1～LM_SEED3产生的，但这个过程不可逆，即不能由seed3～seed4和私钥croseeds反推出LM_SEED1～LM_SEED3；
2，即使找到seed3～seed4，同样无法获得私钥。
因此暴力求解flexlm ECC的计算量还是2^96,并没有减少到2^64.
以上个人的一些浅见，还望各位flexlm大神多多指正。
static
int
genkeys(unsigned int *seed,
int pubkey_strength,
sb_PrivateKey *privateKey,
sb_PublicKey *publicKey)
static
int
genkeys(unsigned int *seed,
int pubkey_strength,
sb_PrivateKey *privateKey,
sb_PublicKey *publicKey)
l_genrand(job, lmseed1, lmseed2, lmseed3, NEWSEEDSIZ, newseeds);
lc_free_job(job);
for (i = 0;i < 4; i++)
{
if (lm_case == 7 || lm_case == 8) /* new with v8.1+ */
{
seed1 |= newseeds[i] << (i * 8);
seed2 |= newseeds[i+4] << (i * 8);
seed3 |= newseeds[i+8] << (i * 8);
seed4 |= newseeds[i+12] << (i * 8);
}
if (lm_case == 1 || lm_case == 2) /* Upgrade pre7.2 to 8.1+*/
{
seed3 |= newseeds[i+8] << (i * 8);
seed4 |= newseeds[i+12] << (i * 8);
}
croseeds[0][0] |= (newseeds[i+16] << (i * 8));
croseeds[0][1] |= (newseeds[i+20] << (i * 8));
croseeds[0][2] |= (newseeds[i+24] << (i * 8));
}
........
l_gen_pkey_headers(croseeds, pubkey_strength, &public, vname);
l_genrand(job, lmseed1, lmseed2, lmseed3, NEWSEEDSIZ, newseeds);
lc_free_job(job);
for (i = 0;i < 4; i++)
{
if (lm_case == 7 || lm_case == 8) /* new with v8.1+ */
{
seed1 |= newseeds[i] << (i * 8);
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
