Concryptor

一个用 Rust 构建的多线程 AEAD 加密引擎。使用三重缓冲的 io_uring 流水线、通过 Rayon 实现的并行分块处理以及通过 ring 实现的汇编优化密码，以每秒千兆字节的吞吐量加密和解密文件。

⚠️ 免责声明：实验性软件 ⚠️

该项目极其新，目前不建议用于生产或关键任务场景。 虽然加密原语（通过 ring 的 AES-256-GCM、ChaCha20-Poly1305）和格式设计是可靠的，但代码库尚未经过正式安全审计或广泛的实际测试。使用风险自负。如需保护敏感数据，请考虑使用经过实战检验的工具（如 GnuPG、age 或 OpenSSL），直到该项目成熟。

特性

• 双密码支持：通过 ring（汇编优化）实现 AES-256-GCM（硬件 AES-NI）和 ChaCha20-Poly1305
• 并行加密：基于 Rayon 的多线程分块处理，利用所有 CPU 核心
• 三重缓冲 io_uring 流水线：使用三个旋转缓冲区池重叠内核 I/O 和 CPU 端加密——当一批待写入操作正在内核中完成时，下一批正在被 Rayon 加密，而第三批的读取操作正在提交到内核。无每块系统调用开销，无 mmap 限制（无 SIGBUS，无虚拟地址空间耗尽）
• Argon2id 密钥派生：行业标准的密码到密钥拉伸（默认 256 MiB 内存，3 次迭代，可通过 --memory 配置）
• 自描述 KDF 参数：内存成本、迭代次数和并行度存储在加密文件头中，因此解密将使用加密时选择的确切参数。旧版文件（全零哨兵）透明地使用旧版 64 MiB 默认值处理
• 块索引 nonce：TLS 1.3 风格的 XOR nonce 派生防止块重排序攻击
• 头认证 AAD：完整的 4 KiB 对齐头包含在每个块的 AAD 中，认证所有头字段（核心、KDF 参数和保留字节），防止截断、头字段操作和保留字节走私攻击
• STREAM 风格最终块：AAD 中的最终块标志防止截断和追加攻击（受 STREAM 结构启发）
• 每文件新鲜随机性：每次加密生成加密随机的 16 字节盐和 12 字节基础 nonce，存储在头中
• 原地加密：通过 ring 的 seal_in_place_separate_tag / open_in_place 最小化热循环中的内存分配
• 密码归零：使用后安全地从内存中擦除密钥和密码
• O_DIRECT + 扇区对齐格式：4 KiB 对齐的头和块槽支持 O_DIRECT I/O，绕过内核页面缓存，实现 NVMe 上的 DMA 速度读写。缓冲区池使用 std::alloc，对齐为 4096 字节
• 目录加密：将整个目录加密为单个加密归档。基于 tar 的打包在密文中保留文件名、权限、时间戳和目录结构。解压验证路径遍历和符号链接逃逸攻击
• 自描述文件格式：头存储密码、块大小、原始文件大小、盐、基础 nonce 和 Argon2id KDF 参数

性能

使用 cargo bench（Criterion，每个测量 10 个样本）进行基准测试。排除密钥派生——数字仅反映纯加密吞吐量。

硬件：

• CPU：AMD Ryzen 5 5600X（6c/12t @ 3.7 GHz 基础频率）
• 内存：2x 8 GiB DDR4-2666（双通道，共 16 GiB）
• 操作系统：Linux

关于 I/O 的说明： Criterion 将临时文件写入 /tmp，在该系统上为 tmpfs（内存支持）。使用 O_DIRECT 时，内核无法在 tmpfs 上使用真正的异步 DMA，因此这些数字反映了密码吞吐量 + io_uring 开销 而没有 DMA 绕过的好处。在真正的 Gen4 NVMe 驱动器上，O_DIRECT 消除了页面缓存双缓冲，并允许直接进入对齐缓冲区池的 DMA，这应该会带来显著更高的吞吐量。

块大小扫描（AES-256-GCM，64 MiB 文件）：

性能特征

该引擎使用 ring（汇编优化的 AES-NI / NEON / ARMv8-CE）进行密码操作，并使用三重缓冲的 io_uring 流水线进行 I/O。三个预分配的缓冲区池在流水线中轮换：当池 A 的写入操作在内核中完成时，池 B 正在被 CPU 上的 Rayon 加密，而池 C 的读取操作正在提交到内核。这实现了 I/O 延迟与加密计算的重叠。

为什么小文件上 AES-256-GCM 比 ChaCha20-Poly1305 更快： ring 的 AES-GCM 后端利用 x86-64 上可用的 AES-NI + CLMUL 硬件指令，使其比 ChaCha20（一种软件密码）具有硬件优势。在较大文件上，两种密码收敛到约 1.0 GiB/s，表明瓶颈从密码吞吐量转移到 I/O 提交开销。

