0 Fork 0

Files

T

admin ce8e6ceed9 chore(工作区): 纳入版本控制基线（回收 411 MB 过程产物）

回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复：
- 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录）
- tmp/（32.4 M，按接续棒命名的过程临时区）
- .workbuddy/tmp/（39.5 M）
- 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物）
- tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留

入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与
接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、
.workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。

排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、
打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。

2026-09-24 07:51:03 +08:00

7.5 KiB

Raw Blame History

需求登记 · 覆盖网络 · 密钥轮换与多路分发（用户提出 2026-09-18 23:42 · 状态 = ⏸ 待实现）

登记缘由 = 用户原话（2026-09-18 23:42）：「能否增加一个随机时间更换加密密钥的方式增加破解难度，甚至可以通过不同节点或打洞设备更新加密密钥，还可以多设备同时分发多个只有一个是真实的」；随后（23:46）明确：「可以记录下来后续实现」。 本文件定位 = 需求登记草案（⛔ 非方案、⛔ 非交接单）。待折叠进入口 接续入口_覆盖网络线_20260916.md §4（待你处理 / 在册挂起项），并在启动实现前走规划棒出正式交接单。 为什么没直接写进入口 §4 = 登记时序㊼部署棒正持有全局执行锁（23:43 起）⇒ 按 R9 纪律不并发写它也会改的文件（入口 §0/§2、日志）。

0. 先纠正一个事实（否则判断会建立在错前提上）

用户前提「拍板结论 = C ＋ D，首选 D-1」与实测事实不符：

项	实际状态
C（域分离）	✅ 已落地（序㊻，本机全绿；部署棒序㊼正在上生产）
D（低熵块非确定性）	🔴 未实现 —— 序㊺用真实内容实测判「D 的作用面为空」：首屏包 23 块 / 0 低熵块；60 份真实小内容 / 0 份低熵 ⇒ `D-1` 无对象可稀释、`D-2` 前提不成立

⇒ "C ＋ D" 目前实际只有 C。 这一点对下面的评估很重要 —— 因为本需求第 1 层本质上是给 D 找一个代价可接受的落点。

1. 本需求要解决的，与"已实测证伪"的那条结论是不是同一件事

🔴 不是。这是本次评估最关键的一条。

威胁模型	内容	现状
甲 · 相等性泄露 / 低熵枚举	确定性（收敛）加密 ⇒ 同明文同钥得逐字节相同密文 ⇒ 「这两块是同一份内容」对外可见；低熵内容可被字典枚举	🔴 已实测成立（序㉛：10,000 块 / 100 值域 ⇒ 只剩 100 种密文；定稿口径 = 「中继看不到明文」成立、「内容不可推断」不成立）
乙 · 密钥失窃	密钥被抄走 / 失陷节点外泄	本需求第 1/2/3 层全部属于这一类

⇒ 随机轮换、多路分发、诱饵密钥，三条都是「乙」的加固；它们都不解决「甲」。 不能替代对低熵问题的处理，只能叠加。

2. 逐层评估

第 1 层 · 随机时间换钥 —— ✅ 建议采纳（形态需收窄）

买到的：把「甲」的泄露限制在单个 epoch 内 —— 跨 epoch 无法关联，每个 epoch 必须单独枚举 ⇒ 攻击总成本 × epoch 数。
买不到的：单 epoch 内的泄露照旧（同一 epoch 里低熵内容仍暴露）。
🔴 代价（最关键）：轮换会把块 id 全部换掉 ⇒ 去重归零。 块 id = f(密文)，换钥 ⇒ 密文变 ⇒ 序㉛实测轮换后块 id 改变 24/24 = 100%，首轮回源立刻回到 1 份 × 组数（E1 口径）。⇒ 轮换不是免费的安全旋钮 —— 它每秒都在花掉这套内容层存在的全部理由（回源字节 ≈ 1 份 × 组数）。
"随机时间"本身增益有限：固定周期同样有"限定窗口"效果；且 epoch 边界随凭据公开，对手可观察到换钥。随机的真实价值 = 不可预测（防卡点抓快照）。 ⇒ 建议形态：随机「间隔」而非随机「时刻」（如 6–24 h 内均匀抽），既不可预测又不至于频繁到吃掉去重收益。
🔑 与 D 的关系（关键洞察）：轮换 = 按时间窗做的 D。D 是逐次加密随机化 ⇒ 去重全死；轮换保留 epoch 内去重。⇒ 本层实质是给 D 找一个代价可控的粒度，方向正确。

