【问题标题】:Decryption type and breaking (AES 128?)解密类型和破解(AES 128?)
【发布时间】:2010-12-12 08:35:08
【问题描述】:

我的问题分为两部分。第一个是“我使用了哪种可能的加密类型”,另一个是“破解它的可能性有多大”(一旦找到加密算法)。

所以,我得到了原始文件和加密文件,当原始文件发生变化时,我能够测试加密文件的行为。我发现的最重要的线索是:

  1. 原始文件和加密文件大小完全相同(注意大小是0x10 = 128位的乘积)

  2. 加密块大小似乎是 128 位。当原始文件上的一个字节发生变化时,加密文件上的相同 128 位块会发生变化,有时(可能)上一个或下一个块也会发生变化。但大多数时候只有这个块。并且文件的其余部分根本没有改变。

  3. 原始文件中有重复的部分(例如 16 字节的 00 值),但在加密文件上没有相同的 128 位块结果。因此,第二个块中的 16 个字节的 00 与下一个块中的 16 个字节的 00 具有不同的加密结果。

考虑到这些线索,你能猜出它是什么类型的算法吗?我以为它是 AES 128 位,但线索 #2 不包括 CBC 模式,而线索 #3 不包括 ECB!似乎是那些“之间”的东西......它可能是任何其他模式下的 AES 128 吗?你还能想到什么?

如果有几种已知算法可能导致该行为,那么能够破解它、知道原始数据并能够对这两个文件的更改进行测试的可能性有多大?

提前致谢

【问题讨论】:

  • ""当原始文件上的一个字节发生变化时,[...} 前一个 [...] 块 [changes]。" 你有仔细检查过吗?那会有所不同从我听说过的任何模式。
  • 我会尝试再次检查。也许这是因为 2 个块上的 2 个字节发生了变化,所以会再次尝试确定。

标签: aes encryption break


【解决方案1】:

这听起来像是 ECB 模式的一种变体,其中明文块与一个随机数进行异或运算,该随机数来自该块在文件中的位置,然后在 ECB 模式下加密。

这将导致观察到的特征:

  • 文件大小没有增加(因此没有 IV);
  • 输入中的单个字节更改会影响整个输出块。

(nonce 可以像计数器一样简单)。

这个方案很弱。它很容易受到与 ECB 模式相同的频率分析攻击——它只需要更多的密文。此外,您收集的任何明文/密文对都可重复用于您找到的任何未知密文中的相同块位置。

【讨论】:

  • 但是这样的方案并不能解释为什么(有时)在被修改的块之前或之后的块发生变化。否则我也会这么想(比如 XEX、LRW 或 XTS 模式),但这些模式都没有这个邻居修改属性。
  • 好吧,OP 确实说“也许”关于这些块的变化,所以我打折了。然而,如果文件被分成不是块大小倍数的段,这实际上可能只是在 XTS 等模式下窃取密文的效果。
  • 感谢您的帮助。也许这比点击率更有意义。我知道一些原本应该是 00 的部分,所以我想我可以用这个做点什么(“攻击”00 块)。有什么具体的建议吗?
猜你喜欢
  • 1970-01-01
  • 2015-03-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-12-03
  • 1970-01-01
  • 2018-04-04
相关资源
最近更新 更多