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 都要好的。当然就像我上边说的，因为你自觉不自觉的提供了大量的实名信息，所以做的好是应该的。

@sjqboss 那哥们总体说的没太大问题，细节上有出入。现在很多银行可能日终结算或者签约每月结算，结算的时候就已经收到款了，但是在商户入网的时候是会收保证金的，而且有一堆罚则可以从保证金里扣款。另外如果是 visa 的收单机构，还会有更严格的 GARS 要求对入网商户的监控和过滤。不能说卡品牌不关注盗刷，只能说确实因为几十年的系统使用下来，目前的无卡支付方案在非大陆地区是最理想的方案。当然现在也在不停地往上打补丁，EMV 是第一代补丁，3DS 是前几年的补丁，MPOC 方案是近几年以及短期未来的补丁，长远来看可能还有其他补丁，这些都是在现有三方/四方支付的基础上在增强无卡支付的安全性和便利性。
但是，你要说这套系统和支付宝财付通相比较哪个更好，我只能说没办法直接比较，就好比说烤鸭和烧鹅哪个更好吃一样。不同的信任体系，不同的技术架构，不同的资金方案，目前看来是双方在用户感知层面越来越靠近（卡片 -> NFC / 二维码 -> NFC ），不过底层架构、用户架构、资金架构上都不一致。
说回到楼里那么多不信任国内行拒付的，我用信用卡接近二十年，肯定不是论坛里时间最长的，内卡外卡我都有，国内海外线上线下我也都刷，甚至早年的压卡支付我都用过，这些年来盗刷的总计不会超过 10 笔，都拒付掉了，并且没有超过两次电话的，从不扯皮，包括招行、中行、交行。国内可能会以信用卡设置了刷卡密码密码为由拒绝拒付，不过我确实从不设密码，另一方面即使设置了密码，走金管局投诉应该也是可行的，只要你能证明这比交易确实不是你做的。3DS 我也没开过，就是传统的卡号有效期 CVV2.
反过来再说支付宝财付通，确实至少我从没遇到过“盗刷”的情况，不过代价当然就是为了做到“足够的安全”，你需要全套实名的活在他们的风控系统里，甚至远超实际需要的实名信息。
再次但是，不论是卡品牌、收单行、发卡行、蚂蚁、腾讯，这些机构在做风控时候的最后依赖都还是保险......赚钱嘛，这没什么可丢人的 2333333

非常感谢！！！作为我的 console 之类的等宽字体使用已经快两年了

我用 timewarrior ，不过没有一个好看的 bashboard 或者 report 。只是自己关注趋势的话足够了。

搜索关键字：CSP 、SRI ，看看是不是你需要的。这两个技术目前在有些信息安全相关认证方面是强制要求的。

这个怎么说呢，首先碰一碰和闪付、quickpass 、applepay 以及各家手机 pay 的原理是不一样的，只是都走了 nfc 通信而已。
闪付、quickpass 、applepay 以及各家手机 pay ，实际上是使用手机 nfc 模拟了一张银行卡，在支持 nfc 的 pos 机上是作为银行卡出现的，里边存了你的卡号（实际是虚拟的 token ）以及各种银行卡相关信息。支付的时候是 pos 机读你的手机（银行卡），然后 pos 机发起交易。地铁卡的交易流程一样，只是收单从银行变成了地铁而已。所以这个时候手机 nfc 可以设置为“只读”，因为就是一张卡。有些手机还支持关机读卡都是一个道理，没有哪个银行卡带电池。
碰一碰，实际是使用手机 nfc 模拟了 pos 机的 nfc 读卡能力，贴在那里的才是卡片。所以首先手机 nfc 设置为只读是没用的，你不能拿一张银行卡读取另一张银行卡。其次发起交易是手机 app 来执行的，这也就是为什么各种 pay 可以不用电量或解锁手机，但是碰一碰不只需要解锁还要打开 app 的原因。但是另一方面碰一碰的贴纸原理上应该和二维码类似，只是商户号或者额外的一些信息，没有任何敏感数据，也就不会因为使用碰一碰带来任何额外地安全隐患，因为他就是把“摄像头扫二维码解析商户号”变成了“手机 nfc 读贴纸获取商户号”这么个流程流程是安全的，那么碰一碰也是。
不过这个在教育用户使用 nfc 方面是个挺大的进步，至少在一二线城市，正常的各种 pay 支付要比二维码方便，一样不用带银行卡只要有手机就行。