☰

关于使用 GnuPG 生成 RSA 密钥的问题

tag-icon • tag-icon gpg time gnupg
关于使用 GnuPG 生成 RSA 密钥的问题

我目前正在做一个高中项目，通过研究 RSA 密钥来更好地从理论上和实践上理解它们。项目的一部分是一个实验，我选择测试一下，看看生成不同长度的RSA密钥时CPU的工作量有多大。如果我需要得出结论，我还想节省时间作为数据点。

该计算机运行的是 Ubuntu 16.04，应用程序是从默认存储库下载的。

计划是使用 GnuPG 生成不同长度（1024、2048 和 4096）的 RSA 密钥，并使用 GNU Time 来获取 CPU 的工作负载和执行该过程的时间。该过程将使用 python 脚本自动化，如下所示：

  1. 对于 [1024, 2048, 4096] 中的长度：

    1.1. X 次：

    1.1.1.执行Gnu PG命令并监控系统资源

    1.1.2.将系统资源的使用情况写入文件

此后我将绘制一些图表来看看我的假设是否正确。

但我对 GnuPG 测试的实施有一些疑问。在问题之后解释我的实施将如何进行。我的问题是：

  • 这个设置能达到我想要的效果吗？
  • 我可以通过某种方式禁用吊销证书的自动创建吗？
  • 为什么生成一些密钥需要更长的时间？
  • 为什么 GnuPG 给出的答案是在用户空间中创建密钥花费了 0 CPU 秒？是在另一个进程中完成的吗？
  • 为什么当创建密钥的时间少于一秒（挂钟 > 1）时，CPU 工作负载参数仅显示值（0 < CPU）？

阅读手册似乎生成密钥的最简单方法是--batch打开该选项。我已按照以下说明在文件中设置了选项：

# Text syntax in this file
#%dry-run

%echo Generating RSA key...

# Don't ask after passphrase
%no-protection

Key-type: RSA
Key-Length: 1024
Name-Real: Real Name
Name-Email: [email protected]
Expire-Date: 0

# Generate RSA key
%commit

%echo Done!

执行该文件的命令有两部分，Gnu Time 部分和GnuPG 部分。 GNU Time 命令如下所示：

$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%"

GnuPG 命令如下。

$ gpg2 --gen-key --homedir=./rsa-keys --batch [filename]

我在 shell 中执行的命令（如果很重要，则使用 Fish shell）如下（GNU Time + GnuPG）：

$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%" gpg2 --gen-key --homedir=./rsa-keys --batch [filename]

命令输出：

Wall clock: 36.83[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.04[s], CPU (userspace): 0.00[s], CPU (workload): 8%
Wall clock: 4.76[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 72.39[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 57.52[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 84.71[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 63.32[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.10[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 47.58[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 64.72[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.05[s], CPU (userspace): 0.00[s], CPU (workload): 6%
Wall clock: 0.03[s], CPU (userspace): 0.00[s], CPU (workload): 11%
Wall clock: 29.62[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 55.02[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 36.08[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 42.92[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 40.41[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 204.36[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 246.42[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.50[s], CPU (userspace): 0.00[s], CPU (workload): 0%

答案1

GnuPG 读取/dev/random，当没有足够的熵可用时会阻塞（这是一个有争议的行为）。实际的计算量可以忽略不计。您可能还会观察到第一次运行/几次运行终止得更快，因为熵池仍然充满“新鲜位”。我建议watch cat /proc/sys/kernel/random/entropy_avail在附加终端中运行，以了解 GnuPG 何时运行到“低熵”模式。

在当前的硬件平台上，被 IO 阻塞或睡眠的进程将被置于后台，因此不会计算 CPU 时间。

$ time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' sleep 5
Wall clock: 5.00[s], CPU (userspace): 0.00[s], CPU (workload): 0%

从以下位置复制一些字节时也会出现这种情况/dev/random（这可能需要相当长的时间，尤其是在虚拟机中）：

time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' dd if=/dev/random of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes copied, 210.672 s, 0.0 kB/s
Wall clock: 210.67[s], CPU (userspace): 0.00[s], CPU (workload): 0%

最后，这也解释了为什么快速迭代会带来更高的 CPU 工作负载：由于进程在 IO-wait 中阻塞的时间更短，因此实际计算时间占完整执行时间的比例要大得多。

相关内容