第 2 层 · 经不同节点 / 打洞设备更新密钥 —— 分两半，一半可立即做，一半过 R5

✅ 可立即做（零暴露面变化）：凭据多路分发。凭据 = 签名的 (network, group, epoch, keyId) 元组，不含密钥本体 ⇒ 走节点 / 打洞路径分发它，安全上无新增暴露面。
🔴 须过 R5（权限扩大）：密钥本体经网络。现行硬规则 = 密钥本体 ⛔ 不经网络、⛔ 不经 relay（走带外 0600 文件）。要经节点传，必须用接收方公钥包裹（wrap）密钥，否则中继直接看到密钥本体 ⇒ 暴露面扩大，须先出「权限影响评估」并取得确认。
⚠️ 要认清它买到什么：节点之间本就在同一信任域（同一 (network, group)），已失陷的节点本来就持有密钥 ⇒ 多路分发不提升对节点失陷的抗性；它提升的是 ① 抗关联（不再人人从 Manager 取）② 可用性（Manager 不可达时仍能换钥）③ 走直连的时延/带宽。三条都是真价值，但不要当作"更难破解"。

第 3 层 · 多份候选密钥、只有一份真 —— ⛔ 建议暂不采纳（两个硬理由）

它不解决「甲」：相等性泄露源于密文相同，与"钥匙被偷"无关；诱饵只提高"偷到一把钥匙"的成本。
有自毁条件：只要"哪份是真的"随密文或凭据一起走 ⇒ 诱饵立刻失效；不随行 ⇒ 每个节点必须逐把试解（N× 解密开销）。而"分发通道会被观察"恰恰是本场景的假设（relay 就在那条路上）。 ⇒ 除非先设计出「密钥包裹＋真伪不落可见面」，否则 = N 倍复杂度换 0 倍抗性。

3. 建议的实现形态（已定项 · 可推翻）

随机间隔轮换（6–24 h 均匀抽）＋ 保留 epoch 内去重 ＋ 预热可调度（避免回源峰值撞上业务高峰）。
凭据多路分发先做（零暴露面变化）。
密钥本体的网络化分发＋诱饵分发 = 单独立项、先出权限影响评估（R5）。

4. 实现前必须由用户定的一条（⛔ 现在不问，留到规划棒开工前）

轮换周期口径 = 安全窗口 vs 回源放大（本层唯一无客观优劣的取舍）：

候选 A · 不轮换（现状） —— 优点：回源最小、零新增复杂度。缺点：「甲」无期限累积，低熵内容长期可枚举。
候选 B · 随机 6–24 h —— 优点：泄露窗口有界且不可预测，代价可控（每天最多几次预热）。缺点：每天数次回源峰值，需 epoch 预热调度。
候选 C · 随机 1–6 h —— 优点：窗口更紧。缺点：预热频繁、回源放大明显，可能吃掉 E1 的收益。

5. 落地前的取证清单（规划棒开工时先做，⛔ 别凭记忆）

现 CONTENT_EPOCH_* 键的现值与语义（参数表 §3.9 六键）—— 轮换周期是新增键还是复用既有键？⛔ 不许猜。
轮换 → 块 id 换代这条耦合是否要拆（即：netKey 是否应随组密钥轮换而变）。⚠️ 序㊻的 C 把 netKey 从组密钥派生 ⇒ 当前是"换钥 ⇒ id 换代"；若要"换钥但 id 稳定"，需改派生口径 ⇒ 又是一次 id 换代（有代价）。
加密性能已实测基线（+20.1 ms / 10.8 MB 包）；轮换的预热成本已有 E1 形态（首轮 1 份 × 组数、次轮 0）。

6. 边界自证

⛔ 本文件只登记需求，零实现（未改任何源码 / 配置 / 生产）；⛔ 未 commit / 未 push；⛔ 未触碰入口 §4 / 交接单 / 工作区日志（因序㊼部署棒持有执行锁，避免并发写覆盖）。

7.5 KiB Raw Blame History Unescape Escape