参看
https://twitter.com/_mohemiv/status/1561044393880178689
@_mohemiv分享了一则消息，特定条件下两个解压密码对应同一个加密zip包。云海跟我说的这事，我几乎不上推特，各种原因吧。
Linux环境中测试步骤如下
————————————————————————–
a) 加密压缩7z a x.zip /etc/passwd -mem=AES256 -p
提示输入密码时，用这个
Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You
b) 解压7z e x.zip
提示输入密码时，用这个
pkH8a0AqNbHcdw8GrmSp
————————————————————————–
步骤a、b中的两组密码可以互换，加密时用短的，解密时用长的。
Windows环境中用7-Zip GUI测试时，注意选压缩格式 zip (默认是7z) 加密算法 AES-256 (默认是ZipCrypto)
看着有点神奇，但这不是魔法，不是前述URL所说的”后门口令”。它有一个合理的解释，参看
https://twitter.com/Unblvr1/status/1561112433812463616
@Unblvr1解释了原理
ZIP uses PBKDF2, which hashes the input if it’s too big. That hash (as raw bytes) becomes the actual password. Try to hash the first password with SHA1 and decode the hexdigest to ASCII.
他的意思是
$ echo -ne “Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You” | shasum706b4838613041714e62486364773847726d5370 -$ echo -ne “Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You” | shasum | cut -f1 -d’ ‘ | xxd -r -ppkH8a0AqNbHcdw8GrmSp
在限定条件下zip的密码逻辑有点奇怪，明文口令超长时对之求SHA1，用SHA1当密码；明文口令足够短时，直接用作密码。看7-Zip源码可以找出这段逻辑，了解多长算超长，我懒。可以确定的是，20字节不算超长。
仔细看这个逻辑，理论上对步骤b中密码的字节流求”SHA1 Collision”，有无穷多个碰撞等着你，只要”碰撞”对应可打印字符串，就可用作步骤a中密码。这种运算量太大，对普通人不现实，我连MD5碰撞都没试过，更别说SHA1碰撞。
换个思路，如何自己达到这样的效果，比如你去糊弄别人，想演示这样一种效果。该问题实际等同于，寻找一段[0x20,0x7f)区间的字符串，要求它的SHA1字节流也在[0x20,0x7f)区间。理论上可以穷举、微调超长字符串，计算SHA1，只要20个字节全部位于[0x20,0x7f)区间，就制造出一对zip解压密码。这个运算量比”哈希碰撞(SHA1 Collision)”小，我接着懒。
密码是可打印字符串，这是UI的限制，底层算法应该没这要求，从底层入手，找到匹配的机率更大。
未看7-Zip源码，但我看了一眼RFC 2898，理解了前述密码逻辑。
加密算法是AES-256，它需要32字节aes-key。无论输入password长短，均经PBKDF2算法变换得到32字节aes-key。PBKDF是”Password Based Key Derivation Function”的缩写，PBKDF2是PBKDF的一种，比如还有PBKDF1。
RFC 2898提到，PBKDF2算法所用伪随机数生成算法的一种示例是HMAC-SHA-1。后者有两个形参key、sth，在加密zip这个case里key对应password。HMAC-SHA-1算法内部对key有处理，key超过512-bits(64字节)时，对原始key求SHA1得到160-bits(20字节)
新key；原始key未超过64字节时，直接用之。
因此，在限定条件下zip的密码逻辑不奇怪，那是PBKDF2/HMAC-SHA-1的标准动作，我肤浅了。步骤a中的长密码是71字节，超过64字节。
此处有点意思哈。对于限定条件下的zip密码，并非一寸长一寸强，64字节的长密码是其强度上限，再长反而将强度除至20字节，也不知是坑谁呢。
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。