systemslibrarian/PostQuantum.FileFormat

# PQF — 后量子文件格式 PQF 是一项针对静态混合后量子加密文件的规范和参考实现。 [](https://github.com/systemslibrarian/PostQuantum.FileFormat/actions/workflows/ci.yml) [](https://github.com/systemslibrarian/PostQuantum.FileFormat/actions/workflows/codeql.yml) [](https://github.com/systemslibrarian/PostQuantum.FileFormat/actions/workflows/differential.yml) [](https://github.com/systemslibrarian/PostQuantum.FileFormat/actions/workflows/reproducible-pack.yml) [](https://www.nuget.org/packages/PostQuantum.FileFormat.Cli/) [](https://www.nuget.org/packages/PostQuantum.FileFormat.Cli/) [](LICENSE) [](spec/PQF-SPEC-v1.md) [](https://securityscorecards.dev/viewer/?uri=github.com/systemslibrarian/PostQuantum.FileFormat) [](https://codecov.io/gh/systemslibrarian/PostQuantum.FileFormat) [](LICENSE) ## 快速开始 将预览版 CLI 作为 [.NET global tool](https://learn.microsoft.com/dotnet/core/tools/global-tools) 安装（需要 **.NET 10+ runtime** — BCL 原生的 ML-KEM 和 ML-DSA API 是必需的）： ``` dotnet tool install --global PostQuantum.FileFormat.Cli --prerelease ``` 然后端到端地加密和解密文件： ``` pqf keygen --type encrypt --public-out alice.pub.pem --private-out alice.key.json pqf encrypt --in secret.pdf --out secret.pqf --recipient alice.pub.pem pqf inspect --in secret.pqf pqf decrypt --in secret.pqf --out secret.dec.pdf --identity alice.key.json --mode authenticated ``` ## 如何试用 这是一个独立的完整往返流程，你可以直接将其粘贴到全新的 shell 中。它会创建一个一次性的工作目录，生成一个示例明文，对其进行加密和签名，检查容器，在 Authenticated Mode（认证模式）下解密，并确认输出与输入逐字节匹配。 ``` # 安装 CLI（如已安装可跳过） dotnet tool install --global PostQuantum.FileFormat.Cli --prerelease # 设置一个 scratch 目录 mkdir -p /tmp/pqf-demo && cd /tmp/pqf-demo # 生成接收者 encryption keypair 和签名 keypair pqf keygen --type encrypt --public-out alice.pub.pem --private-out alice.key.json pqf keygen --type sign --public-out signer.pub.pem --private-out signer.key.json # 创建一个示例明文 echo "hello post-quantum world" > sample.txt # 加密并签名 pqf encrypt --in sample.txt --out sample.pqf \ --recipient alice.pub.pem \ --signing-key signer.key.json # 在不解密的情况下检查容器 pqf inspect --in sample.pqf # 在 Authenticated Mode 中解密（在释放明文前进行验证） pqf decrypt --in sample.pqf --out sample.out.txt \ --identity alice.key.json \ --mode authenticated # 确认往返过程 diff sample.txt sample.out.txt && echo "OK: roundtrip verified" ``` 清理命令：`cd ~ && rm -rf /tmp/pqf-demo`。 ## 本项目是什么 - 一项**文件格式规范**（[spec/PQF-SPEC-v1.md](spec/PQF-SPEC-v1.md)，草案 v0.6.0）。 - 一个在 .NET 10 中的**参考实现**（[src/PostQuantum.FileFormat](src/PostQuantum.FileFormat)）。 - 一个**命令行工具** `pqf`（[cli/PostQuantum.FileFormat.Cli](cli/PostQuantum.FileFormat.Cli)）。 - 一个**确定性编码、失败即关闭的解析器**，没有恢复路径。 - 一个**测试向量与一致性模型**（[tests/PostQuantum.FileFormat.TestVectors](tests/PostQuantum.FileFormat.TestVectors)），用于根据规范对实现进行门控测试。 ## 本项目不是什么 - 不是 TLS 或任何传输安全协议。 - 不是消息传递协议。 - 不是磁盘或卷加密方案。 - 不是匿名或元数据隐私系统。 - 不是经过生产认证的加密技术。该格式和代码尚未经过外部密码学审查。 ## 核心属性 - **设计上失败即关闭：**任何格式错误的结构、未知字段、保留位、长度不匹配或完整性验证失败，都会导致立即拒绝并返回类型化错误。不存在尽力而为或宽松的解析路径。 - **混合后量子加密：**按照 draft-connolly-cfrg-xwing-kem 标准采用 **X-Wing** (X25519 + ML-KEM-768)，在 ROM/QROM 中具有外部 IND-CCA 证明（Barbosa 等人，2024）。没有定制的组合器。 - **混合签名（可选）：** Ed25519 + ML-DSA-87，固定 4691 字节的拼接布局。如果已签名，两半部分都必须验证通过。 - **确定性 CBOR header** 符合 RFC 8949 §4.2.2。非确定性编码将被拒绝。 - **分块的 AES-256-GCM payload**，具有按块派生的 HKDF 密钥、固定的零 nonce 和 AAD 绑定 `file_id || chunk_index || is_final`。 - **单一容器内的多接收者支持**，无需重复 payload。 - **两种解密模式：** - *Authenticated Mode*（认证模式，默认）：在向调用者发布任何明文之前，验证文件签名（如果存在）和 footer。 - *Streaming Mode*（流式模式）：在读取时发布已验证的块，如果 footer 或文件签名验证失败，会进行显式的、非静默的事后通知。调用者绝不能静默忽略流式传输失败。 - **失败即关闭的验证：**拒绝未知字段、长度不匹配、保留位、截断、尾部字节以及任何算法偏差。不存在宽松的路径。 ## 60 秒示例 ``` # 生成接收者 encryption keypair pqf keygen --type encrypt \ --public-out alice.pub.pem \ --private-out alice.key.json # 生成签名 keypair pqf keygen --type sign \ --public-out signer.pub.pem \ --private-out signer.key.json # 加密并签名文件 pqf encrypt \ --in secret.pdf \ --out secret.pqf \ --recipient alice.pub.pem \ --signing-key signer.key.json # 在不解密的情况下检查 header 和 footer 元数据 pqf inspect --in secret.pqf # 在 Authenticated Mode 中解密（在释放明文前进行验证） pqf decrypt \ --in secret.pqf \ --out secret.dec.pdf \ --identity alice.key.json \ --mode authenticated ``` - `.pqf` 是加密容器：包含 `PQF1` magic、确定性 CBOR header、可选的 4691 字节 header 签名、AES-256-GCM 数据块、20 字节的 footer，以及可选的 4691 字节文件签名。 - `pqf inspect` 解析并打印 header 和 footer，而不触碰明文。 - `--mode authenticated` 在发布任何明文之前缓存验证结果。`--mode streaming` 在读取时发布已验证的块，并显式呈现事后的验证失败。 生成的 `.pqf` 文件是一个独立的加密容器：它将接收者包装的密钥、分块密文、完整性元数据和可选的混合签名打包在一个单一的 byte stream 中。 ## 仓库结构 ``` spec/ Format definition and design rationale PQF-SPEC-v1.md Normative specification (v0.6.0 draft) PQF-DESIGN-RATIONALE-v1.md Why the spec is what it is ietf/ Internet-Draft skeleton (work in progress) src/PostQuantum.FileFormat/ Reference .NET implementation cli/PostQuantum.FileFormat.Cli/ `pqf` command-line tool impl/rust/pqf-reader/ Second-source Rust reader + cross-impl gate tests/PostQuantum.FileFormat.TestVectors/ Deterministic interoperability vectors tests/PostQuantum.FileFormat.Tests/ Validation, refusal, and roundtrip tests tests/PostQuantum.FileFormat.Cli.Tests/ CLI integration tests tests/PostQuantum.FileFormat.Fuzz/ Lightweight parser fuzz harness tests/PostQuantum.FileFormat.Kat/ NIST KAT (FIPS 203 / FIPS 204) cross-check harness examples/ Short integration scripts (e.g. tar | pqf encrypt) scripts/smoke.sh End-to-end roundtrip + refusal-path script (run by CI) docs/ Threat model, compatibility policy, side-channel posture SPEC-CHECKLIST.md Per-section conformance checklist CONTRIBUTING.md How to file spec reviews, bugs, and PRs SECURITY.md Security-reporting policy and supported versions CODE_OF_CONDUCT.md Contributor Covenant 2.1 ``` ## 安全模型 - **机密性：**如果*经典* (X25519) 或*后量子* (ML-KEM-768) 原语中*有任何一方*未被攻破，则机密性得以保持。攻破其中一半不会危及另一半。 - **真实性：**仅在文件被签名时存在。签名后，Ed25519 和 ML-DSA-87 都必须验证通过；任何一方失败都会拒绝该文件。 - **不提供匿名性保证。**PQF 保护静态文件内容；它不会隐藏 `.pqf` 文件的存在、接收者是谁或传输层元数据。 - **元数据是可见的。**header 未加密，包含算法 ID、接收者公钥材料、签名者公钥（签名时）、`chunk_size` 和 `created` 时间戳。请将其视为可见。 - **侧信道姿态继承自底层原语。**参考实现被配置为在释放数据前进行验证，并在接收者块上以恒定时间运行接收者尝试。ML-KEM-768 和 ML-DSA-87 由 .NET 10 上的原生 BCL 类型（[`System.Security.Cryptography.MLKem`](https://learn.microsoft.com/dotnet/api/system.security.cryptography.mlkem) 和 [`MLDsa`](https://learn.microsoft.com/dotnet/api/system.security.cryptography.mldsa)）提供支持，这些类型由平台提供底层支持（Linux 上通过 libcrypto 使用 OpenSSL 3.5+；Windows 11 / Server 2025 上使用 CNG），并且是目前可用的最强实际侧信道防御姿态。BouncyCastle 仅作为 X25519、Ed25519 和用于字节确定性测试向量重新生成的 FIPS 204 *确定性* ML-DSA 签名路径的依赖项保留——BCL 目前尚未原生公开这些内容。完整的单次操作矩阵——wrapper 控制的内容和它继承的内容——记录在 [docs/SIDE-CHANNEL-POSTURE.md](./docs/SIDE-CHANNEL-POSTURE.md) 中。 - **实现正确性至关重要。**该格式在设计上是失败即关闭的，但安全性仍然取决于对规范、底层 KEM/AEAD/签名原语以及主机操作系统随机源的的正确实现。 ## 一致性理念 - **严格解析。**拒绝任何 header 级别的未知字段。宽松的 CBOR 解析是不符合规范的。 - **要求确定性编码。**Header 必须能够逐字节重新编码；拒绝非确定性输入。 - **MUST 级别的强制执行。**规范中的每个 `MUST` 都对应于读取器中的一条拒绝路径，并由负面测试向量和拒绝测试套件进行测试。 - **没有静默恢复。**不存在“尽力而为”的路径。任何偏离规范的操作都会以显式的、类型化的错误终止处理。 - **一致性是可测试的。**[SPEC-CHECKLIST.md](SPEC-CHECKLIST.md) 列举了规范性项目。该实现根据 [tests/PostQuantum.FileFormat.TestVectors](tests/PostQuantum.FileFormat.TestVectors) 下提交的测试向量进行门控。 ## 性能 基于单台机器 `BenchmarkDotNet` 运行的指示性数据，环境为 .NET 8.0.27 / Windows 11。**这不能替代在你自己的硬件上进行测量** —— 加密吞吐量主要取决于原语实现，其常数因子因 CPU 而异。基准测试 项目是 `tests/PostQuantum.FileFormat.Bench`；那里的 README 解释了如何重现。 | 操作 | 64 KiB | 1 MiB | 16 MiB | |---|---:|---:|---:| | `Encrypt_unsigned` (单接收者) | ~1.1 ms | ~2.2 ms | ~18 ms | | `Decrypt_authenticated` (单接收者) | ~0.93 ms | ~2.3 ms | ~29 ms | | `Parse_header_only` | ~9 µs (与明文大小无关) | — | — | 在 16 MiB 明文下，单核加密速度约为 **0.9 GiB/s，解密速度约为 0.6 GiB/s**，这对于静态文件使用场景来说足够快，但对于线速磁盘 流式传输来说不够快。这种不对称性——解密比加密慢——来自于 Authenticated Mode 的“先验证后释放”契约：当超出其阈值时，读取器会将明文暂存到 0600 tempfile 中，以便在释放任何字节之前验证文件签名。 多接收者开销（64 KiB 明文，相同机器）： | 接收者数 | 加密 | 作为首个解密 | 作为末个解密 | |---:|---:|---:|---:| | 1 | ~1.1 ms | ~0.98 ms | ~1.04 ms | | 4 | ~2.8 ms | ~3.2 ms | ~3.2 ms | | 16 | ~12.0 ms | ~10.4 ms | ~11.3 ms | | 64 | ~41.3 ms | ~39.3 ms | ~39.9 ms | 正如预期的那样，加密在 N 上的扩展性约为线性——每个 接收者对应一对 X25519/ML-KEM。**解密在 N 上也是约线性的**，这是 因为接收者尝试循环遍历每个块，以保持时间独立于 *哪个*接收者持有 DEK。“作为首个解密”与“作为末个解密”之间的差距在每个 N 时都处于底噪水平——这正是设计发挥作用的地方。 ## 当前实现限制 - 旧的 `PqfFileReader.OpenForValidation` helper 仍然在完全实例化的 byte buffer 上运行（为测试和已经将文件加载到内存中的调用者保留）。生产环境的解密现在通过 `PqfStreamingPipeline` 进行，它直接从 `Stream` 读取：只有 header（根据规范 ≤ 1 MiB）和一个正在传输的 chunk（≤ 16 MiB + AEAD tag）会被缓存。Authenticated mode 仍会将大于 100 MiB 的明文暂存到 0600 模式的 `DeleteOnClose` tempfile 中，以便在释放任何字节到目标之前验证文件签名——这种暂存是安全模型要求的，而不是解析器要求的。 ## 状态 - **状态：**实验性。规范目前处于草案 v0.6.0。 - **未经外部审计。**尚未进行独立的密码学审查。 - **不建议用于不可替代的数据。**字节格式仅在 v1.0.0 冻结；草案版本生成的文件可能无法被最终版本读取。 - **最新预览版：**`main` 分支上的 [`v0.6.0-preview.3`](https://github.com/systemslibrarian/PostQuantum.FileFormat/releases/tag/v0.6.0-preview.3)，已作为 [`PostQuantum.FileFormat.Cli`](https://www.nuget.org/packages/PostQuantum.FileFormat.Cli) 发布到 NuGet。 | 组件 | 状态 | |---|---| | 规范 | 草案 v0.6.0 | | 参考实现 (.NET) | `main` 上阶段 1–5 已完成，CI 为通过状态 | | 测试向量 | 提交了 v1 集（正向 + 负向）；在未签名子集上控制可重现性 | | CLI (`pqf`) | `keygen`, `encrypt`, `decrypt`, `inspect`, `fingerprint`；作为演示 / dogfooding CLI 在 NuGet.org 上发布为 `0.6.0-preview.3` ([范围](cli/README.md)) — 不是生产环境库的依赖项 | | 第二语言实现 | `impl/rust/pqf-reader 中的 Rust 读取器 + CI 中的跨实现一致性门控 | | 解析器模糊测试工具 | `tests/PostQuantum.FileFormat.Fuzz`（CBOR / header / streaming 目标）；60 秒的 CI 冒烟测试通过 | | NIST KAT 交叉检查 | 搭建了 `tests/PostQuantum.FileFormat.Kat` 脚手架（在获取 FIPS 203/204 向量后验证 Decapsulate + Verify） | | 恒定时间证据 | `tests/PostQuantum.FileFormat.Tests/Crypto` 下基于 dudect 风格的测量脚手架；默认跳过，直到特征化基线噪声 | | 供应链姿态 | OpenSSF Scorecard + CodeQL 每周扫描；发布时提供 SLSA-L3 来源 + CycloneDX SBOM | | 威胁模型 | 已发布 —— 参见 [`docs/THREAT-MODEL.md`](./docs/THREAT-MODEL.md) | | 兼容性 / 冻结策略 | 已发布 —— 参见 [`docs/COMPATIBILITY.md`](./docs/COMPATIBILITY.md) | | 外部密码学审查 | 尚未开始 | ## PQF 的对比 这是沿着 PQF 所关注的维度进行的刻意狭窄的比较。任何一行都不 旨在批评所列出的项目——它们有不同的目标、威胁模型和受众。 PQF 的显著选择在于 *混合后量子机密性是默认的*，而不是 可选扩展，并且解析器在构造上是失败即关闭的。 | 属性 | PQF (本项目) | age | GPG (OpenPGP) | Tink | libsodium / NaCl box | |---|---|---|---|---|---| | 机密性原语 | X25519 **+ ML-KEM-768** 通过 X-Wing (混合) | X25519 | RSA / ECDH (经典) | 默认仅 AEAD | X25519 | | PQ 姿态 | 默认混合 PQ | 无 (经典) | 无 (经典) | 无 | 无 | | 签名 | 可选混合：Ed25519 **+ ML-DSA-87** | 无 (仅加密) | RSA / EdDSA (经典) | 签名原语，经典 | Ed25519 | | 传输格式 | 确定性 CBOR (RFC 8949 §4.2.2) | 自定义文本 + 二进制 | OpenPGP 包格式 (RFC 9580) | Protobuf (keyset)，每个原语密文 | 原始拼接 | | 解析器立场 | 失败即关闭，无恢复路径 | 严格 | 历史上较宽松 | 严格 | N/A (库，不是容器) | | 单文件多接收者 | 是 | 是 | 是 | 否 (按密钥 API) | 否 | | 流式与认证模式契约 | 两者皆有，显式的非静默失败通知 | 流式 | 流式 | API 级别 | API 级别 | | 规范已冻结？ | 草案 v0.6.0 (目标 v1.0.0) | 稳定 | 稳定 (RFC) | 稳定 (Google) | 稳定 | | 外部密码学审计 | 尚未 (欢迎审查) | 多次审查 | 数十年的审查 | Google + 审计 | 多次审查 | 如果你今天想要一种稳定、经过审计的经典格式，对于大多数静态文件场景，**age** 是正确的选择。PQF 面向那些明确需要 “此文件在几十年后依然需要对能量子计算的对手保持机密，而且我不想漏掉一个 flag”的调用者。 ## 为什么不直接使用 age、S/MIME 或 OpenSSL CMS？ 针对每个替代方案的老实回答——它能给你什么，它不能 给你什么，以及 PQF 与它们并存的具体原因。 ### age (`age-encryption.org`) **使用 age**，如果你的威胁模型不是具有量子能力的 HNDL。age 很成熟，经过了 多次审计，拥有清晰定义的格式，对于 2026 年绝大多数的静态文件场景来说是正确的答案。它的 X25519 机密性在对抗今天的对手时非常出色。 **PQF 在一个具体方面有所不同：** age 是纯经典的。2026 年 使用 age 加密的密文在 2035 年以后，对于任何拥有具有密码学相关性的量子计算机的人来说都将是可恢复的。age 讨论过 PQ 扩展（例如存在 `age-plugin-xwing`），但格式 本身在规范上仅限 X25519。PQF 的出发点是“混合 PQ 是 默认的，而不是一个插件”，并为此付出了更大的传输格式、 更年轻的原语和更短的审计历史的代价。 ### S/MIME (RFC 8551) **使用 S/MIME**，如果你运行在既定的 X.509 PKI 环境中 （企业 CA、证书颁发机构、支持 S/MIME 的邮件客户端）， 并且你的受众拥有支持 S/MIME 的阅读器。 **PQF 在三个重要方面有所不同：** 1. S/MIME 基于 CMS，这是一种 TLV 格式，有着漫长的解析器歧义 和降级 bug 的历史（该格式早于 现代失败即关闭的设计准则）。PQF 使用确定性 CBOR 和封闭的 schema，并拒绝任何未知字段。 2. S/MIME 没有标准化的混合 PQ 配置。有 CMS 扩展（`draft-ietf-lamps-cms-kemri`、`draft-ietf-lamps-pq-composite-kem`） 旨在解决这个问题，但它们是草案；PQF 也是草案，但 它选择了单一的标准化组合器（X-Wing），而不是 创建自己的。 3. S/MIME 绑定到 X.509 生态系统（颁发者链、CRL / OCSP， subject DN）。PQF 在设计上仅使用密钥对——没有 CA，没有 吊销语义，没有 DN。这对某些工作流来说是一个功能，对 其他工作流来说则是一个缺失的功能。 ### OpenSSL CMS (`openssl cms`) **使用 `openssl cms`**，如果你需要一个久经沙场的 CLI 来生成 RFC 5652 CMS 容器（S/MIME 封装的格式），并且你愿意 自己管理 X.509 管道工程。 **PQF 与 S/MIME 的不同之处在于相同的三个方面**，加上 解析器立场的不同：OpenSSL 的 CMS 解析器在历史上一直 很宽松（就在 2024 年，它还发布了针对畸形输入处理 bug 的 修复程序）。PQF 的解析器在设计上是失败即关闭的，并拒绝 任何结构性偏差，包括仍然会往返转换到 相同逻辑结构的非确定性 CBOR 编码。 ### PGP / GnuPG / OpenPGP (RFC 9580) **使用 OpenPGP**，如果你的受众拥有 GPG 形态的工具链 （Linux 发行版、Debian 软件包签名、既定的 PGP 信任网），并且你的 威胁模型接受仅经典的机密性。 **PQF 有显著不同：** 1. PGP 是一种包格式，积累了数十年的解析器陷阱； IETF 制定 RFC 9580 正是因为这些。PQF 的 采用封闭 schema 的确定性 CBOR 正是这一教训的 现代版。 2. PGP 的 PQ 历史与 S/MIME 类似：存在扩展草案 （X-Wing 在 OpenPGP 中的应用正在 IETF 讨论中），但格式 本身是经典的。PQF 选择了标准化的 X-Wing 组合器 并使混合 PQ 成为默认。 3. PGP 的签名语义带有 PQF 所没有的信任网包袱。 PQF 签名仅证明“这个混合私钥对 在这个确切的 header / 文件上生成了这些签名字节”。任何 身份绑定都是调用者的责任。 ### 那么，到底为什么要使用 PQF？ PQF 是合适工具的狭窄场景：**你想要这样一种文件格式 ：(a) 混合后量子机密性是默认设置而不是 扩展，(b) 解析器在构造上拒绝各种形式的畸形输入，而不是 依赖约定，并且 (c) 实现足够小巧，能在 一个下午通读完毕。** 除此之外，那些 成熟的替代方案会更好。 ## 存在的意义 现有的文件加密格式要么早于后量子过渡期，要么将后量子原语视为可选扩展。PQF 的出发点是假设今天写入的机密文件可能需要在几十年后依然能够防范具有量子能力的对手（“现在窃取，以后解密”），而且这应该是默认设置，而不是外挂功能。 PQF 是**规范优先，而非实现优先。**规范是事实的来源；.NET 参考实现的存在是为了证明规范的可实施性，并为未来第二种语言的实现提供一致性基准。如果实现与规范不一致，以规范为准。 ## 寻求密码学审查 PQF 明确寻求密码学家和后量子实现者的审查。如果你在进行审查，**从这里开始**： - [`spec/PQF-OVERVIEW.md`](./spec/PQF-OVERVIEW.md) — 一份 3 页的审查者概述，总结了目标、威胁模型、原语、传输格式以及值得关注的五个决定。先看这个。 - [`spec/external-review/REVIEW-STATUS.md`](./spec/external-review/REVIEW-STATUS.md) — 诚实的分层记录，包括哪些已被审查（X-Wing 组合器 ✅ 继承自上游）、哪些仅有 LLM 协助（⚠️），以及哪些尚未触及（❌）。 在 [spec/PQF-SPEC-v1.md](spec/PQF-SPEC-v1.md) 中最值得仔细审查的规范性部分： - **§2.4** — X-Wing 组合器采用（PQF 0.6 放弃了内部的 `pqf1-bind-extract-v1` HKDF 结构，转而采用来自 draft-connolly-cfrg-xwing-kem 的标准化 X-Wing 组合器）。KEK 推导现在是 `SHA3-256(ss_M || ss_X || ct_X || pk_X || XWING_LABEL)`。树内实现位于 [`XWingKem.cs`](src/PostQuantum.FileFormat/Crypto/XWingKem.cs)。审查应重点关注 X-Wing 周围 PQF 特有的粘合代码：由于 X-Wing 组合器没有为两者提供 salt 插槽，因此将按接收者和按文件的绑定推入到 DEK 封装 AEAD AAD 中（`file_id || recipient_index`）。 - **§5.2** — 分块 AEAD 构造和 AAD 绑定（`file_id || chunk_index || is_final`），具有按块重加密 + 零 nonce。 - **§6.2 步骤 9** — 文件签名覆盖范围构成（`file_id || sha256(chunks) || footer`）。 - **§6.3 步骤 7** — ML-KEM 隐式拒绝时机和接收者尝试的恒定时间姿态。 - **§6.4** — Authenticated 与 Streaming Mode 的失败信号契约。 作者希望得到审查的规范级问题的运行列表位于 [`spec/PQF-DESIGN-RATIONALE-v1.md` §11](./spec/PQF-DESIGN-RATIONALE-v1.md#11-open-questions-the-author-acknowledges)。 **如何提供反馈：** - 快速的反应或指引：打开一个 [GitHub Issue](https://github.com/systemslibrarian/PostQuantum.FileFormat/issues) 或在 [Discussions](https://github.com/systemslibrarian/PostQuantum.FileFormat/discussions) 下发起一个讨论。 - 可重现的拒绝案例：带上 vector 提交一个 issue——这些将被整合到 [`test-vectors/v1/cases/TV-NEG-*.pqf`](./test-vectors/v1/) 下的负面测试向量集中。 - 敏感的安全发现：使用 [`SECURITY.md`](./SECURITY.md) 中的私密渠道。 - 想在审查前自己验证一致性声明？请参阅 [`test-vectors/QUICKSTART.md`](./test-vectors/QUICKSTART.md) —— 两条命令，约 2 分钟，即可观看独立的 Rust 读取器接受所有由 .NET 编写的测试向量。 ## 下一步去哪里 - [`spec/PQF-SPEC-v1.md`](./spec/PQF-SPEC-v1.md) — 权威的格式规范和一致性规则。 - [`spec/PQF-DESIGN-RATIONALE-v1.md`](./spec/PQF-DESIGN-RATIONALE-v1.md) — 规范之所以如此制定的原因；建议在审查格式之前阅读。 - [`spec/ietf/draft-clark-pqf-00.md`](./spec/ietf/draft-clark-pqf-00.md) — kramdown-rfc Internet-Draft 骨架，进行中。 - [`docs/THREAT-MODEL.md`](./docs/THREAT-MODEL.md) — 显式威胁模型，包含按资产的 STRIDE 表格。 - [`docs/COMPATIBILITY.md`](./docs/COMPATIBILITY.md) — 版本控制策略，v1.0.0 冻结契约，弃用规则。 - [`docs/DESIGN.md`](./docs/DESIGN.md) — 面向非密码学家的长篇设计叙述。 - [`docs/CLAIMS-AND-EVIDENCE.md`](./docs/CLAIMS-AND-EVIDENCE.md) — PQF 做出的每一项安全声明，并附有支持它的工件。 - [`docs/FAQ.md`](./docs/FAQ.md) — 带有超链接答案的常见问题。 - [`docs/STREAMING`](./docs/STREAMING.md) — 流式与认证模式的决策矩阵。 - [`docs/INTEROP.md`](./docs/INTEROP.md) — 活跃的互操作性矩阵。 - [`docs/SIDE-CHANNEL-POSTURE.md`](./docs/SIDE-CHANNEL-POSTURE.md) — 按操作的侧信道姿态（wrapper 控制什么，继承什么，什么超出范围）。 - [`CHANGELOG.md`](./CHANGELOG.md) — Keep-a-Changelog 历史。 - [`MAINTAINERS.md`](./MAINTAINERS.md) — 负责人，响应时间预期，披露窗口。 - [`man/pqf.1`](./man/pqf.1) — 手册页（`mandoc man/pqf.1`）。 - [`SPEC-CHECKLIST.md`](./SPEC-CHECKLIST.md) — 从规范中列举的按部分列出的一致性项目。 - [`docs/internal/PHASE-NOTES.md`](./docs/internal/PHASE-NOTES.md) — 实现阶段笔记，包括在参考构建期间做出的任何规范歧义决策。 - [`CONTRIBUTING.md`](./CONTRIBUTING.md) — 如何提交规范审查、bug 和 PR；接受什么和不接受什么。 - [`SECURITY.md`](./SECURITY.md) — 如何报告安全敏感发现（针对可利用问题的私密安全咨询渠道）。 - [`CODE_OF_CONDUCT.md`](./CODE_OF_CONDUCT.md) — 社区标准。 - [`examples/`](./examples/) — 展示 PQF 如何与熟悉的 Unix pipeline（`tar | pqf encrypt`）组合的简短脚本。 - [`scripts/smoke.sh`](./scripts/smoke.sh) — 由 CI 运行的端到端往返 + 拒绝路径脚本；验证本地构建的最简单方法。 ## 许可证 MIT。参见 [LICENSE](LICENSE)。

标签：可视化界面, 后量子加密, 密码学, 手动系统调用, 数据加密, 文件格式