如何理解 Motrix 浏览器扩展配对协议 MBP1：SPAKE2 首次配对与 AEAD 安全通道-北京尧图网络

如何理解 Motrix 浏览器扩展配对协议 MBP1SPAKE2 首次配对与 AEAD 安全通道【免费下载链接】MotrixA full-featured download manager.项目地址: https://gitcode.com/GitHub_Trending/mo/Motrix如果你要开发、审查或二次接入 Motrix 浏览器扩展与 Motrix bridge server 之间的连接需要理解的是 MBP1——一份把密码学参数钉死到字节级的 wire 契约protocolVersion 1。它解决一个具体问题早期 Native Messaging 时代靠 0600 权限的endpoint.json隐式证明连的就是用户自己的 Motrix而改用固定候选端口段 16802–16806 之后这个证明失效了。MBP1 用四组机制替代它基于 SPAKE2 的首次配对口令是 Motrix 显示、用户手动输入进扩展的短时效配对码、基于长期对称凭据mutualKey的重连 challenge–response、握手后每一帧都包裹在 AES-256-GCM envelope 内的安全信道、以及 Native Messaging 环境下的一次性 attestation ticket。本文按开发者视角走通其中两条主线——SPAKE2 首次配对与 AEAD 安全通道——并给出用规范测试向量校验实现的方法。规范全文见 MBP1 中文规范与英文版。先固定两个前提角色分配与唯一 ciphersuite角色分配是 [RFC 9382] §3.1 的约定扩展是 A 方发起方使用点MMotrix bridge server 是 B 方应答方使用点N。MBP1 v1 只支持恰好一个 ciphersuite没有协商、没有降级路径不支持它的对端直接握手失败fail closed组件选择群Gedwards25519RFC 8032基点为 RFC 8032 基点阶ℓ 2^252 27742317777372353535851937790883648493cofactorh 8PAKESPAKE2ciphersuite SPAKE2-edwards25519-SHA256-HKDF-HMACHash / KDF / MACSHA-256 / HKDF-SHA-256 / HMAC-SHA-256MHF口令→标量scryptN2^14, r8, p1, dkLen64AEADAES-256-GCM12 字节 nonce16 字节 tag签名ticket 绑定Ed25519固定点M、N取 RFC 9382 §6 的 edwards25519 常量32 字节 RFC 8032 编码M d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf N d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab实现来源有硬约束规范 §3曲线运算、SPAKE2 组合、scrypt、Ed25519 必须来自捆绑库并精确锁版本——TypeScript 侧为noble/curves2.4.0与noble/hashes2.4.0即生成规范向量所用的版本。MUST NOT使用 WebCrypto 的 X25519/Ed25519它要求 Chrome 133 / Firefox 130而扩展最低支持 Chrome 120 / Firefox 121。对称原语AES-256-GCM、HKDF、HMACMAY 使用 WebCrypto。所有涉密比较必须 constant-time标量乘法必须走库的 secret-scalar 路径。进入配对四个入口面与一个硬性门bridge server 监听 loopback绑定 16802–16806 中第一个空闲端口全占用时降级 ephemeral 端口。与 MBP1 相关的四个面面方法认证用途/discoveryGET无探测 hint这里有没有 Motrix、是哪个实例/noncePOST 自定义头无一次性配对 nonce 签发/pairWS upgrade?nonceMBP1 首次配对code-entry PAKE 配对/v1WS upgradeURL 无凭据MBP1 重连challenge–response 会话两个入口级规则值得在实现前先记住路由即 demultiplexing/pair只接受首配状态机/v1只接受重连状态机不存在 token-only 模式、?token查询参数或 legacy 帧格式。认证前连接只停留在带硬性 deadline 与容量上限的 pre-authentication 表中绝不进入 live-session map。两条 WebSocket 路由都要求motrix-bridge.v1subprotocol客户端 MUST 在Sec-WebSocket-Protocol中提供它否则在检查路由之前、消耗任何 nonce 之前就以401拒绝。POST /nonce必须携带自定义头X-Motrix-Bridge: 1使请求成为 non-simple 请求跨源网页被浏览器 preflight 拦截server 不授予任何 CORS。nonce 一次性、60 秒过期、只被/pair消费。绑定 loopback 期间所有路由 MUST 拒绝Host不严格等于127.0.0.1[:port]、localhost[:port]或[::1][:port]的请求403封死 DNS rebinding。GET /discovery返回的 JSONinstanceId、appVersion、extensionPairing.protocol: mbp1等字段只是 hintMUST NOT 据此授予信任或做 legacy 降级端口 pin 只能在该端口上完成双向认证的 MBP1 会话之后提交。SPAKE2 首次配对消息流程与口令派生信道激活前/pair上的所有消息都是单个 WebSocket文本帧内容为恰好一个带type判别字段的 JSON 对象二进制字段用 base64url。未知type、乱序、重复、超大帧认证前 16 KiB或 schema 校验失败一律以protocolViolation中止连接。完整流程规范 §6.1extension (A) Motrix (B) | | |-- pairHello ------------------------------| 校验 nonce、origin、 | | ticket排队审批对话框 |------------------------------- pairAccept | 对话框显示配对码 | | | 用户在 Motrix 窗口读取配对码 | | 用户在扩展中输入配对码 | | | |-- pakeA {pA} -----------------------------| |----------------------------- pakeB {pB} | |-- confirmA {cA, ticketProof?} ------------| 验证 cA proof |----------------------------- confirmB {cB}| | 验证 cB | | AEAD 信道激活 | |------------------------- credentialOffer | | 持久化到 storage.local | |-- credentialAck ---------------------------| 持久化 commit |--------------------- credentialCommitted | | MDXP initialize... |下文 wire 示例中的...均为每次连接的运行时值UUID、随机字节等不是固定字符串。pairHello是 A 发出的首帧{ type: pairHello, protocolVersion: 1, browser: chromium | firefox, claimedExtensionId: store ID or Gecko ID, clientInstallationId: UUIDv4 persisted in storage.local, nmTicket: { ... }, ticketBindingKey: b64url 32-byte Ed25519 public key }nmTicket可选携带时ticketBindingKey必填。server 收到后按序处理校验?nonce无效则在后续工作之前关 socket→ 校验 Host 与 Origin → 在执行任何会话状态或对话框之前做 pending-pair 去重、全局上限与 backoff → 若带nmTicket则先于 key confirmation 校验 ticket要求bindingPub ticketBindingKey、callerId claimedExtensionId→ 解析身份三态 → 排队恰好一个审批对话框。pairAccept只表示对话框已排队不携带批准语义——扩展 MUST NOT 把任何 server 消息当作用户已批准只有 key confirmation 成功才是证明。配对码即 PAKE 口令配对码规范 §7的格式Crockford base32 字母表0123456789ABCDEFGHJKMNPQRSTVWXYZ排除I、L、O、U8 个符号恰好 40 bit取自 5 个 CSPRNG 字节展示为大写XXXX-XXXX只显示在 Motrix 审批对话框中。配对码就是 PAKE 口令MUST 绝不以任何形式经任何网络信道传输、绝不写入日志。扩展侧输入先本地规范化去连字符空格、转大写、映射O→0、I→1、L→1再要求恰好 8 个字母表符号本地校验失败的输入直接在 popup 拒绝不产生网络流量、不消耗尝试次数。生命周期每个配对会话一个码在最早到达的时点作废——生成后120 秒、对话框关闭、WebSocket 关闭、或第 3 次失败尝试。第 3 次失败后 server 发pairError {code:rateLimited}并关闭 socket。尝试计数由双方独立记录断连不会重置。码 → 标量w的派生§6.2pw是规范化后 8 个 ASCII 字节pairNonce是本连接消费的那个 ASCII nonce 原文salt MBP1/w/v1 ‖ UTF8(pairNonce) h scrypt(pw, salt, N2^14, r8, p1, dkLen64) w OS2IP(h) mod ℓpairNonce使w会话唯一。若w 0则以pairingFailed中止概率约 2^-252无重试语义。scrypt 是 RFC 推荐的 MHF同时封死在配对码存活期内对主动攻击 transcript 记录的离线穷举。SPAKE2 计算、transcript 与 key schedule按 RFC 9382 §3.3A 扩展B MotrixA 以拒绝采样从[1, ℓ)均匀抽x抽 32 个 CSPRNG 字节按大端解释值为 0 或 ≥ ℓ 时重抽。X x·PpA w·M XB 同法抽yY y·PpB w·N Y。收到的点 MUST 能按 RFC 8032 规范编码解码为曲线上点否则以protocolViolation中止。A 计算K h·x·(pB − w·N)B 计算K h·y·(pA − w·M)h 8K为单位元则中止计一次失败尝试。x、y每次协议运行必须新抽、绝不复用PAKE 状态只存内存运行以任何方式结束即销毁。TranscriptTT把双方身份与全部密码学材料绑在一起§6.4A_id enc(MBP1/A/v1) ‖ enc(browser) ‖ enc(verifiedOrigin) ‖ enc(claimedExtensionId) ‖ enc(clientInstallationId) B_id enc(MBP1/B/v1) ‖ enc(motrix-bridge) ‖ enc(instanceId) TT enc(A_id) ‖ enc(B_id) ‖ enc(pA) ‖ enc(pB) ‖ enc(K) ‖ enc(I2OSP(w, 32))enc(s) len64LE(s) ‖ s8 字节小端长度前缀verifiedOrigin取 WebSocket upgrade 的Origin头 ASCII 值。AAD 进一步绑定 nonce 与 ticketAAD encU32BE(protocolVersion) ‖ enc(pairNonce) ‖ enc(ticketBindingKeyOrEmpty) ‖ enc(ticketDigestOrEmpty)任何 origin、browser、ID、nonce 或 binding key 的调换misbinding都会让双方 AAD 或 TT 失配从而在 key confirmation 处失败——这是篡改不静默降级的结构性保证。Key scheduleRFC 9382 §4SHA-256Ke ‖ Ka SHA-256(TT) 各 16 字节 KcA ‖ KcB HKDF-SHA-256(ikmKa, saltempty, infoConfirmationKeys ‖ AAD, L32) 各 16 字节 cA HMAC-SHA-256(KcA, TT) cB HMAC-SHA-256(KcB, TT)A 先发cAB MUST 在发cB之前验证cA带 ticket 时还须验证ticketProof——对MBP1/ticket-proof/v1 ‖ TT的 Ed25519 签名按 RFC 8032 strict 规则、zip215: false验证。两处验证均 constant-time。验证失败计一次失败尝试B 回复pairError {code:codeMismatch, attemptsRemaining}配对码仍存活时 MAY 在同一连接以全新x重跑pakeA。尝试限制双方独立执行扩展自行执行每配对会话至多 3 轮协议运行、自pairHello起 180 秒绝对 deadline、以及全局失败 backoffmin(30 · 2^(n−1), 3600)秒成功配对或 24 小时后重置无论对端报告什么——server 发来的attemptsRemaining是不可信展示数据MUST NOT 用来放宽本地限制。配对会话 traffic key 与两阶段凭据提交双向 confirmation 通过后§6.6kC2S HKDF-SHA-256(ikmKe, saltMBP1/pair/v1, infoMBP1-pair-traffic-c2s, L32) kS2C HKDF-SHA-256(ikmKe, saltMBP1/pair/v1, infoMBP1-pair-traffic-s2c, L32)MBP1 中每个 HKDF/HMAC 调用都携带全局唯一 labelkey 分离从不依赖 IKM 或 salt 的偶然差异。此后连接上所有帧凭据消息与 MDXP 一视同仁都在 AEAD envelope 内传输。信道内的凭据签发是两阶段提交§6.7B 先以provisional状态持久化凭据再发credentialOffer {credentialId, mutualKey}A 写入storage.local后在发送credentialAck之前先持久化unacked → commit-uncertainwrite-ahead然后才发 ackB 持久化标记committed后回credentialCommitted。这套顺序保证 ack/commit 窗口内任意位置的崩溃都留下可重连状态。凭据 principal 是{browser, verifiedOrigin, clientInstallationId}第二个浏览器 profile 是新 principal互不影响过期或被吊销的凭据一律要求重新 code-entry 配对绝不静默重新信任。AEAD 安全通道envelope 结构、重放保护与用量上限envelope 在/pair上自 §6.6 起、在/v1上自重连成功起激活双向、覆盖每一帧位于 MDXP 之下MDXP JSON-RPC 载荷字节即明文原样不动frame seq64BE ‖ AES-256-GCM(key k_dir, nonce, plaintext, aad) nonce dirTag(4 字节 BE) ‖ seq64BE 12 字节 dirTag 0x00000001client→server| 0x00000002server→client aad MBP1/env/v1ASCII11 字节实现要点§10帧是 WebSocket二进制消息一条消息一帧信道激活后的文本帧是协议违例。seq每方向从 0 开始、每帧恰好加 1。接收方 MUST 要求seq等于本地期望计数严格单调、无窗口任何跳号、重复或 GCM 认证失败 MUST 立即关闭连接。重放保护就是这条严格序号检查。key 按方向独立nonce 唯一性由构造保证。但唯一性不等于用量上界连接 MUST 在任一方向超过2^24 帧或2^30 个已加密 AES block16 GiB 明文先到为准之前关闭——经重连重建、派生新 key。v1 不做原地 rekey。单帧明文上限 1 MiBserver 的 WebSocket parser MUST 把单条消息限制在 1 MiB 8 字节序号 16 字节 tag防止未认证对端先迫使缓冲超大消息。认证前更严格的 16 KiB 帧限制由状态机独立执行。信道激活之后不再有pairError——envelope 违规与用量上限都通过关闭码报告1002协议违规统一码从不指明失败项、4001达到用量上限双方皆无失当客户端按重连流程重建、1011关闭方自身内部故障。客户端 MUST NOT 依据关闭码分支任何已建立 envelope 信道的关闭都意味着经 §8 重建关闭码只让日志可读不承载协议状态。重连路径§8与首配共用同一套成帧规则/v1的 URL 不携带任何凭据server 先发reconnectChallenge {S}客户端回reconnectResponse {credentialId, C, mac}其中mac HMAC-SHA-256(mutualKey, MBP1-R/c ‖ S ‖ C ‖ RT)成功后reconnectAccept.mac由客户端在发送任何其他内容之前验证失败即视为不是我的 Motrix清端口 pin、回退扫描/重新配对。对未知credentialId与错误 MACserver 行为完全一致dummy key 做 constant-time 验证、统一回复authFailed后关闭使该面不成为凭据 ID oracle。边界MBP1 不防御什么理解协议前先接受它的边界§1.1避免高估保证。不在范围内同 UID 本地代码可ptraceMotrix、读storage.local、root 或具备 raw-socket / eBPF 能力的代码、共享 X11 输入注入、被攻破的浏览器。MBP1 必须挡住的是共宿主机的不同 UID 用户他能抢占 loopback 候选端口并主动连接或中继但无法读取其他 UID 的 0600 文件也无法被动截获其他 UID 已建立的 loopback 流。透明中继抢占端口、把一场 PAKE 会话逐帧转发给真正的 Motrix只能建立一条他自己读不到的端到端密钥——AEAD 信道拒绝其读取、伪造、篡改它留在路径中的存在、可见流量大小与时序是 loopback 端口抢占的固有残留文档如实记录不声称已关闭。审批对话框侧另有身份三态§5officialChromium verified Origin 或有效 NM ticket 的callerId命中不可变 allowlist src/shared/config/native-messaging-extensions.json、attested-non-official有效 ticket 证明了确切 ID 但不在 allowlist、unverified无 attestation 的 Firefox/pair或候选段扫描到的对端。官方身份只读 allowlist绝不读 NM manifest 集合。验证实现规范测试向量与参考生成器规范 §13 给出了可执行的验证路径。跨实现向量是规范性的位于 bridge-pairing-protocol-vectors.json与本规范同目录全部字节串为 hex 编码包含五组spake2— 固定输入code、pairNonce、身份以及像 RFC 向量一样直接给出的w、x、y下的完整首配运行及期望pA、pB、K、TT、Ke、Ka、KcA、KcB、cA、cB、traffic key。因为 RFC 9382 Appendix B 只提供 P-256 向量通用 SPAKE2 核心的实现 MUST 先通过全部四组RFC P-256 向量证明 TT 布局与 key schedule 正确再信任 edwards25519 实例化。scryptW— 配对码规范化与w派生§6.2。reconnect—RT、客户端与 server MAC、traffic key§8。nmTicket—ticketKey派生、规范 MAC、ticketDigest外加 weak binding-key 拒绝用例单位元、small-order 点、dirty/non-torsion-freebindingPub均 MUST 被拒S ≥ ℓ与非规范R签名 MUST 被 strict 验证拒绝。envelope— 给定 key/明文下的 AEAD 帧含期望拒绝用例错误序号、篡改密文、仅翻转 dirTagkey 不变——忽略dirTag的实现无法蒙混过关。向量由参考生成器产出脚本已入库scripts/generate-bridge-pairing-vectors.mjs。它分两步先用全部四组 RFC 9382 Appendix B P-256 向量验证通用 SPAKE2 核心再生成 MBP1 edwards25519 向量并自检含 strict Ed25519 验证与 weak binding-key 拒绝。直接运行方式output.json替换为你自己的输出路径node scripts/generate-bridge-pairing-vectors.mjs /tmp/mbp1-vectors.json注意副作用npm script 入口pnpm run generate:bridge-vectors的默认输出路径是仓库内的 docs/bridge-pairing-protocol-vectors.json会直接覆写这份规范性文件。规范同时要求给定记录输入重新生成 MUST 是确定性的——所以更稳妥的做法是把向量写到仓库外路径再与仓库内文件 diff确认字节级一致。向量文件之外实现测试套件 MUST 覆盖向量无法表达的有状态用例双侧尝试上限§6.5/§7.2、跨断连的全局计数§7.3、以及轮换的崩溃点§6.7。仓库内的参考实现位于 src/core/bridge/mbp1/可对照阅读spake2-core.tsSPAKE2 组合、pairing-code.ts码的生成与规范化、scrypt-w.tsw派生、transcript.tsTT/AAD、envelope.ts与envelope-message-stream.tsenvelope 编解码与序号检查、ticket-verify.tsNM ticket 校验、reconnect-mac.ts与reconnect-session.ts重连 MAC 与状态机每个模块旁都有同名*.test.ts。升级依赖前先过 gate规范 §14 的实现 gate 里有一条直接影响二次开发任何noble/curves/noble/hashes版本升级都要重跑全部向量并重新开启密码学审查门禁——2.4.0 这一精确组合的依赖审查是在 2026-09-03 经独立审查批准后才满足的附录 C 的 Dep-pin-2 记录全部四组 RFC P-256 向量复现、310 项 MBP1 单元测试与 77 项回环传输测试通过。同理复用 PAKE 标量或改变 threat model 也会重新开启审查。实现侧还需遵守两条日志纪律任何日志级别都 MUST NOT 记录配对码、w、PAKE 中间值、key、MAC 或 ticketserver MUST NOT 泄露codeMismatch/attemptsRemaining之外的内部失败步骤。核对完成的路径是实现对照五组规范向量全部通过 → SPAKE2 核心先过 RFC 9382 全部四组 P-256 向量 → 有状态用例尝试上限、全局计数、轮换崩溃点有独立测试覆盖 → 依赖版本精确锁定 2.4.0 并记录审计依据。满足这些你的实现就落在规范定义的验收边界内协议本身不覆盖的残留透明中继的路径存在性、同 UID 本地代码则按 §1.1 的威胁模型理解不写进已解决。【免费下载链接】MotrixA full-featured download manager.项目地址: https://gitcode.com/GitHub_Trending/mo/Motrix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

如何理解 Motrix 浏览器扩展配对协议 MBP1：SPAKE2 首次配对与 AEAD 安全通道

相关推荐

Angular 编译器 ngtsc 的 Shims 机制解析：如何把“虚拟源码文件“无缝注入 TypeScript 程序

技术新手到中级的成长路径与学习方法

OpenCode 如何在 GitLab 的 Issue 与 Merge Request 中通过 @opencode 触发任务

更多资讯

Nginx Proxy Manager Redirection Host 实战指南：域名跳转的配置、原理与最佳实践

CANN/GE图切分保存接口

开题报告连遭三次打回？测完7类AI工具，我整理出这份分阶段选型指南

OpenCore Legacy Patcher：四步把老 Mac 升级 macOS 装完（附 U 盘容量与耗时参考）

从零构建 Claude Code 式编码 Harness：基于 CrewAI、E2B 与 OpenRouter 的分层 Agent 实现

Puter 自托管在反向代理后出现重定向循环和 Invalid Host header 怎么排查？

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？