我已经为25年构建系统，我喜欢构建那些有意设计且运作精简的事物，只携带足以证明其价值的向量。
在这种方法中，最小化我存储的用户数据始终对我有意义，原因超越了显而易见的。 他们数据的主权很重要。 在其下是更简单的东西：事物应归其所属。 我构建的大部分是处理，处理架构不可能以其他方式运作。 持有从未需要的记录是无价值的向量。 将其视为优化而非合规练习，是保持设计诚实的关键——以这种方式构建的系统往往自然而然地与监管保持良好关系，因为几乎没有剩余可供监管。
所以当 Mary Camacho 的公告出现在我的 X 订阅中时，我以我自己的方式阅读了她的架构。 她已将其核心以 Creative Commons 许可证发布到公共记录中，细节足以让工程师重建，并且她对其所依赖的前沿技术直言不讳。
在整个过程中，我在服务器内部放置了一个对抗实体并跟踪它能达到的范围。 它能超过工作者。
几乎所有随后的工作都是通过语音对话完成的——通过30 语音笔记，边思考边大声朗读，并从不同角度测试关注点，直到它要么成立，要么崩溃。

我注意到：设备加密给先写入声明记录的人

公开说明直接指定操作顺序。 工作者声称工作并发布其密钥，随后设备才加密：
  1. 工作者 → 协调：轮询并声称工作（写一次，先赢），发布工人的公钥。
  2. 设备 ← 协调：轮询，检索工人的公钥，推导共享密钥，加密有效载荷。
— §2.1, 数据流（每个工作）
设备在该协议中的角色以同等精度指定：
设备在获知工人公钥后，执行自己的 X25519 交换和针对工人密钥的 ML-KEM 封装，产生自己的公钥贡献（X25519 公钥 ‖ ML-KEM 密文）和共享密钥。
— §4.2, 与工人生命周期绑定
在获知时。 在19页中，没有对工人短暂公钥的签名，没有证书，没有设备评估的证明，也没有预共享密钥。 缺失是有意的，并被呈现为优势：模型在没有证明文件、TPM 报价或测量启动工件的情况下进行解密，并且不保留任何预配置的工人秘密。
因此设备将其有效载荷加密给声明记录中所持的任何公钥，没有手段区分合法工人密钥与其他任何人的。 任何能够先写入声明的人都成为设备加密的对象，机密有效载荷在其手中解密。
Diagram source
flowchart TB
    subgraph BEFORE["之前：按发布"]
        direction LR
        A2{“谁先声明？”} -->|真正的工人| A3["真正的密钥"]
        A2 -->|任何其他写入者| A4["攻击者密钥"]
        A3 --> A5["设备加密到它"]
        A4 --> A5
        A5 --> A6["密钥持有者可以读取"]
    end
    subgraph AFTER["之后：签名密钥"]
        direction LR
        B2{“签名有效？”} -->|是| B3["已验证的工人密钥"]
        B2 -->|否| B4["拒绝，重试"]
        B3 --> B5["只有真正的工人读取"]
    end
    A6 ~~~ B2
严重性来自模型携带的内容。 这种架构存在的目的是保存人们最不愿意被读取的数据，它在问题的更难的一半上取得成功：已完成的工作无法被任何人解密，包括操作员。 间隙出现在设备必须确定它正在与谁通信的那一步。

加密技术是可靠的，介绍部分未经过身份验证

攻击者没有破坏任何东西。 X25519 和 ML-KEM-768 都按规定工作。 攻击者提供一个密钥并成为协议的合法方。
这是未经过身份验证的密钥协商，其失败模式是该领域最古老的结果。 普通的 Diffie-Hellman 未验证任何人，易被替换自己公钥的方利用。 密钥封装机制继承了这一属性，这也是为什么 RFC 9180 将接收方公钥的真实性放在其自身范围之外，并假设周围的应用通过证书、密钥目录或离线验证来建立它。 这个模型就是周围的应用，它使用的通道来分发接收方密钥是其自身信任模型标记为不可信的组件。
公开说明预见了邻近攻击并加以关闭：
索赔是写一次/先赢，因此后来的工人无法劫持工作密钥交换。
— §6，参考实现
该推理是可靠的，机制按其所述工作。 它涵盖了两种对称情况之一。
威胁由一次性写入声明处理
第二个工作者覆盖现有声明是的——写入被拒绝
未授权方先写入声明否——第一次写入获胜
首次获胜是一次竞争。 规则保证获胜者保留工作，并未说明谁是获胜者。
还有一句值得引用的断言，因为发现与之相矛盾：
中间人（网关、协调、存储、监控）永远不会拥有足够的密钥材料来推导任何一个秘密。 攻击者如果破坏协调或存储，只能获得不透明的 blob 和公钥。
— §4.3，独立的单向密钥
第一句是准确的。 第二句描述了一个读取的攻击者。 写入攻击者在设备轮询之前将选定的公钥放入声明记录，且对能够安排成为对手的一方来说，推导合法秘密变得不必要。 谁管理该记录的内容，谁就能读取有效载荷，这使得协调层成为机密性的可信组件——§3所说的唯一不应存在的组件除了设备和工作者之外。
对声明的诚实界限：这并不意味着今天开放互联网上的任何人都能读取这些数据。 在实际部署中，写入声明的能力位于云网络和凭证之后，披露描述了设备路径上的身份验证网关。 精确的问题是，机密性现在依赖于该外围，而架构的核心承诺是它在不信任设备与工作者之间组件的情况下保持安全。

