@GeekGao @hxndg 看来我们遇到了一点自然语言表述不清的缺陷。我说的「随机数」是 TLS 1.3 ClientHello 中的随机数，它是用来参与后期 KDF 的，会明文发送，自然不可能用来恢复私钥。你说的「随机数」是用来生成 ECDHE Key Pair 的随机数，这个自然是需要保密、并且保证抗时序攻击的。
此外，我看了 BLE 的标准，其实和 TLS 是一样的——先用 ECDH 交换密钥，然后用 KDF 生成对称加密密钥，最后用对称加密算法 (RC4/AES) 进行加密通信。所以不可能只依赖 DH/ECDH ，也不可能只依赖对称加密，必需两者结合使用。

@gjquoiai 不一定要用 ECIES 吧，其实说到底还是一套 DH + Symmetric Crypto + AD 的 Hybrid Encryption 方案，TLS 、BLE 、ECH 都是自己实现组合而不是依赖 ECIES ，ECIES 只是一个通用的、被证明没有太大安全漏洞方案吧。

@raw0xff
不是叫你换 x25519 ，只是叫你换一个 ECDH 算法——x25519 只是目前最火的。ECDH 和 TLS 没有关系，ECDH 是算法，TLS 是实现。但是建议你使用 TLS ，因为自己去实现密码学相关的东西很容易出错。现阶段没有必要考虑 PQC 。

@GeekGao
1. 性能问题：说到底还是 trade-off 。ECDHE 主要还是为了 PFS ，个人认为物联网设备建立连接并不是一个非常频繁、需要并发的场景，即使建立连接慢一点其实也无所谓，同时由于 ECDHE 参数在 TCP 连接建立前就算好了所以也不会给服务器造成负担。个人觉得用这个换 PFS 是值得的。
2. TLS 中随机数本来就是明文传输的，至于为什么去看 ECDHE 的原理。「同一个用户对两个不同的消息签名时，采用了相同的随机数」，不可能，至于为什么去看 AEAD 的原理。
3. 「使用 X25519 算法的设备可能与使用其他加密算法的设备不兼容」——首先，如果你的设备和软件都是新的，那么完全可以直接上 X25519 。其次，X25519 只是 TLS 选用 ECDHE/DHE 算法之一，你也可以选择其他的 ECDHE/DHE 算法。遵循标准 TLS 1.3 协议的客户端和服务器，应该支持 TLS 1.3 所规定的大部分算法。最后，我也没有说「一定要用 X25519 」，如果 OP 选择了一个成熟的 TLS 库方案，那么自然说是库支持什么就用什么，只需要排除不安全的 chiper 即可。
4. ECDH 是密钥交换算法，AES 是块加密算法，是不同的领域：ECDH 只能用来协商密钥，而 AES 只能用来对称加密，必需两个结合在一起才能组成完整的加密通信协议。感觉你 #18 写的东西没有逻辑。

我不喜欢大公司的浏览器
ungoogled-chromium 或者 Firefox 更合我胃口

@GeekGao
@raw0xff

看来各位对密码学都有一定的误解。建议去把 HPKE 的 RFC 仔仔细细读一遍。总的来说：
1. 现代的加密手段不再使用固定的公钥/私钥对，也就是很多 HTTPS 科普中「使用证书的公钥/私钥来加密/解密」已经是错的了。现代的加密机制，每个 connection 都会进行一次独立的 DH/ECDH ，目前最快的算法是 X25519 。
2. 为什么要 AES 进行实际的加密/解密，而不是直接用公钥/私钥？因为慢。即使 ECC 比 RSA 快，但是和 AES 比仍然有十倍左右的速度差距。如果你的设备以嵌入式为主，CPU 没有 AES 加速功能，建议使用更快的 ChaCha20-Poly1305 算法。
3. 在进行加密通信时，永远使用 AEAD 而不是单纯的 AES——如果决定使用 AES ，必需使用 AES-GCM 模式；如果不使用 AES ，建议使用 ChaCha20-Poly1305 算法。
4. 现代的 TLS 流程：ECDH 交换随机数->用 HKDF 从随机数派生 AES/Poly1305 密钥 (此时服务端握手已经完毕) ->服务器用证书私钥签名发送给客户端 (发送的证书已经用派生密钥加密)->客户端验证证书 (1.5RTT 握手完成) -> 进入 Application Data 通信模式
5. 对于运行在云上的设备，KMS 永远是最好的存储密钥的方法。对于本地设备，建议使用 TPM/HSM ，其实 FIDO2 密钥也能当 HSM 用。

