表单提交时有没有替代 rsa、来加密用户名和密码的方案？

15175 jsbn.js
1009 prng4.js
1883 rng.js
2644 rsa.js
1624 base64.js

全套加起来不足 30k 还没压缩这都嫌大？

找到一种取巧的方法，非对称加密老外称作是 trapdoor one-way function ，按照这个思路考虑，只要查到一对互换公式，单从 JS 客户端加密公式，无法反推导出服务器解压公式即可。

有一个多项式 hash function, 不算 one-way, 服务器公式和客户端公式不同，因为逆推算法比较冷门，代码也很少，不牵涉到大数运算，可以暂时用一下。

举个不恰当的例子，就是用 FFT 那种，把用户名密码，当作把普通的空域的数值变换到频域，然后用频域数值作为安全传输(数据量是原密码长度的两倍)，服务器用逆 FFT 公式还原频域到原密码即可。

找一堆冷门正 FFT 公式 /逆 FFT 公式，基本上就搞定这个需求了。当然没 RSA 安全，但是登录代码少了很多，速度也快。

写的有点绕，简单来说，就是 JS POST 表单，用户名密码用 Math.sin 加密，发到服务器用 Math.asin 解密。不是所有人都看到客户端 sin 就能马上推导出 asin ，找一对很少有人知道的 sin/asin 类似函数。

@3dwelcome 你确定黑客看到 Math.sin 的时候想不到 Math.asin 吗？

密码学中，你这种加密的安全性是建立在加密算法不被人知道的基础上的。就像当初的凯撒密码，一旦知道加密方法，就没有丝毫的安全性可言了。

rsa 不行还有 ecc 嘛， ecc 不行还有 nacl 嘛，为何如此想不开。

@bp0 这和凯撒密码还是有区别的，凯撒密码是对称式加密，只要有密钥，就能解压，因为加密公式和解密公式是一样的。

而 Math.sin 和 Math.asin 是非对称式加密，就算加密公式都公布了，你不是数学大神，逆推不出服务器解密公式的，

楼上用 sin 举例是方便理解的特例，一般都是多项式散列，一但公式生成，要逆推很难，和 RSA 一样，加密容易解密难。

@zhicheng 我也用过 ecc 加密，算法比 rsa 更复杂更不好理解，同样需要超大数计算。一个 html 的 login 的登录界面而已，追求简洁明了，上这种大杀器，好神奇的感觉。。

提到 ecc, 让我想起另一种纯几何加密算法，类似 ecc ，我们把用户名和密码看成屏幕上的一个 x,y 值。用三维的算法，拓展到 x,y,z 空间，投影到一个三维平面上， post 提交，就变成传一个三维坐标点。

黑客看到三维点，没平面公式，他也不知道服务器是如何反投影到二维平面上还原的。

更甚者，可以把二维点投影到 NURBS 三维曲面。个人感觉一般的黑客中间抓包偷密码，分析到这步就没办法了吧。

看到隔壁讨论 qrcode ，又想到一种新方法，做个笔记。

利用 qr 里的错误纠正算法(Error Correction Code - Reed Solomon)，把密码压成二进制，在传输前随机引入很少的错误值(xor)，让 ECC 算法，在服务器做自我修复，还原正确密码。

由于 ECC 算法，一般都牵涉到多项式定义，所以只要和 ISO 标准里不一样，自己写自定义多项式，纠错效果差不多但算法不公开，黑客自然也就直接放弃破解密码了。

加密安全的方式基本是两种
1:算法不公开
2:密钥不公开
当然满足前者的时候，后者也无所谓了

从前者切入并不是不可行，但你是专业的密码学人员么，你设计算法的时候是“真的无法破解”，还是“我觉得无法破解”？我们选修密码课的时候，老师第一次就讲，码农不要去挑战密码设计的事情，在专业的人眼里，你们做来做去都是些小儿科。
如果是前端 JS ，那么加密过程是公开的，你的算法能保证不能反向推导出解密过程么？而且算法不公开真的完全无法破解么？我不确定在通过大量加密前后内容对比，专业人士能不能分析出什么。

这就是所以为什么要用那些开放算法的原因，一些经典的算法，如 RSA 或者 AES 这种都是通过开放算法来得到大规模检验并且存活下来的算法，可靠性相当高。

当然还另一个方面的事情，你做的东西究竟有没有人愿意投入资源去破解罢了。

我倒是觉得 AES 才不安全，太热门了，算法都被用烂了。如果用在 JS 里，你 100%要生成密钥，不管是什么密钥交换算法，最后总要传输到 AES_SETKEY 这个函数入口，黑客只要无脑在入口函数下断点，蹲点就可以了-_-

至于你说专业人士能不能逆推算法，我只想说对于普通人来说，逆推一个 y=sin(x)+cos(x)的反函数都很难，何况是自定义那种很复杂的多项式呢，并不是人人都是数学大神，对吧。

越冷门的算法，研究人越少，就越安全。

@3dwelcome AES 从来就没有过作为传输密码的用途，什么时候给你对称加密可以用在密码传输里面的假象了？

另外，设计算法从来就不考虑热门和冷门，考虑的是算法的鲁棒性，假如热门起来了，全世界的人都来研究你的算法是不是还是坚不可摧的？

事实上，对于只允许输入有限次数的密码，你随便写个映射基本都没人搞的定

楼上的观点不能赞同，这里 POST 里的用户名和密码，别和 SSL 里交换密钥的概念搞混了。表单就是一个普通数据而已，你如果换成 https 里的 post 提交，最终 HTML 表单里，用户名和密码加密还是走的 AES 加密通道。

更甚者，你要是能通过 HOOK 浏览器，从内存顺利截取到 AES 的 KEY 密码，就算你用 SSL 安全传输，还是照样能够还原原文，这和密钥交换一点关系都没有。这就是我说的不安全终极原因所在，任何人都知道的公开算法，给一个 KEY 就能还原，被破解。

能不被破解的，只有自定义的单向加密算法，比如 NURSB 三维空间加密，听这名字就知道高大上，只要把 JS 客户端投影公式做个化简，神仙也还原不了服务器反投影公式。就如上面说的，求代数函数反函数难，求几何投影反投影更难。 ECC 知道不？就是基于几何原理，还只是二维的，不是三维的。

@3dwelcome 服，你觉得对就是吧， HTTPS 的 AES 不是拿来保护密码的，如果要保护密码，有更多更好的方案。

建议多读书，少吹比

我就不知道，为啥楼上不能把 HTTPS 里表单 POST 的用户名和密码，理解成普通的数据。而一定要做特殊处理。

好，就算特殊处理，很多论坛的数据库里，存密码是加密形式，用的是 blowfish, 还是很容易被解密成明文。

假设，如果 GOOGLE 浏览器完全用 JS 重写底层， SSL 相关代码全部改成 JS 端，很容易下断点，估计现在的 HTTP AES 各种加密模式会发生翻天覆地的变化，在未来，没人会在乎世界上曾经有一个算法叫 AES 。非对称算法将会遍地开花，普照人间。

无知者无畏， SSL 安全居然是浏览器不能被下断点，再见

@SoloCompany 我看到这句也笑了。这是不是做计算机的。。