为什么峰值吞吐量在 1-16 MiB 而不是 256 MiB： 小文件（1-16 MiB）的块数少，因此 Rayon 并行性高效，工作集适合缓存。在 64-256 MiB 时，io_uring 流水线完全活跃（三批在途），但每次 SQE 提交和 CQE 完成的开销随块数缩放。三重缓冲设计确保 I/O 和加密重叠，部分隐藏了此成本。

为什么约 1.0 GiB/s 而不是 10+ GiB/s： 现代 AES-NI 每核心可推送 2-4 GiB/s。使用 12 个线程，原始密码吞吐量可能超过 10 GiB/s。三个因素解释了差异：

1. io_uring 每 SQE 开销：每个块需要一个读取 SQE 和一个写入 SQE。对于 256 MiB 文件中的 256 个块，需要提交 512 个 SQE 并回收 512 个 CQE。虽然 io_uring 避免了 pread/pwrite 的每次系统调用内核转换成本，但每个 SQE 仍有环形缓冲区和内存屏障开销。
2. 流水线深度：PIPELINE_DEPTH=3 时，任何时候只有三批在流水线中轮换。真正的稳态重叠需要至少三批；适合一批或两批的文件无法从流水线中受益。
3. 缓存层次结构影响：5600X 每个核心有 512 KiB L2 和 32 MiB 共享 L3。默认的 4 MiB 块超过 L2，一批约 21 个块（84 MiB 活跃工作集）远超过 L3。较小的块大小（64-256 KiB）在块扫描中显示更好的吞吐量，因为更多的工作集保留在缓存中。

缓冲区生命周期和安全性： 缓冲区池在 io_uring 环创建之前通过 std::alloc::alloc_zeroed 和 Layout::from_size_align(size, 4096) 一次性分配，并在所有流水线迭代中重用而不重新分配。每个加密块在 O_DIRECT 写入之前零填充到扇区对齐。环在缓冲区池之前显式丢弃，确保内核从不引用已释放的内存（无 UAF）。

安装

git clone https://github.com/frogsnot/concryptor.git
cd concryptor
cargo build --release

二进制文件位于 target/release/concryptor。

用法

加密

# AES-256-GCM（默认），输出到 myfile.dat.enc
concryptor encrypt myfile.dat

# ChaCha20-Poly1305，自定义输出路径
concryptor encrypt myfile.dat --cipher chacha -o encrypted.enc

# 自定义块大小（以 MiB 为单位）
concryptor encrypt largefile.iso --chunk-size 8

# 更强的 KDF（512 MiB 内存成本）
concryptor encrypt secrets.tar --memory 512

# 非交互式（跳过密码提示）
concryptor encrypt myfile.dat -p "password"

安全说明： --password / -p 将密码作为 CLI 参数传递，这在 ps 输出和 shell 历史记录中可见。对于交互式使用，请省略它以获得安全的隐藏提示。对于脚本编写，建议清理历史记录或使用从文件描述符读取的包装器。

加密目录

# 加密目录（自动检测，生成 mydir.tar.enc）
concryptor encrypt mydir/

# 使用自定义密码和输出
concryptor encrypt mydir/ --cipher chacha -o secrets.enc

目录加密创建一个临时 tar 归档（.concryptor-*.tar，权限 0600，CSPRNG 命名），对其进行加密，然后自动删除临时文件。文件名、目录结构、权限和时间戳都在加密负载内。

解密

# 自动去除 .enc 扩展名
concryptor decrypt myfile.dat.enc

# 自定义输出路径
concryptor decrypt encrypted.enc -o restored.dat

# 非交互式
concryptor decrypt myfile.dat.enc -p "password"

解密并提取目录

# 一步解密并提取（自动去除 .tar.enc -> 目录名）
concryptor decrypt mydir.tar.enc --extract

# 短标志，自定义输出目录
concryptor decrypt mydir.tar.enc -x -o restored_dir/

不使用 --extract 时，解密目录归档会生成中间的 .tar 文件，您可以检查或手动提取。

帮助

concryptor --help
concryptor encrypt --help
concryptor decrypt --help

文件格式

所有值为小端序。头占用完整的 4 KiB 扇区；每个加密块槽填充到下一个 4 KiB 边界。这确保每个偏移量和 I/O 大小都是扇区对齐的，以支持 O_DIRECT。

偏移量  大小  字段
------  -----  ---------------------
0       10     魔数 "CONCRYPTOR"
10       1     格式版本 (4)
11       1     密码类型 (0 = AES-256-GCM, 1 = ChaCha20-Poly1305)
12       4     块大小（字节，LE）
16       8     原始文件大小（字节，LE）
24      16     Argon2 盐（加密随机，每文件唯一）
40      12     基础 nonce（加密随机，每文件唯一）
52       4     Argon2 m_cost（KiB，LE，0 = 旧版 64 MiB）
56       4     Argon2 t_cost / 迭代次数（LE，0 = 旧版 3）
60       4     Argon2 p_cost / 并行度（LE，0 = 旧版 4）
64    4032     保留（零填充至 4096 字节）
4096    ...    [块 0: 密文 + 16 字节标签 + 零填充至扇区边界]
               [块 1: 密文 + 16 字节标签 + 零填充至扇区边界]
               ...

