@jianglibo 首先咱得把名词对齐一下，自签发证书指的是适用自己的私钥签发自己的公钥 CSR 变成证书，CA 通常指的第三方授信机构 GlobalSign 等签发的证书，你说的内网签发也是 CA ，只是不是第三方授信 CA ，这个场景下你是默认了内网 CA 可信。然而对于常规 openpgp 来说，交换的是第一个里边自签发证书，这个是没办法抵御 MITM 的，毕竟随便中间人做了一个证书，你没有其他第三方或者手段来确认证书和人的关联性，所以我在上边的回复里说了，要么线下面交，要么通过 CA （不论是第三方可信还是你内部可信）。目前的公钥分发网站，我要是没记错的话是不验证可信的，最多确认完整性。如果这些公钥分发网站要验证可信性那就自动变成 CA 了。所以回到最开始，openpgp 可以做到双向或者多向的点到点加密确保机密性，但是用户可信性这个事情，要么线下要么 CA 这个是没法回避的。所以如果你只想解决机密性，线下面交对称密钥、分途径交换密钥分量、甚至口头协商密钥派生规则都可以做到，不需要 openpgp 甚至还比 openpgp 简单。如果你要解决可信性，上边我也提了，目前的常规做法就是 CA 。我一直想有一个完善的不基于 CA 的可信方案，但现在能看到的有一些论文，还没有落地到产业接受的程度。

@jianglibo 我司内部就是强制使用 thunderbird 配合 openpgp ，对外和客户（ IT 类技术人员、金融类业务人员都有）联系也推荐用 openpgp 加密邮件，或者至少加密附件。从我入职开始到现在也每天使用超过 12 年了，接触的客户数量也有 200+了，我觉得我有一点说服力。
简单来说，openpgp 这一套体系就是太复杂了，我哦们有完善的配置手册，一步一步带截图具体怎么配置，软件更新也会更新配置手册，就这个前提下，上述那么多客户，首次配置好之后把私钥发给我的占比至少 80%以上。好容易正确生成了公私钥对，加密发送文件的的时候不添加我的公钥的占比能超过 90%。首年记住了怎么操作，后续年度还得电话再指导的至少也能有 30%起。这个是外部客户的场景，而且其中懂基本加解密知识的也不占少数。我司内部，每年需要我协助配置密钥对、thunderbird 、公钥组、邮箱组等的同事也得有 30%以上。我们可是要求每两年就重新配置一次的，就这个频率都不能确保每个人熟悉的掌握配置方式。
原因是什么，上边有人也提到了，公私钥对为基础的 PKI 方案，为了做到可信，要么两人当面交换公钥，要么用 CA 做中心交换，除此以外都不能做到可信这个要求。即使是公开的公钥服务器，只要没有可信方签成证书，那么都会受到 MITM 的影响。当然了公司自建中央公钥服务器会好一点，但是内部使用的问题解决了，怎么解决对外的要求呢？所以国密整出来 SM9 一人一证书的想法，直接中央到“中央”可信。
另外既然 OP 提到 openpgp 了，我姑且认为你也了解 SMIME ，以 SMIME 的简单尚且不能做到大规模推广，openpgp 这种大量涉及到基本知识和技术操作的方案怎么可能会让人用得起来。
如果往更广的方向来说，怎么能在没有中央 CA 的基础上解决双向或者多向互信，这个是下一代加解密基础设施需要解决的问题之一，也是国内不想让解决的一个问题。原本的区块链体系似乎解决了这个问题，但是目前大家的着眼点都在币上，这个底层的方案一直没有一个有效且易用的技术出来。

去年因为各种原因用过一次，环境是 arch ，命令如下：
`docker run --rm --device /dev/net/tun --cap-add NET_ADMIN -ti -e PASSWORD=xxxx -e URLWIN=1 -v $HOME/.atrust-data:/root -p 127.0.0.1:5901:5901 -p 127.0.0.1:1080:1080 -p 127.0.0.1:8888:8888 -p 127.0.0.1:54631:54631 --sysctl net.ipv4.conf.default.route_localnet=1 hagb/docker-atrust`
参数说明参考： https://github.com/docker-easyconnect/docker-easyconnect

