Combinazioni di scambio di chiavi e algoritmo di firma in TLS

Naviga le tue risposte
1

Diciamo che uno non si fida di molto di ECC e valuta la riservatezza sull'autenticità (forse semplicemente perché MitM è più difficile di un'ascolto e una decifrazione passiva in seguito). In questo caso si potrebbe usare il DHE classico per gli scambi di chiavi e l'ECDSA per le firme.

C'è qualcosa di problematico nel farlo? Per avere un'elevata resistenza di crittografia, si userebbero parametri DH grandi (forse 16k) poiché il classico scambio di chiavi DHE non è costoso dal punto di vista computazionale e più veloce le firme ECDSA sui tasti DHE scambiati. Inoltre, questa combinazione non fa parte delle specifiche TLS (per quanto ne so), perché no?

EDIT: Giusto per chiarire, sembra che questo non faccia parte delle specifiche, ma sto cercando risposte sul perché no, o se questa sarebbe una cattiva idea dal punto di vista della sicurezza.

    
posta user1207217 06.07.2015 - 16:06
fonte

2 risposte

2

In order to have high encryption strength, one would use large DH params (16k perhaps) since the classical DHE key exchange is not computationally expensive,

Non posso darti numeri difficili per la velocità. Il comando openssl speed non sembra offrire il punto di riferimento per il normale (campo finito) Diffie-Hellman.

Questa risposta offre una guida sulle dimensioni pratiche dei parametri DH:

this combination is not part of the TLS specification (as far as I know)

Una corretta. Non esiste una combinazione di _DHE_ e _ECDSA nelle attuali assegnazioni della suite di crittografia. 

$ wget https://www.iana.org/assignments/tls-parameters/tls-parameters.txt
$ cat tls-parameters.txt | grep -i _ecdsa_  | awk '{print $2}' | cut -d _ -f2 | sort | uniq -c
     17 ECDH
     21 ECDHE
    
risposta data 06.07.2015 - 16:33
fonte
1

Il classico DHE è molto costoso dal punto di vista computazionale, almeno con il passare del tempo. Questo raramente conta (un normale PC può ancora fare centinaia di DHE al secondo), ma se ti trovi in una situazione in cui il budget di elaborazione è limitato (ad esempio piccoli sistemi embedded), ECDHE è sostanzialmente più economico.

Con implementazioni "normali", il costo di DHE è proporzionale a p 2 r , dove p è la dimensione del modulo e r è la dimensione dell'esponente segreto utilizzato in DHE. r non deve essere maggiore di, ad esempio, 256 bit, SE i parametri DH sono tali che la dimensione del sottogruppo non ha fattori primi piccoli. Sfortunatamente, TLS non consente al server di comunicare al cliente la dimensione del sottogruppo, quindi un cliente cauto dovrà utilizzare un esponente DH segreto almeno grande quanto il modulo, aumentando il costo per p 3 . Anche se un esponente "piccolo" può essere usato, un DHE con un modulo a 16384 bit sarà costoso (a seconda delle dimensioni dell'esponente segreto, sarà tra 64 e 512 volte il costo di un più ordinario 2048- bit DHE modulo). Forse ancora più importante, un modulo DH sovradimensionato potrebbe non funzionare affatto, perché molte implementazioni hanno limitazioni interne per vari motivi ingegneristici.

Non esiste una suite di crittografia definita che combini un DHE classico e firme ECDSA. Quindi la domanda potrebbe essere discutibile comunque. Tali suite di crittografia potrebbero essere definite concettualmente; non sarebbe difficile; ma non è stato fatto, quindi le implementazioni non lo supportano.

    
risposta data 06.07.2015 - 16:58
fonte

Leggi altre domande sui tag

Utilizzo del browser Tor per utilizzare YouTube e la sicurezza dell'account Quali sono i diversi payload utilizzati per la vulnerabilità XSS? [chiuso]