信封与归档
Anpio Key 有两种看起来很像、用途完全不同的文件。
信封 keys/<thumbprint>.json | 归档 <thumbprint>.anpkeyd.json | |
|---|---|---|
| 是什么 | 钥匙在这台机器上的加密存放形式 | 把身份搬到另一台机器的加密文件 |
| 用什么解开 | 口令 + device.secret（绑硬件时再加芯片材料） | 导出时设置的那个独立口令 |
| 能直接换机器吗 | 不能只拷这一个文件 | 能，设计上就是可移植的 |
| 口令能复用吗 | 能，是日常口令 | 不能，必须单独设置 |
| 谁生成 | keygen 或导入 | export-seed，默认构建里没有 |
只拷信封不够
解封信封还需要同一目录下的 device.secret。把 keys/ 单独拷到另一台机器，那边的 device.secret 不一样，信封打不开。
反过来，把整个软件目录连同 device.secret 一起拷走，并且知道口令，就能在另一台机器上解开。所以整套目录和口令一样敏感。
绑了硬件会多一路材料
硬件根把一份解封材料放进芯片，磁盘上没有：
text
KEK = HKDF-SHA256( argon2id(口令) ‖ device.secret ‖ HS, salt )三样少一样都打不开。细节见硬件根。
归档是什么
归档是“把身份带走”的文件，只有导出时的那个口令保护，不依赖原机器的 device.secret 或硬件。
因此：
- 归档文件本身可以被离线暴力破解，强度只取决于口令和 Argon2id 成本；
- 导出时强制要求一个不弱的口令；
- 导出只执行一次，不提供重试循环；
- 归档口令必须和日常口令不同。
导入之后要知道两件事
- 导入出来的是同一把钥匙，不是副本。 两台机器都能签，对方分不出来。旧机器上那份要处理掉。
- 导入会用新机器的
device.secret和新口令重新封装。 旧归档仍然能用旧归档口令打开，不会因为导入而失效。
两个格式已经冻结
助记词方案 bip39-entropy-v1 和归档格式 anp-keyd-archive v1 一旦发布就不能改。改了不是报错，是用户手里的旧备份打不开。
24 个 BIP-39 词直接编码 32 字节 seed，不使用标准 BIP-39 的 PBKDF2 派生。用其他钱包的 to_seed 可能得到另一把钥匙，而且不会报错。细节见设计说明第三节。