關於使用 GnuPG 生成 RSA 密鑰的問題
我目前正在通過研究 RSA 密鑰來做一個高中項目，以便在理論上和實踐上更好地理解它們。該項目的一部分包括一個實驗，我選擇測試並查看在生成不同長度的 RSA 密鑰時 CPU 的工作量有多大。如果需要得出結論，我還想將時間保存為數據點。
該機器執行的是 Ubuntu 16.04，應用程序是從預設儲存庫下載的。
計劃是使用 GnuPG 生成不同長度（1024、2048 和 4096）的 RSA 密鑰和 GNU Time 來獲取 CPU 的工作負載和執行程序的時間。該過程將使用 python 腳本自動執行，看起來像這樣：
- 對於長度
$$ 1024, 2048, 4096 $$: 1.1。對於 X 次：
1.1.1。執行 Gnu PG 命令並監控系統資源
1.1.2。將系統資源的使用寫入文件
此後，我將繪製一些圖表，看看我的假設是否正確。
但是我有一些關於我的 GnuPG 測試實施的問題。在問題之後解釋我的實施方式。我的問題是：
- 這個設置做我想做的事嗎？
- 我可以以某種方式禁用吊銷證書的自動創建嗎？
- 為什么生成一些密鑰需要更長的時間？
- 為什麼 GnuPG 給出的答案是在使用者空間中創建密鑰需要 0 CPU 秒？它是在另一個過程中完成的嗎？
- 為什麼 CPU 工作負載參數僅在創建密鑰的時間不到一秒（掛鐘 > 1）時才顯示值（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: user@localhost.se 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 中執行的命令（如果很重要，則為魚 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%
GnuPG 從 中讀取
/dev/random，當沒有足夠的熵可用時阻塞（這是一個有爭議的行為）。實際的計算工作量可以忽略不計。您可能還觀察到第一次執行/幾次執行終止得更快，因為熵池仍然充滿了“新鮮位”。當 GnuPG 執行到“低熵”模式時，我建議watch cat /proc/sys/kernel/random/entropy_avail在額外的終端中執行以了解情況。在目前的硬體平台上，被 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 中阻塞的時間要短得多，實際計算時間佔整個執行時間的部分要大得多。