对于 4 MiB 块：每个磁盘槽为 ceil((4194304 + 16) / 4096) * 4096 = 4198400 字节（每块 4080 字节填充）。头中的 4032 个保留字节可用于将来特性（非对称密钥槽、元数据等）。

每次加密时，盐和基础 nonce 都从 rand::rng()（由操作系统 CSPRNG 支持）新鲜生成。跨文件重用密码是安全的，因为不同的盐产生不同的 Argon2id 密钥，不同的基础 nonce 产生不同的每块 nonce。

安全设计

• Nonce 派生：chunk_nonce = base_nonce XOR chunk_index（TLS 1.3 风格）。交换块会导致解密失败，因为位置 N 的 nonce 与用于加密原始位置 M 的块的 nonce 不匹配。注意：基于 XOR 的 nonce 派生在跨多个流使用 相同密钥 时存在理论弱点（不同的基础 nonce 可能产生重叠的 nonce 空间）。这不适用于 Concryptor，因为每次加密生成一个新的 128 位随机盐，为每个文件产生唯一的 Argon2id 密钥。Nonce 唯一性仅在相同密钥下重要，而每对文件密钥重用概率约为 2^-128。
• 头认证 AAD：每个块的 AEAD 调用使用 AAD = full_aligned_header (4096) || chunk_index (8 LE) || is_final (1)（共 4105 字节）。完整的 4 KiB 头扇区（核心字段、KDF 参数和保留填充）绑定到每个块的认证标签中。修改 任何 头字节（密码类型、块大小、原始大小、盐、nonce、KDF 参数或保留填充）会使所有块无效。这防止了攻击者编辑 original_size 并删除尾部块的截断攻击，也防止了在保留填充区域中走私数据。旧版 v3 文件使用 52 字节 AAD 解密以保持向后兼容；无法从 v4 降级到 v3，因为版本字节本身在认证的 AAD 内。
• STREAM 风格最终块指示符：AAD 的最后一个字节对于最终块为 0x01，对于所有其他块为 0x00。这防止了两种攻击：
  • 截断：删除最终块并将非最终块提升到末尾会失败，因为非最终块使用 is_final = 0x00 加密，但解密期望 0x01。
  • 扩展：追加伪造块会失败，因为攻击者无法在没有密钥的情况下为 is_final = 0x01 生成有效标签。
• 每文件新鲜随机性：每次加密从操作系统 CSPRNG（rand::rng()）中抽取 16 字节盐和 12 字节基础 nonce。相同文件使用相同密码的两次加密产生完全不同的密文。Nonce 重用（对 AES-GCM 是灾难性的）通过构造避免。
• 密钥派生：Argon2id，可配置内存成本（默认 256 MiB，可通过 调整），3 次时间迭代，并行度 4。默认 256 MiB 是 OWASP 最小值的 4 倍，对 GPU/FPGA/ASIC 攻击者成本高昂。KDF 参数存储在文件头（字节 52-63）中，使文件自描述——无论当前默认值如何，解密始终使用正确的参数。如果字节 52-63 全为零（旧版无 KDF 参数文件），则应用旧的 64 MiB / 3 / 4 默认值。

测试

# 运行完整测试套件（67 个测试）
cargo test

# 运行基准测试（HTML 报告在 target/criterion/ 中）
cargo bench

# 过滤基准测试
cargo bench -- "encrypt/AES"
cargo bench -- "chunk_sweep"

测试套件涵盖：

• 头序列化/反序列化往返
• 密钥派生确定性和敏感性
• Nonce 唯一性和身份属性
• 两种密码在文件大小（空、1 字节、边界情况、多块）上的加密/解密往返
• 错误密码拒绝
• 篡改检测（翻转的密文、损坏的标签、损坏的盐、截断的文件）
• 块重排序攻击检测
• 密码类型不匹配检测
• 截断攻击检测（修改的 original_size + 移除的块）
• 头字段操作检测（修改的 chunk_size）
• 保留头字节篡改检测（修改的填充区域）
• 非确定性加密验证
• 包含 256 个小块的应力测试
• 目录归档打包/解包往返（两种密码）
• 空目录、深层嵌套目录、多文件和二进制内容往返
• 有效内部链接的符号链接保留
• 拒绝逃逸提取根的符号链接（绝对和相对遍历）
• 临时文件在 Drop 时自动清理
• 加密归档的错误密码拒绝

依赖项

安装

# 从 crates.io（推荐）
cargo install concryptor

# 从源码
git clone https://github.com/FrogSnot/Concryptor
cd Concryptor
cargo build --release
# 二进制文件位于 target/release/concryptor

许可证

本项目采用 GNU Affero General Public License v3.0 许可。