压缩加密存档设计

安全且可检索的长期存档框架：集成容器化与密码学

摘要

本报告提出了一个工程框架，用于将存档容器化（压缩与格式化）与强健的密码学（静止加密）相集成。我们分析了在长期保存、数据安全以及日益增长的智能体自动化、高性能检索需求之间的基本权衡。我们提出了一个“解耦”的架构模型，将 容器层 与 密码学层 分离，以确保算法的敏捷性和面向未来的兼容性。本分析综合了来自 NIST、IETF 和 ISO 的标准，以及行业标准实现（PKWARE, Microsoft）的规范，为文件级、卷级和混合型存档策略建立了规范性基线。

I. 解耦原则：面向长存的架构基础

工程实践的核心原则应是将数据结构（容器层）与数据保护（密码学层）在架构上解耦。

容器层 (The "Box")： 其功能是结构化数据。该层负责文件装配、元数据承载和提供可寻址结构。它由 PKWARE 的 APPNOTE（定义 ZIP）和 Microsoft 的 Open Packaging Conventions (OPC) 等规范来定义。其关注点是结构完整性、元数据表示和基于偏移的访问。

密码学层 (The "Lock")： 其功能是保护数据。该层负责机密性、完整性和认证。它由 NIST FIPS 140-3、SP 800 系列和 IETF RFCs 等密码学标准来定义。其关注点是机密性（如 AES）、完整性（如 HMAC, SHA-2）和密钥派生（如 PBKDF2, Argon2id）。

推动这种解耦的主要驱动力是算法敏捷性 (Algorithmic Agility)。这是一个关键的考量：密码学标准和算法的失效（即变得不安全）速度远快于容器格式标准。

一个旨在保存 50 年的存档，其容器格式（如经 ISO 标准化的 ZIP）极有可能在 50 年后仍可读取 [iso.org]。然而，一个密码学算法（如早期的 ZipCrypto，甚至用于完整性的 SHA-1）在此期间极有可能被攻破。

如果密码学与容器被紧密绑定，密码学的失效将使整个存档失效。通过解耦，组织可以执行“密码学重构”（Cryptographic Re-tooling）——例如，使用新的密码或新的哈希算法重新加密或重新签名容器——而 无需 重新打包或迁移底层的容器数据本身。这极大地降低了长期维护的成本和风险。

II. 容器层：标准、压缩与检索

本节探讨存档的物理结构，重点关注格式选择如何直接影响“未来智能体/自动化检索”的目标。

II.A. ZIP 格式：面向检索的标准

对于自动化检索而言，ZIP 格式最重要的特性是其**“中央目录” (Central Directory)**。根据 PKWARE APPNOTE 规范，中央目录是一个独立的结构，通常位于文件的 末尾，其作用相当于一个清单 [pkware.cachefly.net]。

智能体可以 仅 读取中央目录来枚举存档的 全部内容（文件名、偏移量、压缩方法），而无需解析整个文件。这使得无论存档大小如何，都能实现近乎 $O(1)$ 的列表性能。

标准化是确保长期可读性的关键。ISO/IEC 21320-1（文档容器文件）引用了 ZIP 规范 [iso.org]。此外，Microsoft 的 Open Packaging Conventions (OPC)（被所有现代.docx,.xlsx 文件使用）选择 ZIP 作为其物理层。这是对 ZIP 作为 基础平台 作用的有力验证，确保了主流技术供应商（如 Microsoft）在可预见的未来将继续维护 ZIP 工具链。

对于现代应用，ZIP64 扩展是强制性要求，以支持超过 4GB 的存档 [pkware.cachefly.net]。

II.B. 压缩策略：平衡比率、速度和标准

压缩算法的选择直接影响检索性能。

DEFLATE (Method 8): 历史上的默认选项，兼容性强，但性能已被现代算法超越 [pkware.cachefly.net]。

