使用jCryption.NET无会话版传输加密密钥与加密数据是否安全？

先把jCryption的实际流程理清楚：前端先和后端握手，拿到后端的RSA公钥；接着前端生成一个对称加密密钥（比如AES），用后端的RSA公钥把这个对称密钥加密；之后用这个对称密钥加密登录表单数据；最后把「加密后的对称密钥」和「加密后的表单数据」一起发给后端。后端用自己的RSA私钥解密出对称密钥，再用它解开表单数据。

你担心的“密钥随载荷发送”，其实发的是加密后的对称密钥，不是明文密钥——这才是核心，安全性也体现在这里：

• 只有后端手里有对应的RSA私钥，中间人就算截获了加密后的对称密钥，也没法解密出真实的对称密钥
• 表单数据是用对称密钥加密的，没有对称密钥，中间人根本解不开原始的登录信息

那这种方式到底安全吗？分两种情况看：

• 如果你已经在用HTTPS：HTTPS本身已经完成了端到端的加密，jCryption这种额外加密属于多一层保障，但不会带来风险，只是没必要画蛇添足——HTTPS的TLS加密已经足够可靠
• 如果是HTTP环境：这种方式确实能避免登录数据明文传输，但有个致命隐患：握手阶段获取后端RSA公钥的过程如果被中间人篡改（比如把后端公钥换成自己的），那前端加密的对称密钥会被中间人解密，进而拿到你的登录数据。这种场景下，必须确保前端拿到的RSA公钥是可信的（比如提前把公钥硬编码到前端，而不是动态从后端获取）

另外要明确：jCryption用的是「混合加密」方案——用RSA加密对称密钥，用对称密钥加密大体积数据（因为RSA加密大数据效率极低），这是业内通用的安全做法，只要流程没被篡改，安全性是有保障的。

最后给个建议：如果你的服务还没升级HTTPS，优先做这件事，这才是解决传输安全最根本的办法，比额外加jCryption有用得多。

内容的提问来源于stack exchange，提问作者dstr