Livara v7 密钥恢复：身份与聊天记录并不相同

恢复加密身份、重新登录账户和恢复聊天记录是三件不同的事。根据 Livara 安全文档，v7 格式用于恢复加密身份；这一格式本身并不会恢复聊天记录。

此外，也不应将这一架构描述为“完全没有云备份”。当前文档说明，身份材料先在设备上加密，再作为加密备份上传。重要区别在于：服务器存储的是可读密钥，还是必须使用恢复密钥才能解开的加密副本。

三扇门，并不共用一把钥匙

操作	目标	为什么还不够？
账户登录	证明有权访问服务账户	不一定提供解密以往消息的密钥
身份恢复	重新访问加密身份材料	本身不能证明所有消息都存在或可恢复
历史恢复	找回所需消息和附件	除密钥外，还需要数据本身及受支持的恢复方式

这种区分可以避免一个代价高昂的错误：以为知道登录密码就足以找回全部对话，因此擦除旧手机。

v7 文档究竟说了什么？

Livara 的安全页面说明，P-256 密钥协商和签名密钥以及 ML-KEM 种子，会在设备上使用一个随机的 256 位恢复密钥进行加密。在 v7 格式的描述中，算法套件、身份纪元和代次也经过身份验证。这是厂商文档，本身不构成对实现的独立审计。

Livara 威胁模型指出，打开密钥备份必须使用恢复短语。不应从这一说明中猜测将短语转换成密钥的具体算法，或推断可以直接重建全部密钥。实际操作细节必须与应用版本及该版本的指南相对应。

为什么派生函数不能让弱短语变强？

函数的输出长度，不等于输入的不可猜测程度。RFC 5869明确指出，HKDF 会集中已有熵，但不会增加熵。因此，不能宣称任意自选短语经过 HKDF 后，就自动获得完整的 256 位安全强度。

不要擅自缩短、改写应用官方流程生成的短语，也不要用容易猜到的句子替换它。不要将它发送给任何人、客服机器人或未知表单。

更换或擦除手机之前

1. 在应用中确认备份了什么：身份、历史记录，还是通过不同方式分别备份了两者。
2. 将恢复短语保存在安全且独立于该手机的位置；应将他人获取它视为严重风险。
3. 阅读当前版本的恢复指南。不要仅凭“登录成功”就认为已经完全恢复。
4. 如果支持恢复测试方法，请先使用非敏感数据测试，不要擦除唯一现存副本。
5. 迁移后，检查所需的对话和文件，再决定是否停用旧设备。

如果没有恢复短语怎么办？

如果仍持有已授权设备，只查看该应用内现有的官方途径；在没有检查具体版本前，不应假定可以创建新备份。如果设备和短语都已丢失，Livara 文档并未承诺能够恢复密钥。不要把任何“保证解密”服务当成突破这一边界的替代办法。

规划账户迁移时，应先问“哪些数据会使用哪把密钥、从哪个备份恢复？”，而不是假定重新登录就等于全部聊天回来了。