两个设计属性叠加了后果

结果在第二个协议下返回设备，由同一对手调解，因此被拦截的任务完成并从用户侧看起来很普通。
故意缺少持久任务和结果账本——同样的缺失导致非托管并缩小监管范围——消除了调查者后来用来重建受影响任务的大部分依据。 协调记录的有效期约为一小时。 在普通情况下保护数据的属性在对抗性情况下削弱了取证记录。

差距是模型最佳决策所投射的阴影

架构将操作员合法持有的数据与其绝不能持有的数据分离。 联系数据是一个人是谁以及如何联系他们。 机密数据是他们透露的关于自己的信息。 传统系统将两者都存储在同一数据库中，这一步骤将账户表变成某人私生活的记录。 结构化答案是一行：保留联系信息，无法保留机密信息。
移除中央编排器直接实现了这一点。 分配作业给工人的组件必然会了解谁在做什么，而这正是模型拒绝持有的精确资产。 移除它也去除了本来会为工人身份担保的组件，所有剩余的验证工人的路径都被独立拒绝，每个都有可辩护的理由。
结果是一个在托管方面进行严谨推理的设计，并在问题形态为身份验证的唯一点应用托管推理。 信任模型询问每个组件持有什么并给出正确答案。 需要的问题是每个组件可以替代什么。 这两个是独立的信任问题，解决其中任何一个都从未解决另一个。

在工人短暂公共密钥上签名即可完成闭合

工人在启动时生成其短暂密钥对，方式与现在完全相同。 在该密钥被发布到声明之前，它会被长期操作员密钥签名，该签名的公钥部分随应用程序一起发布。 设备在派生任何内容之前验证签名，并拒绝未签名或无效的密钥。 恢复已被指定，因为客户端驱动的重试配合新的作业和新的密钥协商是模型的标准失败路径。
决定性属性是 签名密钥不解密任何内容. 操作员签名密钥被泄露后，只能冒充未来的工人，且无法读取任何已完成的作业，因为每个作业的密钥已随其工人被销毁。 非托管、空密钥库以及无法进行事后解密的不可行性均保持完整。 这就是使设计完成的原因。
签名者保持远离成为设计中已移除的编排者。 它只需证明给定的短暂公共密钥属于操作员启动的工人，且永不需要知道该工人将声称的作业。 现有的监控器是自然的归宿：它已在提供和回收工人，既不持有用户数据也不持有密钥，并且按设计不路由或分配作业。
重放值得检查，因为没有作业知识的签名者无法将签名绑定到作业标识符。 攻击者将真实签名的工人密钥复制到不同的声明记录中，仍缺少相应的私钥，因此负载保持不可读。 结果是没人能处理的作业——服务拒绝，机密性保持完整。
仍有三项限制，披露中列出了全部：明文存在于工人内存中，作业时序泄露元数据，且密钥派生构造被作者标记为改进对象。

建议

之所以出现此发现，是因为架构被放置在公共领域。 公开发布使得独立评估成为可能，这也是为什么差距在此而非在事件报告中浮现的原因。 该系统的专有版本将面临相同的问题，而没有人能指出。
我感谢这份贡献，模型值得它所受到的审查。 中央主张成立，我希望更多系统采用这种形式，因为永不存储机密数据的架构，其监管表面仅为存储数据的架构的一小部分。
建议很狭窄：在设备加密之前先验证工人短期公钥。 一个签名，在设备上验证，成本为零，使模型值得采用。 上述全部来自一次语音转文本对话，跨越超过30条笔记，并与已发布的披露内容核对，而非其摘要。 如果这些发现得到其方验证，它们很容易采取行动。