求教，有没有一种绝对安全的密钥管理方案

[karashoukpan]

求教各位安全大佬，从安全角度来说，密钥似乎只能一层套一层解决？

有个场景：前端要给后段传递一个敏感值 称为 A 。

一种可行的解决方案是（已经开启了 HTTPS ）：

后段提供一个接口获取公钥（假设是一随机串），前端调接口拿到公钥加密 A ，得到 A+ 然后 A+ 给到后端用私钥解密。这样安全吗

[z7356995]

我觉得 https 就更安全了，解决了中间人攻击，再复杂就觉得是化蛇添足了

[jacketma]

没有。就算有一种绝对安全的方式，至少还要记住这种方式是啥。就像有人忘记密钥存在哪里了，只有天晓得了
最终还是必须要有一段信息靠大脑记忆、或者生物信息识别。

[fun201108]

看 https 的原理

[e3c78a97e0f8]

如果 HTTPS 安全，你这完全是无效操作
如果 HTTPS 不安全，中间人攻击后完全可以替换你返回的公钥，你也是无效操作

HTTPS 已经是安全的最优解了，任何其他操作都是重新发明 HTTPS

如果你真的很在乎安全性，可以加上客户端证书进行验证

[e3c78a97e0f8]

更正一下，TLS 已经是安全最优解，HTTPS 是 TLS 的一种常见应用

[pingdog]

CS/BS ，C/B 用公钥加密，S 用私钥解密
这……
防中间人？ HTTPS 就防了
防 C/B 篡改请求？直接 hook 替换加密前的文本，或逆向加密请求

[itechify]

没有绝对，防不住有心人

[facebook47]

前端加密，多此一举🤣🤣🤣有门槛，但没用

[unused]

一次一密的量子通信

[leo72638]

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

[seers]

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

[COW]

> 密钥似乎只能一层套一层解决？

实际上加密层数量并不是越多就越安全，密钥算法 != 加密层数量，如何选择密钥、如何存储密钥才是更应该优先考虑的点。

> 后段提供一个接口获取公钥（假设是一随机串）

公钥是和私钥根据算法一块生成的，不理解你说的随机串是什么

> 前端调接口拿到公钥加密 A ，得到 A+ 然后 A+ 给到后端用私钥解密

通常从效率考虑，不会用公钥去加密数据，而是用对称密钥去加密数据，公钥用来加密对称密钥

[Ketteiron]

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

[cppc]

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

[ZeroClover]

密码学第一原则：不要自己发明密码学

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

[Benjamin007]

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

[chinni]

没有

[wnpllrzodiac]

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

[Zy143L]

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

[michael2016]

结构化思考：
1.要弄清楚具体的场景，是点对点还是客户端对服务端 web 协议？
2.进一步方案：如果是点对点，用 HSM+KMS ，如果是客户端 web 协议，一般还是用 https ，