说个都没提到的点吧：每次发起下载请求前要获取有失效期限的 access token ，发起请求的过程中就可以对来源用户或 IP 做合法性校验（例如是不是重复请求该文件多次、是不是某个时间段内被异常大量的请求、IP 信誉或者 header 存在问题等等，甚至还可以在 js 侧增加 captcha 只有通过验证码的才可以继续执行请求 accees token 过程）

当然，这些可能需要你自己写 nginx 模块实现或者用 apisix 、kong 这类的可以容易实现插件的网关。

个别运营商确实会有某种屏蔽机制在使用。我用移动的 5G 访问不到美西的机器，联通就可以。

基本没见过这么大年纪的。以前有位 Intel 中国过来的最大年纪 40+的同事不知道突然去哪了

才发现有中文版，包含了 Moufiltr 示例，https://learn.microsoft.com/zh-cn/windows-hardware/drivers/hid/keyboard-and-mouse-hid-client-drivers

看了下文档 https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/keyboard-and-mouse-hid-client-drivers
https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/3rd-party-filter-drivers
https://learn.microsoft.com/en-us/previous-versions/ff542379(v=vs.85)

需要实现一个 MouFilter_IsrHook 回调函数，这个函数会在鼠标中断服务例程（ ISR ）被调用时被调用。
可以在这个函数中修改，例如，你可以让函数每隔一段时间只处理一次中断，而忽略其他的中断。这可以通过在函数中添加一个计时器，并在每次处理中断时重置计时器来实现。

理论上能实现，但是细节会很复杂。
但是我怀疑你这是 X-Y Problem 啊，话说你提到的 “一个 1000Hz 回报率的鼠标随便动动就能造成 20%的 CPU 使用率（ CPU：Core i7-7920HQ ” 你确定系统版本、厂商驱动什么的都很正常吗？或者其他什么原因？

CF 可以防御 3-7 层（ OSI 模型）上的 DDoS 攻击，无需人工干预，技术实力全球公认啊。在中国也不会差的，无非是价格问题了。

@Enzoliu CF 也清洗的，只是你通常见到的手段有个前置的人机验证环节（这步骤主要防 CC 攻击），让你觉得那么直接罢了。

没有贬损的意思，你确定二线城市的房价你能接/你愿意接？
我觉得，还是找个女朋友再定。有朋友在帝都工作把房子买到天津了，刚买 2 年就后悔了。
btw：现在接盘一二线城市的房产，35 岁失业了，换不起月供，岂不是芭比 Q 了么。

@hxndg “胡说八道的？恢复私钥？？”
你自己研究吧 https://www.instructables.com/Understanding-how-ECDSA-protects-your-data/#step14

@baobao1270 关于 4 ，你去了解下 Bluetooth 4.2 (LE Secure Connection) 就知道我的逻辑了。

Tor 目前没安全硬伤，有硬伤的是人，例如你在洋葱网络的黑市论坛注册了与 V2EX 上同样的 ID 昵称😂

以前用 Fabricator 协作过，所以都是 fabricator 上的 comments

以前有很多 Read it later 类的服务（部分支持离线阅读）。现在很少听到，怕啥因为需求太小众了？

对于 ECDH+AES 的方案，ECDH 可以用来生成一个共享密钥，然后使用 AES 进行数据的加密和解密。
这种方案的优点：ECDH 的密钥交换速度快，适合于需要频繁交换密钥的场景，而 AES 的加密和解密速度快，适合于需要大量加解密的场景。

ECDH+AES 的缺点：它需要两种不同的加密算法，这可能会增加系统的复杂性和实现难度。

关于对抗量子计算的攻破，已知道的是 ECC 在面对量子计算机的攻击时有概率会被破解。因为量子计算机的构建和实现还在初级阶段，重点是：目前还没有量子计算机能够实现大规模的量子比特控制和稳定性。
因此，如果一个大规模的量子计算机能够实现，并且能够破解 ECC ，那么 RSA 的破解也就不会远了 1 。
微软的研究团队正在研究如何使用量子计算机来破解 ECC ，他们发现，要破解 ECC ，需要的量子比特数量是 RSA 的 6 倍。

针对你提到的“看来各位对密码学都有一定的误解。建议去把 HPKE 的 RFC 仔仔细细读一遍”
我也给你找点反例吧：
1. 性能问题：每次连接都需要进行密钥交换，💡这会增加加密和解密的计算开销，特别是在资源受限的设备上，例如轻量级的物联网设备

2.安全性问题：尽管 X25519 算法在理论上是安全的，但在实际应用中可能存在一些问题。例如，如果在密钥交换过程中随机数值泄露，任何知道该随机数值的人都可以使用该随机数产生签名值恢复私钥。此外，如果同一个用户对两个不同的消息签名时，采用了相同的随机数，则任何人都可以通过两个签名值恢复出私钥。怎么实施保护性措施？
💡除非你假设 OP 一定会科学恰当的使用现代成熟的 TLS 方案。

3.兼容性问题：使用 X25519 算法的设备可能与使用其他加密算法的设备不兼容，这可能会限制它们的互操作性。💡除非你假设了 OP 无所谓自己的学习曲线、也无需考虑后续入方的接入成本。

如果愿意付费的话，inoreader 定制版功能有 [你与同事的每日邮件摘要] 的功能

假如 QPS < 100 ，加解密底层实现是基于 C/C++ 的，盲猜 2c4g 配置够用。

@raw0xff
一定程度是正确的，但是严格的讲是有现实隐患的：
首先,你忽略了一个重要事实,就是私钥泄露可能会带来严重安全问题。如果一个节点的私钥泄露了,攻击者就可以假冒这个节点,这对整个系统的安全都造成威胁。攻击者可能会伪造消息或者修改已经存在的消息,从而影响系统正常运行。

其次,即使数据本身是明文,私钥泄露也意味着攻击者可能会试图窃取或者修改这些数据。在某些情况下,这可能会带来严重后果,比如如果数据包含用户个人信息,那这些信息就可能泄露。

最后,你忽略了私钥泄露不仅意味着一个节点的私钥泄露,更可能会导致更多私钥泄露。比如,如果一个节点的私钥泄露了,攻击者就可以利用这个节点获取其他节点的私钥。到时候攻击者就可能控制整个系统了。