没有明确爱国需求的话也可以考虑 dell 的笔记本，对 linux 的支持很好，我之前的 22 年 inspiron 14p 一直在用 arch ，没有任何驱动之类的问题，并且还有一定的扩展性。唯一问题就是至少直到 22 年为止的 win/linux 笔记本，电池都做不到正常使用 4 个小时以上。所以如果里的需求是电池，那么没的选就上 mac 吧。
不过我干杂活，写代码但不多，现在 m 系列的 mac 本地使用 clang ，如果使自己写的代码还好，如果是用别人的代码，要注意 clang 和 gcc 的一些细微区别，或者单独安装配置 gcc ，这个挺烦的。
至于终端，我用 warp ，好多时候忘了的命令或者懒得搜的时候就直接在终端里问了，它也能直接写好命令让你确认，比较省心，类似预装的 gemini cli 吧。只是现在免费额度越来越少。
最近刚从 dell 的换到便宜的 M4 air ，十年前用过十年的 mac ，实话说界面什么的变化虽然大，架构也从 x86 变成了 arm ，但是体验基本和之前是一样的，不像 arch 能调整的非常跟手，但也没有 windows 那么耗资源。

可以考虑用 resticprofile ，直接在配置文件里指定 schedule 就可以了，我本地已经稳定运行两三年了。

如果你需要在打开窗口的快速文件夹跳转，尝试 listary 或者 flowlauncher
如果你需要插件生态，尝试 flowlauncher 或者 raycast beta
如果希望和 mac 平台统一，那就 raycast
如果不想装第三方，那就 powertoys 自带的 command palette
如果不喜欢 alt+space 打开，那就 listary ，可以双击 ctrl
其他的相比上边基本没有显著特点了。

rustdesk 在 wayland 环境下不能无人值守。比较可行的做法，要么是直接端口转发直接 rdp 客户端连接到 krdp ，要么是通过 tailscale 或者 zerotier 等虚拟组网，或者 vpn 回去之后 rdp 连接。krdp 我没深度使用过，但是 gnome wayland 下的 rdp 服务器是可用的，但也仅仅是可用而已。如果实在有非常高的远程桌面的需求，目前建议还是上 x11 。
所以我现在的解法是 windows 机器加移动硬盘 vtoyboot 到 linux 环境...

从疫情元年到现在我用 unraid 已经 5 年多了，除了 smb 速度是个最大的问题，其他方面我还没有遇到过问题。网络部分我用 r5s 独立了主路由+翻墙之类的功能，除此以外 30 多个 docker 和 2 个虚拟机都是架在 unraid 上，硬盘没做 raid 因为比较乱，一个 4T 的 nvme 做 cache ，一个 12T 做主存储，一个 4T 和一个 2T 做备份，通过 user script 把主存储上的重要数据定期 rsync 过去，平时都是停转状态。
飞牛之类的之前试过，但是他的功能都能有 docker 替代，因此没有长期去用。不过如果都考虑用飞牛了，直接底层 pve 就得了没必要上 unraid 。我没上 pve 的主要原因就是 unraid 买的早...

im 类的端到端加密，请搜索 gpg 的 email 实现机制，或者 smime 的实现，都是类似的。
简单的逻辑，个人到个人的场景下各自交换公钥，通过公私钥协商会话密钥，会话密钥加密消息体。群组消息的话，首先随便一方生成对称密钥，使用组内所有人的公钥分别加密对称密钥放在消息头，每个人拿到后用自有私钥解密，然后解密消息。
群组这个思路是相当早年看到的，不保真现在 gpg 是不是还这么干。
至于你说的 4 位数字，我没用过 x 的 app...确定不是身份验证用的？也有概率是用来派生对称密钥然后解密私钥。

我们办公要求用 thunderbird ，但是手机端我装的是 canary ，自带 gpg 工具，不需要像 thunderbird 额外装 openkeychain 。而且总体颜值比大部分邮箱类软件要高，除了付费......我是早年的付费用户，当时非常便宜，现在似乎贵了不少。

@WngShhng 你看啊，如果你不考虑认证要求，不考虑最佳实践，那你的应用不论你想怎么实现都可以。现在的问题不是你想让大家认可你这个 RSA 的实现，那对不起至少我不太认可。
如果你的出发点是 android 的安全性，可以考虑调用 TEE 去做密钥相关处理，这也是最佳实践的做法。如果你连 TEE 的安全性都存疑，可以考虑不支持 android 只做 iOS 。但是不论如何，你希望说明你的 RSA 服务器实现的安全性高于 TEE ，那至少你得从各方面都给出来做够的说服力，而不是仅仅重复“Android 本身并不安全”，因为国内几个手机的 CC MDFPP 认证也是我做的。
自己实现一套机制没问题，我也经常会帮客户想一些奇怪的思路，比如白盒加密之类，但是不代表这些方式是足够安全的，只是在接受了某些风险的场景下可用。对于你现在的应用场景，是不是你得先想明白到底需要应对什么风险或者安全问题，然后才去看你的实现机制是不是足够的？

