买了 BKT 的靠垫。。先对付用吧。

可以换个思路。
支付宝把地区改到旧金山、纽约啥的 国外地址，然后通过支付宝购买 apple 的礼品卡，再充值到 apple store 中。付款时就直接扣费了。

@cactusman 反正我昨天是怎么弄都安装不了了。

@wu67 确实被 ban 了。 断网、关闭安全守护、关闭安全监测都不好使。
最后没办法下载了小火箭。先对付用着吧。。

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

kettle

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

软考这玩意有啥用。。。

见过 姓由和姓信的

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

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

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

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

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

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