Quanto tempo / "raccolta di entropia" dovrebbe generare una coppia di chiavi RSA 2048bit?

Question

Quanto tempo / "raccolta di entropia" dovrebbe generare una coppia di chiavi RSA 2048bit?

#1 da (6 voti)
#2 da (2 voti)
#3 da (1 voti)

4

Lo scopo della mia domanda è avere un'idea migliore di quanto tempo occorrerà per generare la coppia di chiavi pubbliche / private RSA?

Per essere meno generico lasciatemi specificare la domanda e definire che userò questi comandi per generare la coppia di chiavi su un laptop con un kernel linux 3.2.xx recente.

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

Ho tempo per i comandi e in media questa operazione richiede circa 0,5 secondi, il che mi sembra terribilmente veloce (in effetti troppo veloce).

So di essere a conoscenza (e ho anche cercato di esprimere ciò nel titolo delle domande) che non è solo il tempo, ma piuttosto la quantità di entropia e il suo tasso di rifornimento che influenza il tempo necessario per creare la coppia di chiavi. Almeno suppongo che entropia sia usata per generare le chiavi (altrimenti le chiavi sarebbero prevedibili e di conseguenza inutili, giusto?).

Sullo stesso sistema usando gpg --gen-key da OpenPGP "GNU Privacy Guard" che posso anche usare anche per creare una coppia di chiavi RSA 2048bit, per esempio richiede molto più tempo e richiede anche io per spostare il mouse ecc.

Quindi mi chiedo come si stia sommando. In sostanza quanta entropia e di conseguenza il tempo dovrebbe una generazione di keypair RSA assumere un sistema moderno.

Sono convinto che non ci sia tempo standard, ma sicuramente può essere stimato in termini di "meno di 30 minuti" "più di 10 secondi".

Dato che ci sono depositi di "entropia" nel sistema. Supponiamo che siano vuoti e quindi il tempo in cui cerco la creazione di una "regola empirica" per i keypair RSA 2048 dovrebbe implicare l'avvio da zero "in termini di archiviazione di entropia".

Perché OpenPGP gpg richiede circa 2 minuti per creare una coppia di chiavi RSA 2048 e openssl da fare in mezzo secondo ...?

entropy rsa

posta humanityANDpeace 16.03.2014 - 15:05

fonte

3 risposte

Leggi altre domande sui tag entropy rsa

E-mail già in uso exploit No Handshake di Airodump

score 6 · Answer 1

Per sicurezza, tutto ciò di cui hai bisogno è che il processo venga eseguito con 128 o più di entropia come seme iniziale. Entropia qui significa: ciò che l'utente malintenzionato non conosce . In particolare, non vi è alcun problema se l'entropia di origine stessa viene estesa con un CSPRNG nel produzione di molte coppie di chiavi.

Il modello core è il seguente: il sistema operativo mantiene un "pool entropico" interno che contiene almeno 128 bit di entropia. Un PRNG crittograficamente strong estende quel pool interno in una sequenza arbitrariamente lunga di bit pseudocasuali, che sono, per definizione, imprevedibili dall'attaccante, perché 2 ¹²⁸ è troppo alto numero per l'attaccante di forza bruta nel pool, e "crittograficamente strong" significa veramente "non puoi fare meglio della forza bruta". Su un sistema Linux, questo è chiamato /dev/urandom .

(Nota: parte dell'essere "crittograficamente strong" include anche "forward security": ottenendo il contenuto del pool dopo la generazione della chiave non dovrebbe consentire "riavvolgere" il PRNG al suo stato prima della generazione .I buoni PRNG sono inoltrati sicuri.)

C'è un mito comune sull'essere entropia "esaurita" come se fosse una sorta di combustibile. Questo non è vero, tranne in un senso molto teorico che si applica solo se si usa la casualità solo per Pad One-Time , e il tuo aggressore è Dio. Per tutti gli altri casi, inclusa la generazione di chiavi per "algoritmi normali" come RSA, e non per l'ira divina, l'entropia non viene consumata quando si ottengono i byte da /dev/urandom . Il comportamento di /dev/random su Linux è, infatti, gravemente imperfetto (la /dev/random di FreeBSD è molto meglio). Questa pagina Web spiega abbastanza bene le differenze tra /dev/random e /dev/urandom , e perché /dev/urandom dovrebbe essere preferito Leggi tutto intero.

La domanda rimanente è quindi: perché GnuPG utilizza /dev/random e non /dev/urandom per la generazione di chiavi? Bene, ci sono ragioni storiche (GnuPG volte a supportare sistemi con PRNG fornito da OS molto poveri) e inerzia generale (una riluttanza comune a sfidare "saggezza consolidata", anche quando tale "saggezza" è mitica); ma la ragione principale è che è colpa tua . GnuPG fa della crittografia come medicina: non solo deve proteggere le e-mail, ma l'utente umano deve anche essere convinto che si sia appena verificata una potente crittografia. Le pillole funzionano meglio quando hanno un sapore fallo; allo stesso modo, gli utenti vogliono la generazione di chiavi per sembrare uno sforzo costoso. La tua stessa domanda è una testimonianza di quella sensazione: sebbene tu non sappia esattamente cosa succede all'interno di un CSPRNG (che è una questione per i crittografi), continui a credere che "0,5 secondi sia troppo veloce". GnuPG rispetta i tuoi capricci facendo un grande spettacolo del processo di generazione delle chiavi. Questo è tutto security theater e succede perché tu lo vuoi in questo modo.

score 2 · Answer 2

misurando le letture di gpg e openssl di File /dev/random e /dev/urandom che sembrano essere le fonti di entropia / casualità sembra che la risposta sia quella

per una coppia di chiavi RSA a 2048 bit che abbiamo bisogno / usare

300bytes "di /dev/random casualità" in caso di gpg
32bytes "di /dev/urandom randomness" in caso di openssl

La differenza di fuso orario (gpg circa 30sec) vs (openssl ca 0.5secs) è quindi spiegata da quel fatto che /dev/random sta bloccando quando si esaurisce la casualità.

score 1 · Answer 3

Per aggiungere a quanto detto da humanandpeace, / dev / urandom è un CSPRNG che usa il pool entropico interno del kernel (cosa viene usato per / dev / random, anche un CSPRNG che blocca con una stima di entropia == 0) ma esteso da un Algoritmo CSPRNG. Ciò significa che la lettura da / dev / random è molto lenta a meno che non si abbia un RNG hardware che lo alimenta.

GnuPG utilizza l'input di dati grezzi da / dev / random per la generazione di chiavi. Usa / dev / random perché vuole garantire entropia di altissima qualità per le chiavi, e / dev / urandom non è una buona fonte di entropia su alcuni sistemi (o almeno non lo era, non sono sicuro se questo è ancora vero).

OpenSSL, d'altra parte, usa 32 byte da / dev / urandom per seminare il proprio CSPRNG interno, quindi genera i dati necessari per generare le chiavi da lì. Questo spiega le operazioni più veloci.

A meno che non si trovi una debolezza nei dati casuali generati da / dev / urandom che non influenzano anche / dev / random, le chiavi generate in entrambe le modalità dovrebbero essere sicure. / dev / urandom è creduto per essere crittograficamente sicuro e viene utilizzato per molte altre operazioni, quindi un punto debole in esso sarebbe un grosso problema.