友情联动：发支付宝口令红包，欢迎大家破解.

[3dwelcome]

昨天有个帖子： https://www.v2ex.com/t/776529 前端加密让大家破解 AES 加密红包，这太离谱了。

我把 AES 算法去掉，现阶段的计算机要破译几乎不可能。改成了最简单的 XOR 加密，也放入了口令红包，欢迎大家破解。

规则如下：

1. 支付宝口令红包是纯数字的 0~9, 长度固定为 8

2. password 明文密码被限定为 0~9, a~z, A~Z 这个范围内，无特殊字符，无中文和符号。

3. 为了便于校验结果是否有效，支付宝口令累加起来的数字，是 45 。(比如口令是 12345678, 累加值就是 1+2+3+4+5+6+7+8=36)

4. 核心解密函数就一行，password 是不知道的，是前端 input 用户输入。

var str = "WmXOsVFG";
var pass = "????????";
var num = "";

for (var i=0;i<pass.length;i++)
num += String.fromCharCode(pass.charCodeAt(i) ^ str.charCodeAt(i));

[AoEiuV020]

楼主这个例子可以继续简化一下，xor 都不需要，
var sum = 87654321;
var pass = ????????;
var num = sum - pass;
num
已知 pass 是 8 位数字，求 num,

[qq316107934]

@kop1989 同意你的观点，尤其是后面还有不定长随机字符。构建彩虹表也是需要大量时间的，彩虹表只能加速离线搜索速度。

[3dwelcome]

@AoEiuV020 “简单意味着爆破效率高，因此安全性差，”

AES 还能 CPU 加速来着，运行速度极快，但就是没人说过安全性差。

你这里列举的反面例子里，把 XOR 替换为 AES，还是同样适用的。

只要 XOR 密钥构建足够长，比如明文长度 100M，密钥长度也是 100M （程序生成无重复序列），那么 XOR 安全性一点都不输给 AES 。

[AoEiuV020]

@3dwelcome 可能是对“安全性”的理解不一样吧，
假设算法中 xor 秘钥长度 100，破解理论需要计算 100w 次，破解需要时间 10 秒，
而 aes 秘钥长度 16，破解理论需要计算 1w 次，破解需要时间同样 10 秒，
你认为在这个例子中 xor 安全性和 aes 一样，
我认为在这个例子中 aes 安全性更高，

[3dwelcome]

@AoEiuV020

代码运行速度慢 = 安全性高？这种思路不对吧，好算法设计就是要运行速度足够快。

不能说我设计一个加密算法，起名叫乌龟，就很安全，这不科学。

你说的爆破解，也仅仅针对有唯一解的题目。现实中很多密文解密后，都是一行文字，都不能确认是不是唯一的。

[AoEiuV020]

@3dwelcome 不是=，这只是一方面，还有其他因素影响安全性，我只是想描述简单和安全性的联系，是通过爆破效率联系上的，

[AoEiuV020]

@3dwelcome 比如 linux 的 su 为了安全，就有故意在密码错误时设置延时，降低响应速度，降低破解效率，提升安全性，这只是一种手段，一条路，肯定不能放弃其他只看这个，

[3dwelcome]

@AoEiuV020 手机 SIM 卡 PIN 只要输错三次，直接就锁卡了。

也没牵涉到任何加密算法，就是极大限度提高黑客的试错成本。

这样确实是安全性高一些，但个人觉得和算法本身设计，已经没什么关系了。

[pke]

@matrix67 #7 用一小时看完了，了解了一段精彩的历史，不算浪费，比当初参与此种的人甚至节省了很多时间

不过注意点神贴回复数人都提到 2012 年在挖 btcoin，不知道他们现在怎样了

[skies457]

科班出身、学过基本密码学的人根本不会出这样毫无意义的题，本质上就是给定序列 A，求解 Ai^Xi=Yi，在没有额外信息下这组式子有无数解，因此枚举 Xi 和枚举 Yi 是一样的，不如直接去试支付宝口令。那么为啥 xor 不适用于需要正经加密的场景呢？因为这些场景往往是有额外信息的，比如破解文本密码经常会用到英语字母的频率，而且生成出来的结果一般是有意义的（比如网络包都有固定的结构或者 header ），所以 xor 加密在大量使用的情况下安全性非常差

[BeautifulSoap]

看了上面彩虹表事件之后，我猛然发现了一个大家都没注意到的有意思的细节，事件时间是 2012 年，站长有个回复：

Livid：
曾经我还挖矿的时候，两块 6870 可以每秒 600M 个 SHA1，而 MD5 的复杂度更低


2012 年之前挖矿的话那肯定是比特币了，不知道站长之后有么有把币卖了，如果没卖的话那难怪 V2EX 能坚持这么多年还没广告

[Mohanson]

对 xor 感兴趣的话，去搜下 rc4 算法，然后理解它为什么是不安全的以及为什么被弃用

[3dwelcome]

@skies457 你说的不就是频率分析攻击吗？

这些攻击针对的都是定长密钥，对于代码自动生成的无限长密钥，这些 XOR 弱点都不存在。

可以不回贴，但不要不懂装懂。

[x86]

@lbyo #17 这是当年送 rmbp 的帖子吧

[skies457]

@3dwelcome 那么请问您要怎么分享这个无限长的密钥呢

[3dwelcome]

@skies457 分享无限长的密钥，用的肯定是生成无序数列的代码片段了。

有了 webasm，几乎什么算法，js 都是能正常运行的。

你要说在分享过程中，代码片段被中间人截取了，那等于是密钥泄漏。几乎任何加密算法，都没办法在密钥泄漏的情况下，避免被破解。(除了量子加密外）

[lbyo]

@x86 是的，今天无意中看到了，还把整个时间线搞出来了，不知道老哥当年有没有看到全程，需要分享吗

[x86]

@lbyo #37 哈哈，我全程看过

[no1xsyzy]

@3dwelcome #10 目前来说，拿卡牌游戏做比喻
非对称都是数学的宝石，类似一套操作 OTK 或者北京龙卡回合套路。
对称大多数是按部就班地处理，类似堆怪堆甲堆 buff
而哈希则像是捣浆糊的神智错乱，好比把『混沌之球』撕成碎片然后掷向对方半场

不过 random padding 对称也能做，甚至 hash 也能做（加盐）。

#25 也有 bcrypt 这种纯粹为了慢设计的算法
#28 CIA 三方面里面，A 能靠一定错误次数后加锁来保证，而 C 不能靠一定错误次数后加锁来保证

[skies457]

@3dwelcome https://en.wikipedia.org/wiki/Stream_cipher_attacks 建议读一下这个，你这个 idea 已经被研究几十年了