Generazione di keypair RSA 2048: tramite openssl 0,5s tramite gpg 30s, perché la differenza?

Generazione di keypair RSA 2048: tramite openssl 0,5s tramite gpg 30s, perché la differenza Esistono diversi programmi che possono gerarchizzare i keypair pubblici / privati ​​RSA

GnuPG / OpenPGP, ad esempio, ha un wizzard invocato tramite

gpg --gen-key

OpenSSL può generare una coppia di chiavi usando queste righe di comando

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

per la stessa cosa, che sta generando una coppia di chiavi RSA 2048 bit che riesco a percepire - sulla stessa macchina - tempi molto diversi.

opensslgenera una coppia di chiavi in ​​circa 0,5 secondi
gpgrichiede circa 30 e persino annunci "sposta il mouse per generare casualità / entropia"

La differenza può essere spiegata? So che gpg fa un po 'di più della semplice creazione della chiave RSA, tuttavia scelgo specificamente l'opzione (4)

Seleziona il tipo di chiave che desideri:
   (1) RSA e RSA (impostazione predefinita)
   (2) DSA ed Elgamal
   (3) DSA (solo segno)
   (4) RSA (solo segno)
La tua selezione?

Quindi davvero l'unica cosa generata è una coppia di chiavi RSA a 2048 bit. Eppure la differenza di tempo sta crollando a 30 secondi?

A me sembra che o gpg stia sprecando inutilmente tempo o OpenSSL non stia aspettando abbastanza tempo e quindi crea chiavi insicure.

La mia domanda è: cosa potrebbe spiegare la differenza?

Aggiornare

La creazione di RSA deve prendere come input un po 'di casualità. Quindi per essere sicuro che il rapido openssl non sia semplicemente il risultato dell'uso di una casualità memorizzata, l'ho eseguito in batch più volte

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

che cede

0m16.577 reali
utente 0m16.309s
sys 0m0.092s

il che è che per 50 chiavi RSA a 2048 bit (presumo occorra molta entropia / casualità) si apre ancora solo 16 secondi. La mia ipotesi qui sarebbe quindi la "risposta" che openssl deve essere rotta. Dopotutto sono diffidente sul fatto che il mio Linux (un kernel 3.2.0-59) sia diventato così eccezionale nel generare casualità.

Forse la differenza è semplicemente che openssl usa /dev/urandome gpg usa /dev/randomche se vero potesse spiegare la differenza di tempo il mio problema è che non so come lo scoprirò, per verificarlo.

Update2

Per testare la fonte di random di openssl ho usato

strace -xe trace = file, leggi, scrivi, chiudi openssl genrsa -out testkey5.private 2048 2> & 1 | grep random -A1

che cede

aperto ("/ dev / urandom", O_RDONLY | O_NOCTTY | O_NONBLOCK) = 4
leggi (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

quindi sembra che 32 byte da /dev/urandom(non il "migliore" /dev/random) siano sufficienti per la coppia di chiavi RSA a 2048 bit in openssl. Quindi è così veloce!

misure

Mezzi di generazione della coppia di chiavi RSA a 2048 bit

• Solo 32 byte /dev/urandom(usando openssl)
• 300 byte di /dev/random(usando openPGP GNU Privacy Guard)

questo spiega ovviamente la differenza di tempo!

GnuPG consuma diversi byte /dev/randomper ogni byte casuale che utilizza effettivamente. Puoi facilmente verificarlo con questo comando:

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 +++

Per generare 16 byte di entropia di alta qualità, GnuPG legge 300 byte da /dev/random.

Questo è spiegato qui: Architettura del sottosistema di numeri casuali

Linux memorizza un massimo di 4096 byte (vedi cat /proc/sys/kernel/random/poolsize) di entropia. Se un processo ha bisogno di più di quello disponibile (vedi cat /proc/sys/kernel/random/entropy_avail), l'utilizzo della CPU diventa più o meno irrilevante in quanto la velocità di alimentazione del pool di entropia del kernel diventa il fattore rilevante.

Il tuo suggerimento che questa differenza è perché opensslutilizza / dev / urandom e gpgusi /dev/randomè corretto.

Puoi osservare l'entropia disponibile che scende mentre si generano le chiavi gpgusando:

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

Ho usato un programma per generare la descrizione dei passaggi per configurare una smart card OpenGPGgpg , quindi ho dovuto eseguire gpgpiù volte fino a quando tutto ha funzionato come previsto. Dopo le prove iniziali ho notato che /dev/randomnon ci sarebbe stata abbastanza entropia e gpg si sarebbe semplicemente bloccato in attesa dell'accumulo di nuova entropia.

Ho scritto un piccolo programma per fornire dati extra non casuali, e quando lo facevo gpgnon "si fermava" ma generava le chiavi quasi immediatamente: bello per testare lo script per funzionare correttamente, ma ovviamente non è qualcosa che dovresti fare mentre generi il tuo vero chiavi.

Il programma per accelerare gpg( non utilizzare in situazioni reali ):

# 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)

Quando eseguo questo mentre guardo entropy_availposso vedere l'entropia disponibile salire a oltre 3800.