È una chiave effimera di Diffie Hellman un buon materiale per essere utilizzata come chiave di algoritmo di cifratura simmetrica?

Question

È una chiave effimera di Diffie Hellman un buon materiale per essere utilizzata come chiave di algoritmo di cifratura simmetrica?

#1 da (1 voti)
#2 da (0 voti)
#3 da (-1 voti)

1

Sto progettando un protocollo sicuro (per scopi accademici / di apprendimento) e sono al punto in cui ho bisogno di (ri) progettare il passaggio chiave di scambio.

Nella mia precedente implementazione, usavo fare affidamento su RSA per crittografare quindi firmare un paio di chiavi AES generate casualmente che avrei poi utilizzato per la crittografia del traffico.

È stato portato alla mia attenzione che l'uso di Diffie Hellman per lo scambio di chiavi potrebbe adattarsi meglio alle mie esigenze, ma non mi sento troppo a mio agio con un algoritmo che non capisco abbastanza bene, quindi le domande:

Mi piacerebbe usare EC-DHE e ho letto che la chiave generata non era casuale (leggi: ha una struttura, che suppongo provenga dai concetti matematici sottostanti). Ho sempre sentito che l'uso di chiavi generate casualmente era altamente raccomandato per algoritmi di cifratura simmetrica. Anche se ho cancellato il tasto DHE risultante, non sarà ancora "casuale". Va ancora bene usarlo a tale scopo?

Ho capito (correggimi se ho torto), che in EC-DHE, la scelta della curva ellittica è fondamentalmente un modo semplice per scegliere i parametri DH. C'è qualcosa di cui dovrei essere a conoscenza quando scelgo la curva ellittica? Devo lasciare che gli utenti decidano quale EC possono usare?

encryption key-exchange diffie-hellman rsa

posta ereOn 04.03.2014 - 00:37

fonte

3 risposte

Leggi altre domande sui tag encryption key-exchange diffie-hellman rsa

Progettazione di una strategia di sicurezza e crittografia per MongoHQ Come generare una coppia di chiavi DSA per il browser

score 1 · Answer 1

DH (che si tratti di curve ellittiche o meno) produce un segreto condiviso . Quel segreto è un valore numerico con alcune proprietà algebriche; tuttavia, tutto il segreto è contenuto in esso. Devi solo distillarlo, allo stesso modo in cui trasformi le patate in vodka.

Supponi di utilizzare una curva ellittica a 256 bit, ad es. Curva P-256 standard del NIST. Gli elementi inviati sul filo sono punti di curva, ognuno dei quali, formalmente, una coppia di coordinate (X, Y) in un campo di 256 bit. Il risultato DH è un altro punto di curva e, per lo standard, la coordinata X di quel punto finale è il segreto condiviso. È un valore a 256 bit. Con una tale curva, ECDH dovrebbe offrire "sicurezza a 128 bit" (che è buona), quindi il segreto condiviso in qualche modo contiene 128 bit di segretezza. Quella segretezza è "diffusa" sugli attuali 256 bit. Quindi c'è spazio per la struttura anche in quel valore a 256-bit.

L'utilizzo dei 256 bit risultanti "così com'è" è generalmente considerato imprudente perché non è facile determinare l'estensione di tale struttura aggiuntiva e come potrebbe essere sfruttata esternamente. Per attivare questi 256 bit in una sequenza di bit che si può troncato e suddiviso in tasti per AES / HMAC / qualunque cosa, il metodo più semplice è quello di hash loro con qualche funzione di hash. Ad esempio, applica SHA-256 e ottieni ancora 256 bit, che possono quindi essere suddivisi e utilizzati in sicurezza come desideri. Per un caso più generico, utilizza una funzione di derivazione della chiave .

Per quanto riguarda la scelta della curva: poiché ci sono vantaggi prestazionali nell'hardcode della curva esatta nelle implementazioni, la maggior parte delle librerie esistenti supporterà solo una manciata di curve specifiche. In SSL / TLS, quando si usano le curve ellittiche, il client invia una lista di designazioni simboliche per le curve che supporta e quindi il server sceglie una di queste curve. In pratica, tutti usano P-256. Ovviamente, in un protocollo personalizzato, puoi scegliere un'altra curva; si potrebbe anche mandato che arbitraria possono essere utilizzati curve, in modo dinamico, ma poi si dovrà prendere disposizioni per l'invio dei parametri della curva, e questo sarà onerosa per le implementazioni in quanto la maggior parte delle librerie CE non offrono il supporto per curve arbitrarie.

score 0 · Answer 2

La costruzione di curve ellittiche è computazionalmente più costosa rispetto alla scelta dei parametri DH. Costruire una curva ellittica non è un compito banale.

Suggerirei di dare un'occhiata alla seguente domanda e alle risposte: È possibile utilizzare curve ellittiche personalizzate nelle implementazioni TLS comuni? .

Come accennato in questa discussione, è probabile che si verifichino problemi di compatibilità e implementazione se ci si allontana troppo da alcune delle "curve" denominate più accettate in OpenSSL. Consentire ai tuoi utenti di specificare curve arbitrarie sembrerebbe poco pratico.

score -1 · Answer 3

Prima di tutto, DHE / ECDHE consente a due persone di stabilire una chiave segreta condivisa, ma non include l'autenticazione . Quindi, DHE / ECDHE dovrebbe essere usato insieme alle firme RSA (o DSS) in base al quale il valore pubblico trasmesso sul canale di comunicazione sarebbe firmato dalla chiave privata della RSA (o DSS). Per verificare l'autenticità, il destinatario dovrebbe "disconnettersi" utilizzando la chiave pubblica del mittente.

Come puoi vedere nel articolo Wiki per EC-DH, i parametri da definiti sono (p, a, b, G, n, h) dove:

p - campo sottostante della curva ellittica (ad esempio campo primo, campo binario
a, b - coefficiente della curva ellittica
G - punto base di esempio (Gx, Gy)
n - ordine di gruppo
h - cofactor (dove h = #E (Field_p) / n)

Tuttavia, sulla base della mia comprensione pratica di EC-DH, c'è un insieme di parametri raccomandati per diverse suite . Il riferimento può essere trovato qui da NIST.

Generalmente, i parametri utilizzati sono decisi dal server . Questo è generalmente così nel protocollo SSL / TLS.