任何东西加个绝对那就是没有

在 HTTPS 上面再自己实现一遍基础的密钥交换就行，抓包只能看见公钥和密文，无法解密，配合客户端混淆/反调试等手段，可以杜绝大部分攻击了

> 密钥似乎只能一层套一层解决？ 实际上加密层数量并不是越多就越安全，密钥算法 != 加密层数量，如何选择密钥、如何存储密钥才是更应该优先考虑的点。 > 后段提供一个接口获取公钥（假设是一随机串） 公钥是和私钥根据算法一块生成的，不理解你说的随机串是什么 > 前端调接口拿到公钥加密 A ，得到 A+ 然后 A+ 给到后端用私钥解密 通常从效率考虑，不会用公钥去加密数据，而是用对称密钥去加密数据，公钥用来加密对称密钥

前端加密解决的是敏感，而不是安全 (无法以任何手段保证绝对安全)，即原始明文是否应该发送到服务端，对用户来说是一件敏感的事。 (虽然服务端并不会储存原始明文，csdn 这种傻逼公司很好地说明了储存明文密码不会带来任何益处反而后害无穷) 前端加密只需要任何一种不可逆算法就行，不要考虑太复杂的东西。

如果应用层要做： 1 使用临时密钥，比如密钥协商算法协商一个特殊用途的会话密钥 2 最终会需要一个类似根密钥的密钥，这个在硬件中才能具有很高的安全性 3 没有绝对安全，只有层层加码

密码学第一原则：不要自己发明密码学 顺便，最近在前端密码学上有一定的突破，但绝对不是你这么简单的方案就能正确、安全地实现的。参考： https://blog.cloudflare.com/improving-the-trustworthiness-of-javascript-on-the-web/

没有绝对安全方案，你说的方案能增强安全，但仍需防范公钥伪造等风险。

没有

rsa 已经可以明码传输密钥了，有这背书，你改怕个啥。不然银行早跪了

TLS+RSA 足够安全了 再多的话...再写个 jsvmp 的 sign 算法 给上传的参数加签