基本可以实现前端加密和后端解密，并且较难被破解的方法？

场景为 ajax 发送一个加密的字符串，给后端解密。该字符串的实际内容不想被用户抓包察觉

rsa 不就行了，跟语言没关系啊

后端向前端发一个公钥，前端用公钥加密，密文传给后端，后端用私钥解密。

->并且较难被破解的方法？
js 用 wasm 加密可以增大破解难度，但是本质上只要利益够大迟早会被破解

用 wasm 加个壳吧

没方法，js 加密本身就很迷惑，加密算法无法保密->wasm 虽说可以编译，但解起来也就那回事，数据源也是暴露前端的无法加密，所以加密给谁看呢

这个公钥一抓包不就被破解了

建议描述一下你的需求，首先前端和后端的通信加密只要有 https 就可以了，除非是你前端产生的内容不想让用户看到所以加密传回后端，但是本质这个需求单纯通过 JavaScript 是不可能的，前端代码对于浏览器本身就是全透明的，你怎么产生的怎么加密的都没什么意义，顶多混淆了代码，看起来费点力气而已，wasm 楼上也说了，存在反编译问题，也只是增加了难度，所以问题应该出在需求上。

有个问题，公私钥是不是只针对非对称加密，LZ 需要的是不是一个对称加密，以及密钥分发方案。

怎么弄都会被破解， 只要利益超过破解付出的成本

场景呢？没场景？

登录密码加密吗？上 https 足够了，针对这个场景任何前端加密都是脱裤子放屁。

显示隐私内容？前端输入密码才能看？那应该是后端发来密文吧。

前端加密是个永恒的话题，只能防懒鬼不能防有心人。

不过有时候还是要看你的需求，毕竟不同的加密需求有不同的解决办法。

非对称随便弄一个就好了啊，私钥存服务器，公钥发给前端
公钥加密的内容即使被抓包也解不了啊，又没有私钥

场景交代的太模糊了，直接建议双向 https 吧，以保证双向信任和内容加密
就是每次打开你前端界面要贴证书才能访问

重要原则：只要代码写的足够复杂，别人就会懒得看🐶，从而增加了破解难度😂。随便搞个位移，base64 过一下 就能糊弄住很大一部分人了

->该字符串的实际内容不想被用户抓包察觉
rsa 加密一下就行了，只有有私钥的才能解密
同一个字符串公钥加密之后每次密文都不一样，谁也不知道内容是什么

这是个伪需求

简单点就是把加密过程的代码进行大量的混淆操作，增加了读代码难度，复杂点就是把加密工程用 wasm 封起来，毕竟反编译的门槛一下子就上去了。

这样加密的意义何在？

前端想加密数据有几种方法。

第一个学 chrome 的 CDP ，给每一个 JSON 传输数据包，都弄一个服务器来维护的自增长 ID 。也就是每个请求就算被黑客抓取到也没关系，服务器的验证 ID 随时在变化，没办法重放。

第二个学 HTTP2.0 的二进制协议，用 gRPC 来封装 json 数据，对于二进制加密。前端最大的弱点，在于数据都是明文，黑客看一眼就懂。如果是私有二进制协议，他还要花时间分析，还未必能分析出来正确结果。

第三是学 websocket 的 zlib 扩展压缩，就是客户端和服务器各维护一个动态变化的压缩字典，这样黑客获取获取中间一段数据也没用，他没有对应的字典能正确解压，也是百搭。

rsa 公钥只是加密。。。解密是私钥。

用公钥加密的东西，用户没有私钥，如何破解？

公钥加密，私钥解；私钥加密，公钥解

楼主说想在客户端加密，在后端解密；同时楼主又担心客户端用公钥加密的东西会被用户破解。我问，用户没有私钥如何破解。

公钥随便抓包啊，私钥在服务端，没有私钥拿到公钥也解不出来什么呀

又遇到了用 12 位密码保护 2 位数余额的场景了😂

防中间人，https 足矣；防用户，尤其还是 web ，做不到

对第一种情况，无论如何用户需要正常获取数据，黑客模拟此过程不是同样可以获取数据？

对于第三种情况，感觉与第一种相同，效果本质上是通过混淆前端逻辑增加查看源数据的成本。但似乎在调试工具下都无太大意义

另外关于 Lz 的贴条需求，局限在 js 范围内个人感觉无法实现。前端破解有很多专业户，单纯加密逻辑即使搞得很复杂，专业人员理顺可能甚至不需要很长时间

这问题在 V2 也讨论了很多次了。

上次讨论的结果是，前端加密一下，总比什么都不管，不加密要好。

也不能用静态密钥，不安全。需要算法来动态生成密钥，算法会频繁更新，让黑客没办法保存 JS ，也没办法反编译。都是服务器实时下发的动态脚本，必须联网才能获取。只要用户一直联网，就能限制访问频率和提高破解门槛。

现在网络安全要求很高，前端加密和后端数据库加密一样，也许很多人眼里看起来用处不大，但不能没有。安全就是一点一滴累加起来的。

根据题主的描述场景就是有一个字符串是前端生成的要传回后端，不让用户在 DevTools->Network 中看到原始内容，所以就是要把这个内容的 generator 加密或者说隐藏的深一点，感觉您说的都是防中间人的，或者说是防止爬接口的。

