我隐隐约约记得，曾经有人用晶格还原法对 TLCGs 进行过加密分析，于是我挖出了原始论文，发现实在是太完美了！我只需要定义一个由 2^32 和 TLCG 中的常数幂给定的基向量的网格，然后进行网格还原。给定了还原后的基数，我只要做一个矩阵乘法就可以从高字节中恢复原始状态。

至少，这是我的想法。但我需要五个字节才能将其限制在单一结果上，而在攻击的那个点上，我只有四个字节。根据论文中描述的过程这几乎不会算出正确的答案。然而，我知道答案会很接近正确的答案，所以我跑遍了所有可能的 key1 值，并检查它给我的答案和真实答案的差异，发现了差值总是 36 个向量中的其中一个！这就是我的优化，有了这个优化，我可以只运行 36 种可能性，而不是 40 亿个。

接下来，我们遇到的是在机器上的 GPU 之间传输数据的问题。我的业务伙伴 Nash Foster 研究了 GPU 的实现，告诉我不同操作 GPU 操作的速度是多少，并为了将加密破解代码放入其中的应用程序编写了很多支持结构。我们如何将这些 PB 级的候选密钥送到 GPU 上进行测试？我突然想到，我的攻击的每个阶段都在猜测大量的比特，然后只在大约六万五千个的候选密钥中选定一个。如果我有某种方法能够透过这些信息来推导比特，而不是仅仅去猜测和检查，我就可以节省很多工作，更重要的是可以节省很多网络流量。但这个想法的问题是数学太复杂了，它涉及到将有限域的数学和整数环的数学混合在一起，而这并不是什么容易的事情。

我想了想我所知道的其他密码攻击，其中有一种似乎可以派上用场，那就是中间相遇攻击。中间相遇攻击适用于块加密，当它使用一部分密钥做前半部分的加密，而另一部分密钥做后半部分的加密。这基本上适用于压缩密码，但密钥的数量远远超过了中间的位数。后来我想到可以利用 CRC32 的线性优势：把最后一个 CRC32 的两个输出 xor 在一起，结果就可以不受 key2 的影响了 ! 与其计算加密的中间状态并将其存储在表中，我不如计算两个中间状态的 xor 结果并将其存储。

我写出了差分的中间相遇攻击，并在我的笔记本电脑上运行。之前在我的笔记本电脑上需要几个小时的阶段，现在只用了几秒钟就完成了。下一个阶段，我预计在 GPU 农场上需要一周的时间，在强大的 CPU 上只用了几个小时就完成了。我没办法让它在第三阶段计算得更快，以至于对加速整体攻击有用，但它完全避免了移动数据的需要：我们只需在每个 GPU 的电脑上计算出候选组合并让它们运算。Nash 编写了 GPU 代码，运行速度快得惊人。

攻击运行了十天，失败了。

我伤心极了。难道我们漏掉了哪些候选密钥？我们回去看了看他笔记本上的最大进程 ID，发现它比我们预期的大了几个位，因此 rand 还有其他几个可能的初始种子。我还回去仔细检查了我们所有的测试。是否有我们遗漏的东西？基于 CPU 的版本和 GPU 版本的表现有什么不同吗？我们的客户重新运行了我们的测试，发现 GPU 版本在正确的答案排在候选列表中的第二位时，无法找到正确的密钥，但在排在第一位的时候却能找到。仔细研究代码，我们发现我们在计算偏移到数据结构中的数据块索引和线程索引时，将数据块索引和线程索引互换了。 (责任编辑：admin)