Il supporto della curva ellittica limitata in rhel / centos / redhat openssl è abbastanza robusto?

5

Redhat alla fine cedette dopo aver insistito per anni sul fatto che le curve ellittiche avessero brevettato e disabilitato, di recente abilitando un enorme tre algoritmi:

CentOS 6.5
openssl ecparam -list_curves                            
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field 

CentOS 7.0
openssl ecparam -list_curves                      
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

Ma una build di sorgenti dirette di openssl 1.0.1i ha dozzine di curve in confronto.

È ciò che redhat ha fatto abbastanza robusto? Lo hanno paralizzato?

    
posta ck_ 09.08.2014 - 15:13
fonte

1 risposta

4

Inizierò. TL; DR: Probabilmente è OK.

P-256 e P-384 sembrano essere le "curve" più largamente implementate e / o preferite, probabilmente perché sono le due selezionate per link e le giuste dimensioni per i punti di forza attualmente considerati constrongvoli. Per essere pedanti sono in realtà dei set di parametri che consistono in una curva su un campo più un generatore di un grande sottogruppo, ma ognuno dice semplicemente curva per comodità; gli algoritmi come ECDSA e ECDH sono gli stessi per tutte le curve e le chiavi, proprio come l'algoritmo RSA è lo stesso per tutte le chiavi.

P-521 è la curva più grande attualmente standardizzata per SSL / TLS, che soddisfa i maniaci delle dimensioni.

ECC di dimensioni inferiori a 160 bit è probabilmente irrisibile abbastanza presto, e standard importanti proibiscono meno di 224 o 256 per essere constrongvoli; vedi link . I campi binari si sono dimostrati meno popolari. Quindi le curve che RedHat ha scelto sono abbastanza probabili per un'interoperabilità decente.

Alcuni, in particolare Dan Bernstein, sostengono che TUTTE le curve standardizzate NIST / SECG sono difficili da implementare senza sidechannels e potrebbero anche essere backdoor, vedi link e link , ma le alternative proposte non sono ancora standardizzate e apparentemente richiedono cambiamenti nell'implementazione (di una forma di equazione che mantenga la resistenza del sidechannel) da sviluppare e implementare abbastanza ampiamente prima che diventino utile, quindi non cercare quello domani.

Ma se vuoi, penso che non ci dovrebbe essere nulla di sbagliato nell'usare la tua build di compilazione, purché la versione OpenSSL upstream nuova abbastanza da contenere le necessarie correzioni di sicurezza non sia così nuova da essere incompatibile con ciò che gli altri RedHat / CentOS i pacchetti si aspettano.

    
risposta data 13.04.2017 - 14:48
fonte

Leggi altre domande sui tag