☰

關於使用 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 中阻塞的時間更短，因此實際計算時間佔完整執行時間的比例要大得多。

相關內容