如何使用 GnuPG 和 GNU 并行进行大文件并行加密？答案

【问题标题】：How to do large file parallel encryption using GnuPG and GNU parallel?如何使用 GnuPG 和 GNU 并行进行大文件并行加密？
【发布时间】：2017-09-17 05:33:11
【问题描述】：

我正在尝试编写用于归档的并行压缩/加密备份脚本使用 GNU 并行、xz 和 GnuPG。脚本的核心部分是：

tar --create --format=posix --preserve-permissions --same-owner --directory $BASE/$name --to-stdout . \
    | parallel --pipe --recend '' --keep-order --block-size 128M "xz -9 --check=sha256 | gpg --encrypt --recipient $RECIPIENT" \
    | pv > $TARGET/$FILENAME

没有 GnuPG 加密，它工作得很好（解压缩和解压工作），但添加并行加密后，解密失败并出现以下错误：

[don't know]: invalid packet (ctb=0a)
gpg: WARNING: encrypted message has been manipulated!
gpg: decrypt_message failed: Unexpected error
: Truncated tar archive
tar: Error exit delayed from previous errors.

由于未压缩的大小与gnu parallel的块大小相同（大约125M），我认为这与GnuPG对部分块加密的支持有关。我该如何解决这个问题？

仅供参考

另一个关于随机数生成的并行 gpg 加密问题

https://unix.stackexchange.com/questions/105059/parallel-pausing-and-resuming

【问题讨论】：

您可以在这里做的最好的一件事是将-z 0 传递给 gpg 以阻止它尝试重新压缩 xz 的输出。这可能会将您的工作更改为 IO-bound 并消除对 GNU 并行的需求。它为我做到了，但我会注意到我使用的是 zstd 而不是 xz -9。

标签： encryption parallel-processing gnupg pgp gnu-parallel

【解决方案1】：

打包

tar --create --format=posix --preserve-permissions --same-owner --directory $BASE/$name --to-stdout . |
    parallel --pipe --recend '' --keep-order --block-size 128M "xz -9 --check=sha256 | gpg --encrypt --recipient $RECIPIENT;echo bLoCk EnD" |
    pv > $TARGET/$FILENAME

解压

cat $TARGET/$FILENAME |
  parallel --pipe --recend 'bLoCk EnD\n' -N1 --keep-order --rrs 'gpg --decrypt | xz -d' |
  tar tv

需要-N1 来确保我们一次通过一条记录。 GnuPG 不支持解密多条合并记录。

【讨论】：

@Old Tange：我不知道--rrs。使用自定义分隔符是个好主意。我无法在您的命令中得到它的一件事是-N1 选项。在这种情况下，这个选项有什么作用？手册页说 与 --pipe -N 一起使用时是要读取的记录数。这比 --block 慢一些。
感谢您的快速回答。只是好奇如果我错过了-N1 选项，并行传递多条记录到管道？
在打包命令中将-z 0 的参数添加到gpg 将通过阻止它尝试重新压缩xz 的输出来节省许多浪费的CPU 周期。

【解决方案2】：

GnuPG 不支持连接多个加密流并同时解密它们。您将不得不存储多个文件，并单独解密它们。如果我没记错的话，你的命令甚至会混淆所有 GnuPG 并行实例的输出，所以结果或多或少是随机垃圾。

无论如何：GnuPG 也负责压缩，看看--compression-algo 选项。如果您更喜欢使用xz，请应用--compression-algo none，这样GnuPG 就不会再次尝试压缩已经压缩的消息。加密在当今得到 CPU 指令的大量支持，xz -9 实际上可能比加密更耗时（尽管我没有对此进行基准测试）。

【讨论】：

哇！很好的答案和问题编辑谢谢。这就是我想知道的。而且我不知道 gpg 对压缩的关心我会在我的工作中尝试--compression-algo none。正如你提到的。几千兆字节的 xz -9 比 gpg encrption 是一个巨大的进程，但 gpg 进程的时间也不容忽视。无论如何，我会报告两个测试的执行时间。
如果你能获得足够新的软件来支持，也许还可以看看 Facebook 的新 zstd 算法，一些基准测试声称在具有竞争力的压缩比上具有出色的 CPU 负载。可能达不到xz -9，但计算开销要小得多。
是的，我已经花了一些时间在该管道进程上应用 facebook 的全新 zstd 算法，但 zstd 的进程创建行为看起来与 xz、gzip 不同。所以我成功地创建了并行压缩的 zstd arhive 文件，但它的压缩率和时间比旧的xz -9 设置差。看起来需要更多的研究。
在我的 gpg (1.4.18 / Debian) 中设置压缩级别的选项是 --compress-level --compression-algo 中没有选项所以我只是在我的脚本中设置了 --compress-level 0
这里是简单的基准数字。 ( 11.9GiB tar.gz.xz ) 1. tar + 并行 xz + 带压缩的单个 gpg：3022 秒 2. tar + 并行 xz + 不带压缩的单个 gpg：2550 秒（比原始速度快 15.6%） 3. tar + 并行 xz和没有压缩的 gpg：2873 秒（比原始速度快 4.9%，但 NOT WORKS）第三个命令通过获取 random_seed 条件显示时间差异很大。最后我选择了 tar + parallel xz + single gpg 没有压缩组合。

【解决方案3】：

这主要是一个 gpg 问题。 gpg 不支持多线程，可能永不。你可以在网上搜索一下原因。

gpg v2 甚至变得更糟：你甚至不能在其中运行多个 gpg v2 实例并行，因为它们都锁定了现在正在执行所有操作的 gpg-agent 工作........也许我们应该在进行大规模加密时寻找替代方案。

https://answers.launchpad.net/duplicity/+question/296122

编辑：不可以。可以同时运行多个 gpg v2 实例，而 gpg-agent 没有任何问题。

【讨论】：

从技术上讲，这涉及另一个问题：OpenPGP 指定使用 CFB 模式变体，它不支持多线程加密，因此您必须启动多个单独的加密流（您已经这样做了）。当然，第二个引用可以通过运行多个线程或实例来解决（如果不支持，这是 GnuPG 的限制）。