Zstandard (zstd, Method 93): Zstandard（方法 93）被纳入 ZIP 规范，其关键优势在于卓越的 解压速度，这对于检索密集型工作负载至关重要 [pkware.cachefly.net]。IETF RFC 8878 对 zstd 进行了标准化，将其从“一种新算法”提升为“正式规范的标准”，符合非专有长期保存的要求。

7z 与固实压缩 (A Cautionary Analysis):
7z 格式（如 LZMA/LZMA2）提供高压缩比，但其“固实”（Solid）压缩模式与自动化检索的目标存在 直接冲突。固实块将所有文件视为单个数据流。
这种设计导致了“依赖链”：

要从固实存档中检索第 1000 个文件，解压器必须从第 1 个文件（或固实块的起点）开始，并解压所有先前的数据（文件 1-999）。

这使得 随机访问（从中间检索单个文件）的计算成本极高且速度缓慢。

它还严重影响 容错性。压缩流中的一个单位错误就可能导致该块中 所有后续文件 无法恢复。

结论：对于优先考虑自动化检索和长期稳健性的存档，必须 禁用 固实压缩，或使用极小的固实块。

表 1：面向自动化检索的容器格式权衡

III. 密码学层：机密性、完整性与密钥管理

本节详细介绍“锁”本身，从数据 如何 加密转向数据 如何 验证。

III.A. 模型 1：文件级（容器原生）加密

ZIP (AE-x): WinZip AE-1/AE-2 规范（方法 99）是开放的 ZIP 标准的一部分 [winzip.com, pkware.cachefly.net]。这 不是 已被破解的传统 ZipCrypto。AE-x 指定使用 AES 进行加密，并使用 HMAC-SHA1 进行认证。这是一个安全的现代“加密后认证”(Encrypt-then-MAC, EtM) 结构。

7z (AES-256): 7z 规范使用 AES-256-CBC 和基于 SHA-256 的 KDF。

元数据权衡： 7z 的“加密文件名/加密头”选项提供了卓越的元数据隐私（隐藏目录结构）。但是，这（如同 ZIP 的“中央目录加密”）使存档变得“不透明”，禁用 了快速、未经身份验证的列表功能。这与“智能体检索”的目标直接冲突。

III.B. 模型 2：卷级（不透明）加密

此模型（例如 VeraCrypt 容器、磁盘加密）通常使用 XTS-AES 模式。根据 NIST SP 800-38E (Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices)，XTS 模式存在一个关键的局限性。

XTS 模式被设计 仅 用于提供机密性。它 不是 一种认证加密（AEAD）模式，不提供 任何数据完整性或真实性验证。XTS 模式是“可延展的”（malleable）。攻击者可以“翻转”磁盘上的密文位；当该 XTS 加密块被读取时，它 不会 产生解密错误，而是会 成功 解密为 不同的、已损坏的 明文。

对于必须能够区分“数据损坏”（磁盘错误）和“数据篡改”（安全漏洞）的档案系统而言，这种容忍度是不可接受的。因此，单独使用 XTS-AES 进行归档是 不完整的 甚至 危险的，除非 强制性地与一个 外部认证层（见第四节）配对。

III.C. 模型 3：认证加密 (AEAD)

黄金标准是 NIST SP 800-38D (Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC)。

像 AES-GCM 这样的 AEAD 模式是首选的密码学原语。它们在一次高效的传递中同时提供机密性和认证，并且比分离的 Encrypt-then-MAC 结构更不容易出现实现错误。

IV. 长期可验证性：证明完整性、真实性与时效性

本节解决了卷级加密（如 XTS）留下的完整性空白，并提供了长期保存所需的“可验证性”。

IV.A. 完整性 (The "What"): 哈希清单

标准： FIPS 180-4 (Secure Hash Standard)。

实现： 在加密 之前 创建一个“清单”文件（例如 sha256sum.txt）。此清单包含存档中每个文件的 SHA-256（或更强）哈希值。该清单随存档一起存储，允许在解密后进行完整的完整性检查。

IV.B. 真实性 (The "Who"): 数字签名

标准： IETF RFC 5652 (Cryptographic Message Syntax - CMS)，PKCS#7 的继任者。

