@raw0xff 我记得 WSS 就是 WebSocket over TLS 啊，还是我记错了……
AD 是输入法打字被吃了，指的是 AEAD

其实我们讲这么多，都是密码学方案和算法的问题。大家都离题万里，其实楼主要的也是一个可以实行的方案，这里楼主出一个吧：
X.509 ECC (secp256r1) 证书 + TLS 1.3 双向认证，密钥直接保存在文件里

下面是对方案的解释：
1. 楼主想要用 ECC Keypair ，那么就选 secp256r1 吧。从代码可维护和减少编码工作量的角度考虑，建议复用现有格式，也就是 X.509 证书。自己用 openssl （或者其他你喜欢的加密库）自建一个离线 CA ，然后给客户端/节点发证书就行。
2. 通信协议方面，个人建议 TLS 1.3 。楼主喜欢 WSS 的话也可以用 WSS ，和 TLS 安全性差不多。TLS 1.3 目前所有的 cipher 都是安全的，只要禁用 TLS 1.1-1.2 即可。如果有必要可以开双向认证。用现有协议而不是。WSS 相比 TLS 1.3 的好处是可以走 CDN 。此外，如果楼主还没有决定序列化方案的话，gRPC 也是很不错的选择。
3. 鉴于你的成本，KMS 就别想啦。用云服务器的话是不可能「安全存储密钥」的——只要云服务商想看就能看。阿里云有卖带 TPM 的云服务器，但是也是贵的离谱。真要做什么的话，你可以在创建服务器的时候勾选「加密磁盘」，至少如果放你云服务器的物理机磁盘被偷了不会导致你的私钥泄露。不过轻量云好像不支持加密磁盘的功能。私钥安全性也不会有什么磨损，不泄漏就行。

@GeekGao 其实楼主的问题只是问个可以实操到加密通信方案，结果被我们话题歪到密码学原理去了。或许这就是论坛有意思的地方吧，让我看到思维碰撞的火花（
此外某小飞机的算法算不上高明，比起 Reality 来说设计的失误还是挺多的，Reality 可以说是「源于 TLS 1.3 ，高于 TLS 1.3 」了

@raw0xff #33 TLS 主要是实现 Forward Security ，也就是假如有一个中间人捕获了你的通信，虽然无法解密但是依然保存通信的内容。万一有一天你的私钥泄漏了，如果没有 FS ，那么中间人就能解密你的所有通信；如果用了 FS ，那么就只能解密未来的通信（如果你没有更换私钥），无法解密过去的通信。

TLS 实现 FS 的方式就是 ECDH ，如果你能使用「正确的方式」进行 ECDH 的话，那么自然不需要使用 TLS——但是鉴于大多数人实现密码学的方式都容易犯错，因此「建议」使用 TLS 。

@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 拍手称快了。

试试抓 CRX 下来手动安装？

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

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

CZ 我猜测是 CNZZ 的缩写

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

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

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

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

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