想要玩的爽 肯定是 8 Pro
个人感觉性价比是 7 Pro 最高

@yuanmomo 其实与其说是适合国情，不如说是适合风投比较多的国家。在中国和美国，搞技术的其实都应该懂点商业和运营，毕竟美国很多一心搞技术的不是融不到钱、就是创始人被踢出董事会。不只是瑞典，感觉整个欧洲的风投都不多，所以一心搞技术的就够了。

@Mqzo 「老师活人没见到」，学校应该有 catlog 吧，可以看看老师的 Email 给他发邮件问问试试看。讨价还价不至于，我觉得问问其实无伤大雅，你可以把你 X1 Carbon 的 Specification 发给老师看看。
网卡外接，Wireshark 不一定能抓全，如果涉及 Ethernet 层的实验，那么需要走 PCIe 且支持关闭 Offloading 的网卡。
其实你开学再买也来得及，主要是会错过现在黑五，到时候买就贵了。

你现在的 Thinkpad 不是已经满足了吗
个人感觉 Network 相关的专业，主要还是要抓包，所以需要一个混杂模式的网卡，其他对电脑应该没什么需求。按理说 i7/16G/1TB 这些要求，都是和专业无关的，感觉是写需求的人为了写而写的
话说学校是在美国吗

用户的性情总是喜欢折中的调和的，譬如说你想要只支持 Chrome ，大家便会说你不支持 Firefox 不好。但你要给他们的电脑装个 Electron ，他们便会为 Tarui 拍手称快了。

Apple Pay 和 App Store 不是同一个东西

试试抓 CRX 下来手动安装？

大概是 HTTP Meta Tag 的区别，Apple 设备的 icon 需要单独标注

作为一个经常听国内独立音乐的，只能说很难离开网易云了
这个超清母带吧，其实是假的，是 AI 根据原音频生成的

CZ 我猜测是 CNZZ 的缩写

@kid1412621 前面的字母是航空公司代号，而且不一定是字母，比如春秋的代号是 9C

@M003 你说的这个规则是 90 年代的了，现在航班号是航空公司内部随便排的，只有前面的代号是不变的，只不过大家习惯了去程和回程差 1 位

@kid1412621
@M003 国际航班现在也有可能有第二位数字

醉后不知天在水 满船清梦压星河
从中摘了几个字出来 译作 Skylake-Dreamliner 这是我家各种 Linux / OpenWrt 设备的主机名

「钥匙串访问」，如果你有 Mac 设备可以清除掉，是随 iCloud 同步的

你甲骨文面板里 网络 ACL 放行了吗？看看 VPC 默认规则？
最近甲骨文网络质量变得很差，也有可能有影响

感觉楼主的思路还是挺不一样的，相当于是把证书服务做成了 SaaS 。CNAME 免授权的功能 acmesh 其实也有，只不过终究还是需要一个自己的域名——而楼主想的云服务化方案就替用户省下了这个烦恼。但是这条路在国内想要商业化，难走啊。

感觉楼主其实选错了 market segmentation——或者说，为什么 acmesh 没有部署到 CDN 、到 Load Balancer 的功能？其实 acmesh 可以自定义 Deploy Hook ，但是官方不实现其实还是因为需求不足。这些功能其实企业用的更多，大企业又不喜欢用 ACME 更喜欢付费证书，而做成云服务也不讨 Geek 喜欢，所以楼主的市场就很小了。我看到楼主的定价是只要更新证书就收费，那么必然导致很多人觉得「那我还是用免费的 acmesh 吧，让 AI 写个部署到 CDN 的脚本也不难」。想要吸引新用户，还是建议做点 promotion ，最好是有一点免费额度。

接下来就要指出楼主的问题了。第一个是技术方面的：「 OHTTPS 会在每天的凌晨 1 点左右运行证书自动更新、部署及监控服务」——这一点希望楼主尽快修改。很多客户端都选择在 UTC 0:00 更新证书，对 LE 的服务器造成了很大的压力，LE 也在自己的官网请求客户端作者用随机算法，将流量分摊到一天的不同时间。目前主流的客户端都跟进了，因此还是建议楼主也进行跟进。

然后是广告措辞都部分，Let's Encrypt 本身并不是「顶级证书机构」——它本身不是根 CA 。「免 DNS 授权自动化」也不是您的「首创」，这样的宣传有违反广告法的嫌疑。