☰

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がユーザー空間でキーを生成するためにCPU秒が0であるという答えを提供するのはなぜですか？他のプロセスで実行されますか？
  • キー生成時間が1秒未満（壁時計> 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部分の2つの部分で構成されています。 GNU Timeコマンドは次のとおりです。

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

GnuPG コマンドは次のようになります。

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

シェルで実行するコマンド（重要な場合はFishシェルを使用）は次のとおりです（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_availGnuPGがいつ「低エントロピー」モードで実行されるかを確認するには、追加の端末で実行することをお勧めします。

現在のハードウェアプラットフォームでは、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 待機でより短い時間だけブロックされるため、実際の計算時間は全体の実行時間ではるかに大きい部分を占めます。

おすすめ記事