@murmur 哈哈我们公司那代码写的跟屎一样。 一行注释都没有 就别说文档了。 就这领导还要弄个 AI 编程助手呢 真的谢了。

kettle

这贴里让去大连理工的 都是程序员么？？
简直不要太搞笑。 计算机系 大连理工和北邮有可比性么。。

软考这玩意有啥用。。。

见过 姓由和姓信的

跟我们公司一摸一样。
老板觉得他看到你的日报，就能真的清楚你每天都在干什么了。。。。 简单天真

@renoooo 那你这是不可否认性的需求。 可以客户端本地生成密钥对，然后用私钥签名数据，公钥跟数据一起加密，作为数字信封一部分发给服务端。 服务端用他的服务器私钥先解开 数据密钥然后用数据密钥解出来数据和客户端公钥，客户端公钥验签通过后，再解密数据。 机密性、完整性、不可否认性的保护就都做了。
别问我客户端私钥怎么保护。。。。 你可以临时生成。 或者你用个 usb key 保护下？
密码保护这玩意 就是增加破解难度而已。

@XuYijie 其实就是生成个伪随机数而已。 对性能也没啥损耗，1 、起到了保护作用。2 、一次性密钥也不用费神研究密钥保护的事情。

服务端接收数据后，用服务端的私钥解密，获得密钥 A ，然后再用密钥 A 解密数据就好。

@XuYijie 客户端不用私钥呀。 你每次通信的时候 都是客户端生成的随机数作为 对称加密密钥 A ，这个密钥是个临时的，只对本次会话负责。 对称加密密钥 A 加密数据，然后用服务器的公钥 B 加密 A 就好了。把加密好的 A 和加密数据 一同发给后端服务。

一般单向 TLS/SSL 认证就够用啦，它来帮你做信道保护。
你用数字信封做个信源加密就好。 客户端生成个随机数作为数据加密密钥就够了。

不是这样的 如果加密数量量比较大的话，非对称加密的性能很差。
一般都是通过密钥协商出来一个对称密钥对通信中的数据进行加密。比如：
在客户端侧：客户端私钥+服务端公钥进行密钥协商
在服务端侧：服务端私钥+客户端私钥进行密钥协商。
协商出来的这两个密钥是一致的，你就可以当作是对称密钥来用。 在协商过程中。双方的私钥不见面，而且也不涉及到对称密钥传输的问题。
HTTPS 或者说 TLS 就是大致这么做的。
但听你的需求，你好像是想做信源加密。那你做数字信封就好。就是用服务端的公钥对数据加密密钥做加密，然后数据加密密钥对数据做加密，如果有防篡改的需求，也可以做个签名。

也有说不是 gpt4 会员有关

@pinylin 我也长春的没啥好企业 说下名字帮你排雷。。。

我很多男同事是因为不想回家带孩子 所以在公司加班。也不知道这孩子是给谁生的。。