https://laisky.notion.site/How-Hype-Will-Turn-Your-Security-Key-Into-Junk-ac50dfbc44354bdfab17ef76e72ece13
非常不错的文章，介绍了目前 passkey 领域可能正在走的一条歧路。
补充：关于 yubikey 是什么，以前写过一篇文章 https://blog.laisky.com/p/yubikey/
众所周知，FIDO、WebAuthn 等正在推动 passwordless，也就是放弃让用户记忆 password，转而采用 security key 等固件来实现无密码身份认证。
除了 yubikey 等专用设备外，各类内置加密芯片的 iphone、android、mac 等设备也可以集成 passkey。
但是 passkey 的具体实现上，存在 resident key/non-resident key 两条路。简单粗暴的概括下就是：
* non-resident key 方案：仅需要 security key 设备持有一对公私钥，就可以对接任何服务端。缺点是需要用户输入用户名
* resident key 方案：需要 security key 设备为每一个服务端记录一对唯一的公私钥，优点是用户不需要输入用户名和密码，缺点是对 security key 设备的要求高了。
android passkey、icloud keychains 这种依赖加密芯片的软件，可以支持存储无限多的 resident key。但是像 yubikey 这样的廉价专用硬件，其能存储的公私钥对（slots）是有限的，往往只有 5～20 个。
所以如果 resident key 方案成为主流，实际上 yubikey 等设备相当于就被挤出市场了。这违背了 WG 当初声称的“可以支持所有用户设备”。
Ps. 会搬运整理一些以前发在 X 的资讯贴到这里，方便归档索引。
next: https://t.me/laiskynotes/163
非常不错的文章，介绍了目前 passkey 领域可能正在走的一条歧路。
补充：关于 yubikey 是什么，以前写过一篇文章 https://blog.laisky.com/p/yubikey/
众所周知，FIDO、WebAuthn 等正在推动 passwordless，也就是放弃让用户记忆 password，转而采用 security key 等固件来实现无密码身份认证。
除了 yubikey 等专用设备外，各类内置加密芯片的 iphone、android、mac 等设备也可以集成 passkey。
但是 passkey 的具体实现上，存在 resident key/non-resident key 两条路。简单粗暴的概括下就是：
* non-resident key 方案：仅需要 security key 设备持有一对公私钥，就可以对接任何服务端。缺点是需要用户输入用户名
* resident key 方案：需要 security key 设备为每一个服务端记录一对唯一的公私钥，优点是用户不需要输入用户名和密码，缺点是对 security key 设备的要求高了。
android passkey、icloud keychains 这种依赖加密芯片的软件，可以支持存储无限多的 resident key。但是像 yubikey 这样的廉价专用硬件，其能存储的公私钥对（slots）是有限的，往往只有 5～20 个。
所以如果 resident key 方案成为主流，实际上 yubikey 等设备相当于就被挤出市场了。这违背了 WG 当初声称的“可以支持所有用户设备”。
Ps. 会搬运整理一些以前发在 X 的资讯贴到这里，方便归档索引。
next: https://t.me/laiskynotes/163
踩了个小坑，我有一台廉价的 storage VPS，系统是 ubuntu 16.04 + 2.6.32。这台机器上我跑了一个 minio + nginx + tailscale 当 s3 用。配置非常差，我一般懒得登上去。然后我家里的台式机上也有一个 minio 作为 replica，这个 minio 我经常升级。两个 minio 的版本就越差越远。
然后昨天晚上，线上的 minio 因为鉴权不兼容，在 sync 的时候居然挂了。我登上去手动更新了一下可执行文件即可。
借此机会想抒发几个感慨：
1. storage vps 除了硬盘大没其他优点，除了跑 s3 没其他用处。廉价 VPS 我也买过不少了，之所以便宜都是因为有大坑，😮💨。
2. Go 的静态编译真香，这破机器上我就只能跑得起来 Go 的程序。
然后昨天晚上，线上的 minio 因为鉴权不兼容，在 sync 的时候居然挂了。我登上去手动更新了一下可执行文件即可。
借此机会想抒发几个感慨：
1. storage vps 除了硬盘大没其他优点，除了跑 s3 没其他用处。廉价 VPS 我也买过不少了，之所以便宜都是因为有大坑，😮💨。
2. Go 的静态编译真香，这破机器上我就只能跑得起来 Go 的程序。
这系列的后续两篇文章描述的都是同样的 QUIC HoLB 问题，即对 http fields table 更新的依赖所导致的 HoLB。
* https://laisky.notion.site/HoL-Blocking-Allows-Attacks-in-QUIC-52f6f3876b5943b0ae257d56c70d0549
* https://laisky.notion.site/HoL-Blocking-and-the-Deadlock-Hazard-in-QUIC-614658fee16e4c23b276c98e7300d4b0
但是更进一步介绍了可能带来的风险：
1. 单 stream 死锁风险：某个 stream 可能会依赖该 stream 后续的 header 更新
2. 多 stream 死锁风险：当接收端的 flow control window 被塞满，header 更新可能无法送达，导致死锁
3. DoS 攻击：攻击者伪造一个请求，该请求依赖一个不存在的 fields table 版本。
prev: https://t.me/laiskynotes/42
next: https://t.me/laiskynotes/84
* https://laisky.notion.site/HoL-Blocking-Allows-Attacks-in-QUIC-52f6f3876b5943b0ae257d56c70d0549
* https://laisky.notion.site/HoL-Blocking-and-the-Deadlock-Hazard-in-QUIC-614658fee16e4c23b276c98e7300d4b0
但是更进一步介绍了可能带来的风险：
1. 单 stream 死锁风险：某个 stream 可能会依赖该 stream 后续的 header 更新
2. 多 stream 死锁风险：当接收端的 flow control window 被塞满，header 更新可能无法送达，导致死锁
3. DoS 攻击：攻击者伪造一个请求，该请求依赖一个不存在的 fields table 版本。
prev: https://t.me/laiskynotes/42
next: https://t.me/laiskynotes/84
Laisky on Notion
HoL Blocking Allows Attacks in QUIC | Notion
Protocol designers underestimate how badly people will implement their designs.
https://arxiv.org/pdf/2311.00871.pdf 这篇论文指出，大模型（LLM）对上下文的理解能力（ICL）不是一种通用的泛化能力，而是对预训练数据的检索能力。
用通俗的话说就是，不是一个智能理解了你的问题，而是它从数据集里搜索到了关联数据。
我现在愈发认为 LLM 只是一种高效的信息压缩算法，它的特色在于解压的效果也依赖于输入（prompt）。而 ICL 其实类似于心理学的“锚定效应”，所谓的 prompt engineering 只是在试图让 LLM 的答复锚定到更高质量的预训练数据集上。
至于能不能通向 AGI，对既有方法的灵活运用也是能够导向创新的，但是目前 LLM 的问题在于知识质量鱼龙混杂，需要人类高效 prompt 才能引出高效的答复，这可能预示着它只能扮演一个 copilot 角色，而且它的能力和人类搭档的能力是成正比的。
用通俗的话说就是，不是一个智能理解了你的问题，而是它从数据集里搜索到了关联数据。
我现在愈发认为 LLM 只是一种高效的信息压缩算法，它的特色在于解压的效果也依赖于输入（prompt）。而 ICL 其实类似于心理学的“锚定效应”，所谓的 prompt engineering 只是在试图让 LLM 的答复锚定到更高质量的预训练数据集上。
至于能不能通向 AGI，对既有方法的灵活运用也是能够导向创新的，但是目前 LLM 的问题在于知识质量鱼龙混杂，需要人类高效 prompt 才能引出高效的答复，这可能预示着它只能扮演一个 copilot 角色，而且它的能力和人类搭档的能力是成正比的。
https://youtu.be/EMXnJMCoFYI
WSJ 在 2023-06 拍摄的揭露瓦格纳雇佣军团背景的纪录片。
我第一次见识瓦格纳是在乌克兰战场以俄军炮灰的身份出现，但其实在俄罗斯全面入侵乌克兰以前，瓦格纳一直在小心翼翼地和俄罗斯政府撇清关系。
虽然瓦格纳的背后完全是俄罗斯的政府资金和军火，但是瓦格纳明面上是一个完全私人的雇佣军集团，发家于叙利亚战争。它在叙利亚的运营模式是，帮助叙利亚的巴沙尔政府夺取油气田，然后从中获取 25% 的利润分成。这套模式让瓦格纳在叙利亚赚得盆满钵满，这些钱一部分用于维护自身运作，一部分进入普里戈金的腰包，还有相当大一部分回流回克林姆林宫。
在叙利亚还发生了一起小插曲，2018年2月瓦格纳军团进攻由美军支持的抵抗军油气田，美军询问俄军是否参与，被俄军否认后，美军出动空军全歼了这支瓦格纳军队，造成数百人死伤。(Battle of Khasham)
叙利亚模式让克林姆林宫尝到了甜头，于是开始在全球范围内推广这套模式，罪恶的魔爪遍及四大洲，前阵子九名中国工人在中非被杀就是出自瓦格纳之手。
然而乌克兰战争让瓦格纳从幕后走向了台前，和俄军的关系逐渐明朗化，部队组成也从精英战士向囚犯炮灰转变。
当专家们预言这代表着瓦格纳即将面临转型时，军事叛变发生了，不过这是发生在这部纪录片以后的事情了。
WSJ 在 2023-06 拍摄的揭露瓦格纳雇佣军团背景的纪录片。
我第一次见识瓦格纳是在乌克兰战场以俄军炮灰的身份出现，但其实在俄罗斯全面入侵乌克兰以前，瓦格纳一直在小心翼翼地和俄罗斯政府撇清关系。
虽然瓦格纳的背后完全是俄罗斯的政府资金和军火，但是瓦格纳明面上是一个完全私人的雇佣军集团，发家于叙利亚战争。它在叙利亚的运营模式是，帮助叙利亚的巴沙尔政府夺取油气田，然后从中获取 25% 的利润分成。这套模式让瓦格纳在叙利亚赚得盆满钵满，这些钱一部分用于维护自身运作，一部分进入普里戈金的腰包，还有相当大一部分回流回克林姆林宫。
在叙利亚还发生了一起小插曲，2018年2月瓦格纳军团进攻由美军支持的抵抗军油气田，美军询问俄军是否参与，被俄军否认后，美军出动空军全歼了这支瓦格纳军队，造成数百人死伤。(Battle of Khasham)
叙利亚模式让克林姆林宫尝到了甜头，于是开始在全球范围内推广这套模式，罪恶的魔爪遍及四大洲，前阵子九名中国工人在中非被杀就是出自瓦格纳之手。
然而乌克兰战争让瓦格纳从幕后走向了台前，和俄军的关系逐渐明朗化，部队组成也从精英战士向囚犯炮灰转变。
当专家们预言这代表着瓦格纳即将面临转型时，军事叛变发生了，不过这是发生在这部纪录片以后的事情了。
https://pkg.go.dev/crypto/ecdh #golang
Go 1.20 引入的这个 ECDH 包性能相当可以，比我之前用的第三方 DHKX 包快 80 倍😂。
Ps. DH 是密钥交换算法（Diffie-Hellman key agreement/exchange protocol），Alice 和 Bob 各自生成自己的公私钥对，并交换公钥。
然后各自用自己的私钥和对方的公钥可以计算出一个相同的共享密钥，这个密钥可以用来作为后续通信的对称密钥。
Go 1.20 引入的这个 ECDH 包性能相当可以，比我之前用的第三方 DHKX 包快 80 倍😂。
Ps. DH 是密钥交换算法（Diffie-Hellman key agreement/exchange protocol），Alice 和 Bob 各自生成自己的公私钥对，并交换公钥。
然后各自用自己的私钥和对方的公钥可以计算出一个相同的共享密钥，这个密钥可以用来作为后续通信的对称密钥。
前文提到过，HTTP/2 的分帧是不彻底的，仅仅是应用层 stream，而在传输层 TCP 看来仍然是一个 stream。HTTP/3 将 stream 拆分做到了传输层，在 UDP 层面就以 stream 为单位，声称解决了所有的 stream 间 HoLB 问题。
https://laisky.notion.site/HoL-Blocking-and-Priority-Inversion-LiteSpeed-Blog-4601095b01ed4f8d87bc3bc40ed665d7
很可惜现实是残酷的，其实 stream 间的阻塞也没解决。这次问题出在 QPACK: Field Compression for HTTP/3 上。
HTTP/1 时代，大量流量被浪费在重复传输 HTTP fields 上（如 HEADERS），所以从 HTTP/2 时代起，就引入了 HPACK 来压缩 HTTP fields。客户端和服务端各自维护一个 fields table，然后进行增量的更新。
在 HTTP/3 上保留了这个设计，并更名为 QPACK。但是 QPACK 的设计有个问题，它让 stream 间失去了独立，带来了依赖关系，而我们都知道，依赖关系会导致 HoLB。
具体来说，因为 QPACK 只传输增量更新，所以每一个 request/response 都需要指定一个
这就导致了一个很可怕的现象，一个高优先级的 stream，可能会因为缺乏必要的
更可怕的是，按照 RFC-9204 规定，当一个 stream 被
prev: https://t.me/laiskynotes/40
next: https://t.me/laiskynotes/62
https://laisky.notion.site/HoL-Blocking-and-Priority-Inversion-LiteSpeed-Blog-4601095b01ed4f8d87bc3bc40ed665d7
很可惜现实是残酷的，其实 stream 间的阻塞也没解决。这次问题出在 QPACK: Field Compression for HTTP/3 上。
HTTP/1 时代，大量流量被浪费在重复传输 HTTP fields 上（如 HEADERS），所以从 HTTP/2 时代起，就引入了 HPACK 来压缩 HTTP fields。客户端和服务端各自维护一个 fields table，然后进行增量的更新。
在 HTTP/3 上保留了这个设计，并更名为 QPACK。但是 QPACK 的设计有个问题，它让 stream 间失去了独立，带来了依赖关系，而我们都知道，依赖关系会导致 HoLB。
具体来说，因为 QPACK 只传输增量更新，所以每一个 request/response 都需要指定一个
REQUIRED INSERT COUNT，表示这个 request/response 至少依赖于哪一个版本的 fields table 的更新。而 HTTP/3 的 fields 更新是以 HEADER 的形式和 DATA 一起传输的（gQUIC 原始设计中独立的 HEADER stream 被 IETF/QUIC 取消了），换言之，fields 的更新属于某一个 data stream。而这个 data stream 的优先级，是由 data 而不是 header 决定的。这就导致了一个很可怕的现象，一个高优先级的 stream，可能会因为缺乏必要的
REQUIRED INSERT COUNT 而被另一个携带 fields 更新的低优先级 stream 阻塞。更可怕的是，按照 RFC-9204 规定，当一个 stream 被
REQUIRED INSERT COUNT 阻塞时，接收方应该一直缓存这个 stream 直到 REQUIRED INSERT COUNT 满足为止。如前文所述，如果是高优先级的 stream 被低优先级的 stream 阻塞，那么接收方必须很傻地接受完全部高优先级数据后，才能继续处理低优先级的数据。而高优先级的数据就只能躺在缓存里傻等低优先级的增量更新完成后，才能被处理。prev: https://t.me/laiskynotes/40
next: https://t.me/laiskynotes/62
Laisky on Notion
HoL Blocking and Priority Inversion in QUIC | Notion
Background