RSA 2048キーペアの生成：openssl 0.5sを介してgpg 30sを介して、なぜ違いますか？

RSA 2048鍵ペアの生成：openssl 0.5sを介してgpg 30sを介して、なぜ違いがあるかRSA公開/秘密鍵ペアを生成できるプログラムがいくつかあります

たとえばGnuPG / OpenPGPは、経由で呼び出されるウィザードを持っています

gpg --gen-key

OpenSSLはこれらのコマンドラインを使用してキーペアを生成できます

openssl genrsa -out testkey.private 2048
openssl rsa -in testkey.private -pubout -out testkey.public

まったく同じことについて、それは私が知覚できるキーペアRSA 2048ビットを生成しています-非常に同じマシン上で-非常に異なる時間。

openssl約0.5秒でキーペア
gpgを生成し、約30 秒かかり、さらに「マウスを動かしてランダム性/エントロピーを生成する」と宣伝する

違いは説明できますか？gpgはRSA鍵の作成だけではなく、いくつかの少しのことを行うことを知っていますが、特にオプション（4）を選択します

必要なキーの種類を選択してください：
   （1）RSAおよびRSA（デフォルト）
   （2）DSAとElgamal
   （3）DSA（署名のみ）
   （4）RSA（署名のみ）
あなたの選択？

したがって、実際に生成されるのは2048ビットのRSAキーペアだけです。それでも時差は30秒ぐらいですか？

私には、gpgが不必要に時間を浪費しているか、OpenSSLが十分な時間待機していないために安全でないキーが作成されているようです。

私の質問は、違いを説明できるものは何ですか？

更新

RSAの作成では、入力としてある程度のランダム性を使用する必要があります。したがって、高速のopensslが、格納されたランダム性を使用した結果ではないことを確認するために、何度かバッチ実行しました

time bash -c "for i in {1..50}; do openssl genrsa -out / dev / null 2048; done;"

これは

実数0分16.577秒
ユーザー0m16.309s
sys 0m0.092s

つまり、2048ビットのRSAキーが50個ある場合（私はエントロピーとランダム性が必要だと思います）、opensslは16秒しか必要としません。したがって、ここでの私の想定は、opensslを破らなければならないという「答え」です。結局のところ、私のLinux（3.2.0-59カーネル）は、ランダム性を生成する点で非常に素晴らしいものになっています。

多分違いは単にopensslの使用/dev/urandomとgpgの使用で/dev/randomあり、trueが時間差を説明できる場合、私の問題はこれを確認する方法がわからないことを確認することです。

update2

opensslのランダムのソースをテストするために使用しました

strace -xe trace = file、read、write、close openssl genrsa -out testkey5.private 2048 2>＆1 | grepランダム-A1

これは

open（ "/ dev / urandom"、O_RDONLY | O_NOCTTY | O_NONBLOCK）= 4
read（4、 "\ x21 \ xd8 \ xaa \ xf1 \ x2b \ x5f \ x4a \ x89 \ x5d \ x6c \ x58 \ x82 \ xc1 \ x88 \ x21 \ x04 \ xfa \ x5b \ x18 \ x98 \ x8a \ x34 \ x2b \ xe3 \ xf3 \ xc0 \ xb1 \ xef \ xfb \ x44 \ x15 \ x09 "、32）= 32

そのため、opensslの2048ビットRSAキーペアには32バイト/dev/urandom（「良い」で/dev/randomはない）で十分です。したがって、それはとても速いです！

測定

2048ビットRSA鍵ペア生成手段

• 32バイトのみ/dev/urandom（opensslを使用）
• 300バイト/dev/random（openPGP GNU Privacy Guardを使用）

これはもちろん時差を説明します！

GnuPGは/dev/random実際に使用するランダムバイトごとに数バイトを消費します。次のコマンドで簡単に確認できます。

start cmd:> strace -e trace=open,read gpg --armor --gen-random 2 16 2>&1 | tail
open("/etc/gcrypt/rngseed", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\\\224F\33p\314j\235\7\200F9\306V\3108", 16) = 16
open("/dev/random", O_RDONLY)           = 4
read(4, "/\311\342\377...265\213I"..., 300) = 128
read(4, "\325\3\2161+1...302@\202"..., 172) = 128
read(4, "\5[\372l\16?\...6iY\363z"..., 44) = 44
open("/home/hl/.gnupg/random_seed", O_WRONLY|O_CREAT, 0600) = 5
cCVg2XuvdjzYiV0RE1uzGQ==
+++ exited with 0 +++

16バイトの高品質エントロピーを出力するために、GnuPGはから300バイトを読み取ります/dev/random。

これはここで説明されています：乱数サブシステムのアーキテクチャ

Linuxは最大4096バイト（を参照cat /proc/sys/kernel/random/poolsize）のエントロピーを格納します。プロセスが利用可能な以上のものを必要とする場合（を参照cat /proc/sys/kernel/random/entropy_avail）、カーネルのエントロピープールの供給速度が関連する要因になるため、CPU使用率は大体無関係になります。

この違いは、openssl/ dev / urandomとgpguses /dev/randomが正しいためです。

以下をgpg使用してキーを生成している間に利用可能なエントロピーが低下するのを見ることができます：

watch -n 1 cat /proc/sys/kernel/random/entropy_avail

OpenGPGスマートカードをgpgでセットアップする手順の説明を生成するプログラムを使用したためgpg、すべてが意図したとおりに機能するまで複数回実行する必要がありました。最初の実行後、/dev/randomエントロピーが十分ではなく、新しいエントロピーが蓄積されるのを待ってgpgがストールすることに気付きました。

私は小さなプログラムを書いて、ランダムでないデータを追加しました。そうするとgpg、「停止」することはなく、ほとんどすぐにキーが生成されます。スクリプトを正しく実行するためのテストに適していますが、実際のコードを生成するときに行うべきことはありません。キー。

高速化するプログラムgpg（実際の状況では使用しないでください）：

# For testing purposes only 
# DO NOT USE THIS, tHIS DOES NOT PROVIDE ENTROPY TO /dev/random

import fcntl
import time
import struct

RNDADDENTROPY=0x40085203

while True:
    random = "3420348024823049823-984230942049832423l4j2l42j"
    t = struct.pack("ii32s", 8, 32, random)
    with open("/dev/random", mode='wb') as fp:
        # as fp has a method fileno(), you can pass it to ioctl
        res = fcntl.ioctl(fp, RNDADDENTROPY, t)
        time.sleep(0.001)

見ながらこれを実行するとentropy_avail、利用可能なエントロピーが3800を超えていることがわかります。