@WngShhng 想突出端到端就不要加服务器，忘了就忘了，或者参考 bitlocker 提供离线的恢复密码的助记码之类的方式。如果一定要做 RSA 且服务器保存，那么至少参考上边几楼的说法，做好身份认证之类的事情，比如额外引入 CA......

怎么说呢，我先摆资历来增加说服力，国内的 FIPS140-2/3 认证，基本都是我做的。如果有做过认证的或者关心过认证的，应该就知道我是谁。
当然你的产品不做认证前提下，随便怎么开发都没问题，但是如果你希望哪怕参考一点所谓的“最佳实践”，你就会发现那个“大神”说的大差不差。语气问题可能以下我也有，见谅。
端到端加密没有一个准确的定义，但是按照常规的实现思路来说，“没有第三人持有任何可用于解密的材料”这个应该是共识，那么按照你现在的做法引入一个 RSA 公私钥做加密，私钥在你的服务器侧用作密码恢复，先不提所谓的算法安全强度的事情，至少你说端到端这个就不准确了。这里不讨论 RSA 用于加密的一堆要求，也不讨论怎么身份认证的事情，就单纯存在一个中心点可能会解密密码这个场景，作为明确有端到端需求的人可能就不选了。
其他的问题，诸如 KDF 密钥派生算法，常规的方式都是考虑把密码作为 PBKDF2 的输入，提高 iteration 次数到 10000 以上，然后用派生出来的密钥作为 AES 密钥使用。AES 的 IV 要看使用场景来判断长度和生成方式，通常来说至少是随机数 96 bits 以上。在做到这些之后，你怎么做拼接 base64 之类的都无所谓。
我们都能理解不要自创算法的重要性，但同时正确使用算法，正确的组合算法也相当重要。

@faywong8888 endeavouros 在用，作为日常桌面使用快 5 年了吧。这个发行版就是原始的 arch 加上一个 gui 安装器和一些定制的桌面主题，可以略微节省一些安装时候的配置时间，仅此而已。

如果你是考虑合规需求，那么 SHA-256 加盐的任何用法基本都是能满足要求的，除非国密强制 SM3 。如果是海外合规相关，上边有人提到 argon2id 以及 bcrypt ，相比 SHA2 系列算法的“合规”风险更高，因为有些审核机构会指定要求 FIPS 许可算法。
如果你只是单纯考虑安全性本身，无脑 SHA-512 就可以。首先 SHA-512 和 SHA-256 可以简单认为不是一个算法，其次 SHA-512 的算法安全强度是 256bits ，而 SHA-256 只有 128bits 。参考 SP 800-57 即可。

赞同楼上两位，我是 r5s 跑 openwrt ，启用了 openclash 翻墙、adguardhome 做 dns 和禁用广告、kms 来激活内网 windows 和 office 、ddns 到 cloudflare 解析、vpn 和 tailscale 都是用来回内网，剩下服务类的都在 nas 上 docker 部署。平时非常稳定，我可能想起来的时候会手工重启一次，通常两次想起来间隔都在 2 个月多吧。

@ouqihang 是的，这个就是根本原因之一。为了解决这个问题，海外的做法是直接打包成保险。反正为服务付费这个事情海外是比较能推的开的。国内的做法是，尽可能从源头杜绝（各种风控），如果实际发生了，也有保险...但是想让大多数人为了潜在的风险多付费是不可能的。

@dilidilid 这么说吧，端侧我不担心，我自己就做端侧的各种合规认证，安卓上指纹一定走 tee ，面部大概率不走 tee ，ios 都走...另外端侧都是自己主动注册，特征值保存在端侧用来匹配。
不过支付宝的刷脸支付终端，我不认为每个人都需要在终端上注册面部信息，那这个时候是不是可以理解为面部特征在支付宝有存储？掌纹同理。我不担心支付宝和财付通对数据存储的安全性，但是出发点是方便支付这个，我认为没必要给出来面部和掌纹特征。

@dilidilid 至少不需要指纹面部和掌纹啊...SSN 当然是实名，除了上边说的这几个信息之外，SSN 也没那么容易关联你的社交关系和购物习惯，所以实际上从风控的角度，我是觉得支付宝和财付通做的能比所有银行捆上 cybersource 以及 worldpay 都要好的。当然就像我上边说的，因为你自觉不自觉的提供了大量的实名信息，所以做的好是应该的。