Generazione chiavi RSA: gpg vs openssh

7

Quando genero la chiave RSA per ssh (sia lato server che lato client):

dpkg-reconfigure openssh-server
ssh-keygen

la generazione della chiave è completata all'istante. Tuttavia, quando genero la chiave RSA per gpg, la generazione della chiave richiede diversi minuti e devo generare entropia digitando sulla tastiera o leggendo / scrivendo sul disco:

gpg --key-gen

Mi chiedo cosa faccia questa differenza e se la qualità delle chiavi generate sia la stessa (per le stesse dimensioni della chiave) . Qualcuno ha qualcosa da dire su questo?

come nota a margine:

Ricordo vagamente che esisteva una vulnerabilità Debian OpenSSH che influiva sul seeding del generatore di numeri casuali. IIRC, l'entropia per la chiave proveniva da due fonti:

1) using uninitialized memory
2) using the Process ID (PID)

Questo bug è stato causato commentando (1), lasciando il PID come unica fonte di entropia. Di conseguenza, lo spazio delle possibili chiavi era solo 2 ^ 16.

OpenSsh utilizza davvero solo queste due fonti di entropia? No /dev/random ?

    
posta Michael Boies 19.03.2015 - 12:41
fonte

1 risposta

3

La differenza deriva dal fatto che si utilizza il blocco / non blocco casuale (e.a. / dev / random e / dev / urandom) dalle pagine man di ubuntu 14.04 ( man random ):

NAME:      random, urandom - kernel random number source devices

SYNOPSIS : #include <linux/random.h>
           int ioctl(fd, RNDrequest, param);

DESCRIPTION :
 The  character  special files /dev/random and /dev/urandom 
 (present since Linux 1.3.30) provide an interface to the kernel's random number    
 generator. 
 File /dev/random has major device number 1 and minor device number 8. 
 File /dev/urandom has major device number 1 and minor device number 9.

 The random number generator gathers environmental noise from device drivers and  
 other sources into an entropy pool.  The generator also keeps  an  estimate
 of the number of bits of noise in the entropy pool.  From this entropy pool random 
 numbers are created.

 When  read,  the  /dev/random device will only return random bytes within the 
 estimated number of bits of noise in the entropy pool.  /dev/random should be
 suitable for uses that need very high quality randomness such as one-time pad or 
 key generation.  When the entropy pool is empty,  reads  from  /dev/random
 will block until additional environmental noise is gathered.

 A  read  from  the  /dev/urandom  device will not block waiting for more entropy.  
 As a result, if there is not sufficient entropy in the entropy pool, the
 returned values are theoretically vulnerable to a cryptographic attack on the  
 algorithms used by the driver.  Knowledge of how to do this is not  available
 in  the  current  unclassified  literature,  but it is theoretically possible that 
 such an attack may exist.  If this is a concern in your application, use 
 /dev/random instead.

 Writing to /dev/random or /dev/urandom will update the entropy pool with the data 
 written, but this will not result in a higher entropy count.  This  means
 that it will impact the contents read from both files, but it will not make reads   
 from /dev/random faster.

Usage :
 If  you  are  unsure  about  whether you should use /dev/random or /dev/urandom,  
 then probably you want to use the latter.  As a general rule, /dev/urandom
 should be used for everything except long-lived GPG/SSL/SSH keys.

Questo significa che openssh userà il file speciale / dev / urandom e gpg --key-gen usa / dev / random. il GPG si bloccherà quando l'entropia viene "drenata" fino a quando non viene aggiunta una quantità sufficiente di entropia, con conseguente utilizzo di entropia comprovata, casuale casuale il suo pool di entropia per tutto il tempo. Ciò significa che non esaurisce l'entropia come / dev / random fa. e fa questo per avere un livello di "reale" entropia per i numeri casuali. e non fare affidamento sull'entropia di / dev / urandom.

    
risposta data 19.03.2015 - 13:31
fonte