Positive Technologies 的网络安全研究员 Arseniy Sharoglazov 近日在社交平台分享了一个简单的实验并指出，加密的 ZIP 文件可能存在两个正确的密码，并且都可以提取出相同的结果。
“创建 ZIP：7z a -mem=AES256 -p
使用这个密码：Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You
提取它：7z e
使用这个密码：pkH8a0AqNbHcdw8GrmSp
Magic!”
Sharoglazov 制作了一个名为 x.zip 的受密码保护的 ZIP 文件，选择的密码是 1987 年的热门英文歌曲的双关语：
Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You
但实验结果表明，当他使用一个完全不同的密码（pkH8a0AqNbHcdw8GrmSp）提取 x.zip 时，不会收到任何的报错信息。
对此，BleepingComputer 使用不同的 ZIP 程序成功地对该实验进行了复现。该网站使用了 p7zip（相当于 macOS 的 7-Zip）和另一个叫 Keka 的 ZIP 工具，与 Sharoglazov 一样在创建时采用了较长的密码，并启用了 AES-256 加密模式。结果表明，虽然 ZIP 使用较长的密码加密，但使用任一密码都能成功提取了存档。
一些网友在 Sharoglazov 的动态下针对该实验进行了讨论，一位 ID 为 Unblvr 的用户指出，造成这个结果的原因可能在于：
ZIP 使用 PBKDF2，如果输入太大，它会 hash 输入 。该 hash（作为原始字节）成为实际密码。尝试使用 SHA1 对第一个密码进行 hash，并将十六进制摘要解码为 ASCII… :)
在启用 AES-256 模式生成受密码保护的 ZIP 存档时 ，如果密码太长，ZIP 格式会使用 PBKDF2 算法并对用户提供的密码进行 hash 处理。在这种情况下，这个新计算的 hash 将会成为文件的实际密码。研究人员解释称，太长是指超过 64 个字节（字符）。
当用户试图提取文件，并输入一个超过 64 字节的密码时，用户的输入将再次由 ZIP 应用程序进行 hash，并与正确的比较密码（现在本身就是一个 hash）。如果匹配，将可以成功进行文件提取。
示例中使用的替代密码 pkH8a0AqNbHcdw8GrmSp 实际上是较长密码 SHA-1 hash 的 ASCII 表示。Nev1r-G0nna-G2ve-… 的 SHA-1 checksum = 706b4838613041714e62486364773847726d5370。此校验和在转换为 ASCII 时产生：pkH8a0AqNbHcdw8GrmSp。
但是值得注意的是，在加密或解密文件时，仅当密码长度大于 64 个字符时才会进行 hash 处理。换句话说，较短的密码在压缩或解压缩 ZIP 的任何阶段都不会出现这种情况。这也是为什么在加密阶段选择长的 “Nev1r-G0nna-G2ve-…” 字符串作为密码时，ZIP 程序设置的实际密码实际上是该字符串的 (SHA1) hash。
如果在解密阶段输入 Nev1r-G0nna-G2ve-…，它将被 hash 并与之前存储的密码（即 SHA1 hash）进行比较。但是，在解密阶段输入较短的 “pkH8a0AqNbHcdw8GrmSp” 密码将使应用程序直接将此值与存储的密码（也就是 SHA1 hash）进行比较。更多的技术见解可参见 Wikipedia 上 PBKDF2 的 HMAC collisions 小节。
“当使用 HMAC 作为其伪随机函数时，PBKDF2 有一个有趣的特性。可以轻松地构造任意数量的不同密码对，每对密码对都存在冲突。如果提供的密码长于底层 HMAC hash function 的块大小，则首先要将密码 pre-hashed 成一个 digest，然后将该 digest 作为密码使用。”
不过，同一个 ZIP 有两个可能的密码这一事实并不代表存在有安全漏洞；因为生成密码的 hash 的前提是需要知道原始密码。
本文来自投稿，不代表展天博客立场，如若转载，请注明出处：https://www.me900.com/326167.html