实现： 必须对 哈希清单本身 进行数字签名。这证明了“正确”哈希值的列表是由受信任的实体（例如归档系统）生成的。这可以防止攻击者简单地创建一个新存档，为 恶意 文件生成一个新的 有效 哈希列表，并替换原始清单。

IV.C. 时效性 (The "When"): 可信时间戳

这是一个关键但经常被忽视的步骤，用于防范“回溯签名攻击”。数字签名证明了 谁 签署了 什么，但不能证明 何时 签署。

如果一个签名密钥被泄露，攻击者可以创建恶意存档，用被盗密钥签名，并将系统时钟回溯。这使其看起来像是在密钥泄露 之前 由受信任来源签署的有效存档。

解决方案： IETF RFC 3161 (Time-Stamp Protocol - TSP)。

实现： 在签署清单（RFC 5652）后，立即将签名的哈希发送到受信任的时间戳管理局 (TSA)。TSA 返回一个 签名的 时间戳令牌，该令牌与签名进行密码学绑定。这 证明 了该签名（以及存档清单）在特定时间点已经存在。这对于法律和合规性上下文至关重要。

IV.D. 密钥派生 (The "Password"): KDF

将低熵的人类密码转换为高熵的加密密钥需要安全的密钥派生函数 (KDF)。

标准 1 (基线)： NIST SP 800-132 (Recommendation for Password-Based Key Derivation)。该标准规范了 PBKDF2。PBKDF2 是“CPU 密集型”的，通过强制高迭代次数来增加计算难度。

标准 2 (现代)： IETF RFC 9106 (Argon2 Key Derivation Function)。

Argon2 (特别是 Argon2id) 之所以更优越，在于它是“内存密集型”的。PBKDF2 的 CPU 密集型计算很容易被 GPU/ASIC 阵列并行化，攻击者每秒可以检查数十亿个密码。而 Argon2id 需要大量 可配置 的 RAM 来计算。这对于合法用户的 PC 来说微不足道，但对于攻击者在 GPU/ASIC（每个处理核心的 RAM 都很少）上进行大规模并行化来说，成本极其高昂。对于长期存档，Argon2id 是抵御强力破解的更优选择。

表 2：密码学模型比较

注：7z 的 KDF 是专有迭代方案；VeraCrypt 明确提供了 Argon2id 和 PBKDF2 选项。VeraCrypt 的“认证 (完整性)”单元格明确指出其 固有缺陷。

V. 集成工程基线：规范性堆栈

本节将所有先前的分析综合为可操作的、分层的建议。

V.A. 基线 1：检索优化 (元数据公开)

用例： 内部智能体的最高检索性能；元数据（文件名、结构）不敏感。

技术堆栈：

容器： ZIP (启用 ZIP64)。

压缩： Zstandard (Method 93, 遵从 RFC 8878)。

加密： ZIP AE-2 (Method 99, AES-256 + HMAC-SHA1)。

KDF： Argon2id (RFC 9106) 或 PBKDF2 (NIST SP 800-132)。

智能体交互： 智能体可以读取 未加密 的中央目录以实现即时列表，然后按偏移量请求 特定 文件的解密。

V.B. 基线 2：隐私优化 (元数据私密)

用例： 高安全性；存档结构和文件名是敏感的，必须隐藏。

技术堆栈：

容器： 7z (非固实或小块固实)。

压缩： LZMA2 或 Zstandard。

加密： 7z AES-256 并 启用“加密头”。

KDF： 7z 原生 (基于 SHA-256 的迭代)。

智能体交互： 智能体必须 完全解密 头部（需要密钥）才能列出文件。这是安全的，但速度慢。

V.C. 基线 3：批量存储 (卷级)

用例： 归档海量、不透明的数据块（例如磁盘镜像、大型科学数据），文件级粒度不太重要。

技术堆栈 (按顺序)：

数据： 创建存档 (例如 ZIP) 和 SHA-256 清单。

签名： 创建清单的 CMS 签名 (RFC 5652)。