最近看到一些动态 js 的说法，很多前端加密公司都提到过，我没见过类似项目所以无法理解是怎样一种加密。一般来说，js 脚本核心数据交互功能还是向服务器请求或发送一段数据，而具体请求或发送的实现可以经过混淆让人无法理解传输的具体内容。不过按照你所说的话，黑客只需要保存某一时刻的所有传输信息，应该就可以解密当时刻下的代码具体行为，之后只需要在浏览器里对目标数据预先劫持就可以永远立于不败之地了，关于你说的让黑客没办法保存 js 我不是很理解

动态 JS 可以在原来浏览器 JS 的基础上，再运行另外一套 QuickJS 虚拟机，加密解密就是运行在虚拟机里进行，算法可以在服务器实时生成。

对黑客来说，虚拟机就是字节码，看不懂。字节码可以埋地雷，必须按照一定的顺序执行，这能一定程度防止恶意修改，提高破解难度。

由于密钥算法是动态的，随时在变。那么下发的虚拟机字节码，也随时在变。保存的 JS 算法会过期，自然也就没有保存 JS 代码的意义了。

大概理解了，意思是需要秘钥验证的场景，前端每次加密前都要向后端请求加密代码，而后端每次提供以不同逻辑加密的代码，使黑客即使解出单次请求的逻辑也无法复用。不过感觉上这个适合的应该是前端往后端发送数据的场景，对于接受数据保密的需求则无效。另一个问题在于，发送数据一般都需要通过基础设施获取，但 js 虚拟机我看到的一般是实现 es5 ，也就是说不管是 input 这类用户输入，或者从 navigator 这类基础设施获取数据，本身无法在虚拟机内部执行，如果获取后再输入的话，这个获取过程就很容易被预先劫持

是的，劫持确实是一个很大问题。

以前网上银行都要装一个浏览器插件，只靠原始 JS 绕不过去。

如果目标用户具备网络抓包的能力，那么从用户的技能水平上说，可以说，前端的加密手段应该都对用户无效。

很早很早很早微博是不带 https 的。所以他的登陆就是 js 加密。然后我就研究了 1-2 天，大概搞明白了什么个玩法。细节不好说，原理上就是制造一堆参数，用一定算法随机选择。然后，RSA 加密不是要公钥么？任何公钥可以用私钥生成。只是需要一些算法参数。这个就是服务端加密了吐回来的。然后再加密秘文。。我还照着实现了一个

其实我觉得吧，前端加密都是防君子不防小人，只要你的内容足够他有用大量的时间研究，就没有解不开的，所以前提如果是你的数据重要到绝对都不能让对方知道，你为什么要用 WEB 网页的方式提供内容。参考银行，证券，就是绝对不能随便被抓包拿到数据的。。。又想简单，又想安全。对不住，没有银弹。。如果只是想给破解者增加麻烦，套娃就是了，越复杂越好。。只要解密成本大于你实际数据成本，就没人干这个事。我干过最复杂的事就是，把硬件编号，每一个用一个不同的算法加密，然后最后结果再套 3 层不同 key 的加密。。而且整个东西是二进制文件，内存里本身就是加密的，只有在使用的一瞬间，从十个不同的内存快拿 n 字节的数据拼起来，再解密。。。。谁爱破解谁破解去吧，毁灭吧。。随便

直接 https 不就完了吗

我记得本站有个做 js vmp 的，有商业化产品，应该能提高破解难度。

他有句话说得挺好的

一说到保护安全的问题，大部分人想的是我们要 100%安全

我没有用过他的产品，所以不确定强度足够。但我相信只要是设计合理、强度足够的 vmp ，动态的 opcode ，正确的使用方式，破解起来还是没有楼上部分人说得那么轻松的。简单的办法：打开淘宝抓抓包，看看能不能很轻松就把每个加密数据分析出来。

这让我想起了 （ csrf 跨站请求伪造，一种网络攻击） csrf 的防御策略之一 csrf token 就是前端给后端发一个数据 后端凭此数据决定是否拒绝访问
tech.meituan.com/2018/10/11/fe-security-csrf.html＃前端安全系列（二）：如何防止 CSRF 攻击
就你这个问题而言，具体解决方案 很可能并不在于对明文的加密和解密手段，而在于发送的内容和约定的解密方式。最简单的保密例子是 你可以在发起端发十句谜语，在接收器端决定十句里的第五句谜语是真正起作用的谜语，那么即使在发起端（客户端）抓包拦截到 10 句谜语了 拦截者面对受混淆的信息 并不知道真正起作用的是哪一句，这是服务器端才知道的，那么是不是只要保证解密办法是仅有解密端知道的就可以了呢

IDEA Cipher: github.com/aleen42/IDEA

web 加密难道不是应该用 https 吗。。。

好多人在等着 OP 的需求场景，OP 哪里去了 😳

老哥 套娃 牛逼

只要套的足够多，就没人有闲工夫去一层层剥开

其实 99%的需求下，前端加密。
你以为的：抓包，拿到数据，把 js 代码整理一下稍微阅读，然后看加密逻辑，然后解密。
实际的：抓包，妈了个蛋，这货居然加密了。。搞不了搞不了。。逃了逃了。。。

这种方式没有什么用，只能防下小白用户

如果說需要加密一些敏感數據的傳輸，RSA 是足夠並且在 js 層面是無法破解的。但 RSA 畢竟是非對稱，有其局限性而無法對較大的 request body 進行加密，這時候如果只是考慮對付小白，可考慮 IDEA Cipher 等對稱加密。如果真考慮安全級別，就直接上 SSL 或者通過 worker 做本地端加密吧。