Génération de paires de clés RSA 2048: via openssl 0.5s via gpg 30s, pourquoi la différence Il existe plusieurs programmes qui peuvent calculer les paires de clés publiques / privées RSA
GnuPG / OpenPGP, par exemple, a un sorcier envié via
gpg --gen-key
OpenSSL peut générer une paire de clés à l'aide de ces lignes de commande
openssl genrsa -out testkey.private 2048 openssl rsa -in testkey.private -pubout -out testkey.public
pour la même chose, qui génère une paire de clés RSA 2048 bits, je peux percevoir - sur la même machine - des temps très différents.
openssl
génère une paire de clés en environ 0,5 s
gpg
prend environ 30 et même des publicités "déplacez la souris pour générer l'aléatoire / l'entropie"
Peut-on expliquer la différence? Je sais que gpg fait un peu plus que la création de clés RSA, mais je choisis spécifiquement l'option (4)
Veuillez sélectionner le type de clé que vous souhaitez: (1) RSA et RSA (par défaut) (2) DSA et Elgamal (3) DSA (signe uniquement) (4) RSA (signe uniquement) Votre sélection?
Par conséquent, la seule chose générée est une paire de clés RSA à 2048 bits. Pourtant, le décalage horaire est de 30 secondes?
Pour moi, il semble que soit gpg perd du temps inutilement, soit OpenSSL n'attend pas assez de temps et crée donc des clés non sécurisées.
Ma question est ce qui pourrait expliquer la différence?
Mise à jour
La création RSA doit prendre en entrée un certain caractère aléatoire. Par conséquent, pour m'assurer que l'opensl rapide n'est pas simplement le résultat de l'utilisation de quelques aléas stockés, je les exécute par lots plusieurs fois
time bash -c "for i in {1..50}; do openssl genrsa -out / dev / null 2048; done;"
qui donne
réel 0m16.577s utilisateur 0m16.309s sys 0m0.092s
c'est-à-dire que pour 50 clés RSA 2048bits (je suppose qu'il faut beaucoup d'entropie / aléatoire), openssl n'a encore eu besoin que de 16 secondes. Mon hypothèse ici serait donc la "réponse" qui doit être ouverte à openssl. Après tout, je me méfie de mon Linux (un noyau 3.2.0-59) qui est devenu si génial pour générer de l'aléatoire.
Peut-être que la différence est simplement que les utilisations openssl /dev/urandom
et les utilisations gpg /dev/random
qui, si elles sont vraies, pourraient expliquer la différence de temps, mon problème est que je ne sais pas comment je saurais à ce sujet, pour le vérifier.
update2
Pour tester la source aléatoire d'OpenSL, j'ai utilisé
strace -xe trace = fichier, lecture, écriture, fermeture openssl genrsa -out testkey5.private 2048 2> & 1 | grep random -A1
qui donne
open ("/ dev / urandom", O_RDONLY | O_NOCTTY | O_NONBLOCK) = 4 lire (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
il semble donc que 32 octets de /dev/urandom
(pas le "meilleur" /dev/random
) suffisent pour la paire de clés RSA à 2048 bits dans openssl. C'est donc tellement rapide!
Des mesures
Génération de paires de clés RSA 2048 bits
- 32 octets de seulement
/dev/urandom
(en utilisant openssl) - 300 octets de
/dev/random
(en utilisant openPGP GNU Privacy Guard)
cela explique bien sûr le décalage horaire!
/dev/urandom
gpg de moins bonne qualité et dit même "1 octet/dev/random
n'est pas suffisant pour 1 octet de hasard". Cela ne signifierait-il pas que les clés openssl sont plus sujettes à "trop peu d'aléatoire" par rapport aux gpg?