时间戳： 对签名应用 RFC 3161 时间戳。

容器： 将数据、清单、签名和时间戳令牌放入 VeraCrypt (或类似) 卷中。

加密： 使用 XTS-AES 加密该卷，密钥通过 Argon2id 派生。

智能体交互： 智能体必须挂载该卷（需要密钥），然后 必须 手动 针对已签名/时间戳的清单来验证检索到的文件。这是用于批量数据最“繁琐”但 可验证性最强 的方法。

V.D. 混合解决方案：“旁路索引” (Bypass Index)

此模型解决了基线 1 (快速/泄露) 和基线 2 (缓慢/私密) 之间的冲突。

完全加密的存档（如基线 2 或 3）对智能体来说是一个“黑匣子”。智能体不需要 内容，但它需要 索引 来完成工作。

实现：

使用基线 2 或 3 归档数据（完全加密，元数据隐藏）。

生成一个 独立 的 JSON 或 XML“旁路索引”文件。此文件 仅 包含发现所必需的元数据（例如，文件路径、MIME 类型、创建日期、加密容器内的文件偏移/块号，以及明文的 SHA-256 哈希）。

然后 单独 加密和签名此 索引文件。

智能体交互： 授权的智能体被授予 仅访问索引文件 的密钥。它可以解密这个小文件，执行快速查询（“查找 2023 年的所有 PDF”），并识别所需数据的 确切位置（例如，“存档 2023.7z，第 512 块”）。然后，智能体可以从操作员或更安全的密钥管理系统请求 仅解密该块。这在不损害静止数据机密性的前提下提供了发现能力。

VI. 操作优先级与结论性原则

VI.A. “先压缩后加密”的强制规定

这是一个必需的操作顺序，其基础是信息论。

压缩的工作原理是查找和减少 冗余（模式）。

安全的密码学函数（如 AES）产生的输出在计算上与 随机噪声 无法区分。此输出具有最大 熵 且没有可辨别的模式。

结论：

先压缩后加密 (正确)： 压缩减少了明文大小。随后在较小的数据集上执行加密，节省了计算、存储和传输成本。

先加密后压缩 (错误)： 加密数据（随机噪声）无法 被压缩。在密文上运行压缩算法，充其量无法减小大小，最坏情况下甚至可能因开销而 增加 大小。

这是一个不可协商的操作顺序。

VI.B. 恪守柯克霍夫原则 (Kerckhoffs's Principle)

该原则指出：“即使密码系统的所有细节（除了密钥）都已公开，它也应该是安全的。”

本报告中提出的整个框架都遵循这一原则。每个组件（ZIP, ISO, Zstd/RFC 8878, AES/NIST, SHA/FIPS, CMS/RFC 5652, TSP/RFC 3161, Argon2id/RFC 9106）都是 公开、开放、经过国际审计的标准。

此存档的长期安全 不 依赖于使用秘密或专有工具。它 仅 依赖于密码学密钥的保密性和强度，以及对这些公共标准的规范化实施。这确保了即使最初的供应商或软件不复存在，数据在几十年后仍然是可恢复的，因为规范本身就是检索的“源代码”。

VII. 参考文献

IETF RFC 8878: Zstandard Compression

IETF RFC 9106: Argon2 Key Derivation Function

IETF RFC 5652: Cryptographic Message Syntax (CMS)

IETF RFC 3161: Time-Stamp Protocol (TSP)

ISO/IEC 21320-1: Document container file — Part 1: Core

Microsoft Corporation: Open Packaging Conventions (OPC) Documentation

NIST FIPS 180-4: Secure Hash Standard (SHS)

NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC

NIST Special Publication 800-38E: Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices

NIST Special Publication 800-132: Recommendation for Password-Based Key Derivation (PBKDF2)

NIST Publications (NIST Computer Security Resource Center)

PKWARE, Inc.:.ZIP Application Note (APPNOTE.TXT)

WinZip International LLC: AES Encryption Information: Encryption Specification AE-1 and AE-2

7-zip.org: 7z Format Specification (Documentation Help)