it-swarm-eu.dev

ECDSA vs ECDH vs Ed25519 vs Curve25519

Tra gli algoritmi ECC disponibili in openSSH (ECDH, ECDSA, Ed25519, Curve25519), che offre il miglior livello di sicurezza e (idealmente) perché?

118
Omar

In SSH vengono utilizzati gli algoritmi due: un algoritmo di scambio di chiavi (Diffie-Hellman o la variante della curva ellittica chiamata ECDH) e un algoritmo di firma. Lo scambio di chiavi produce la chiave segreta che verrà utilizzata per crittografare i dati per quella sessione. La firma è tale che il client può assicurarsi che parli con il server giusto (un'altra firma, calcolata dal client, può essere utilizzata se il server applica l'autenticazione client basata su chiave).

ECDH utilizza un curva; la maggior parte dei software utilizza la curva NIST standard P-256. Curve25519 è un'altra curva, il cui "passo di vendita" è che è più veloce, non più forte, di P-256. La differenza di prestazioni è molto piccola in termini umani: stiamo parlando di calcoli di meno di un millisecondo su un piccolo PC, e questo accade solo una volta per sessione SSH. Non lo noterai. Non si può dire che nessuna curva sia "più forte" dell'altra, non praticamente (sono entrambe abbastanza lontane nel regno "impossibile spezzarlo") né accademicamente (entrambe sono al "livello di sicurezza a 128 bit").

Anche quando ECDH viene utilizzato per lo scambio di chiavi, la maggior parte dei server e client SSH utilizzerà le chiavi DSA o RSA per le firme. Se vuoi un algoritmo di firma basato su curve ellittiche, allora ECDSA o Ed25519; per alcuni motivi tecnici a causa della definizione precisa dell'equazione della curva, questo è ECDSA per P-256, Ed25519 per Curve25519. Anche in questo caso, nessuno dei due è più forte dell'altro e la differenza di velocità è troppo piccola per essere rilevata da un utente umano. Tuttavia, la maggior parte dei browser (inclusi Firefox e Chrome) non supporta più ECDH (anche dh).

L'uso di P-256 dovrebbe produrre una migliore interoperabilità in questo momento, perché Ed25519 è molto più recente e non così diffuso. Ma, per un determinato server che configuri e al quale desideri accedere dalle tue macchine, l'interoperabilità non ha molta importanza: controlli sia il software client che quello server.

Quindi, in sostanza, la scelta spetta all'estetica, cioè completamente a te, senza una ragione razionale. I problemi di sicurezza non saranno comunque causati da tale scelta; gli algoritmi crittografici sono la parte più forte dell'intero sistema, non la più debole.

101
Tom Leek

Da Introduzione a Ed25519 , ci sono alcuni vantaggi in termini di velocità e alcuni vantaggi in termini di sicurezza. Uno dei vantaggi di sicurezza più interessanti è che è immune da numerosi attacchi di canale laterale:

  • Nessun indice array segreto. Il software non legge o scrive mai dati da indirizzi segreti nella RAM; lo schema degli indirizzi è completamente prevedibile. Il software è quindi immune da attacchi di temporizzazione della cache, attacchi di hyperthreading e altri attacchi di canale laterale che si basano sulla perdita di indirizzi attraverso la cache della CPU.
  • Nessuna condizione di filiale segreta. Il software non esegue mai rami condizionali basati su dati segreti; lo schema dei salti è completamente prevedibile. Il software è quindi immune agli attacchi dei canali laterali che si basano sulla perdita di informazioni attraverso l'unità di previsione delle filiali.

Per fare un confronto, ci sono stati diversi attacchi di temporizzazione della cache reali dimostrati su vari algoritmi. http://en.wikipedia.org/wiki/Timing_attack

80
Brian Minton

Esiste un importante vantaggio pratico di Ed25519 rispetto a (EC) DSA: quest'ultima famiglia di algoritmi si interrompe completamente quando utilizzato per le firme insieme a un generatore di numeri casuali non funzionanti. Un tale guasto RNG ha accaduto prima e potrebbe benissimo accadere di nuovo.

Teoricamente, le implementazioni possono proteggere contro questo problema specifico, ma è molto più difficile verificare che entrambe le estremità stiano usando un'implementazione corretta piuttosto che preferire o applicare (a seconda delle esigenze di compatibilità) un algoritmo che specifica esplicitamente comportamento sicuro (Ed25519).

37
lxgr

Avevo l'impressione che Curve25519 IS in realtà è più sicuro delle curve NIST a causa della forma della curva che lo rende meno suscettibile a vari attacchi del canale laterale e fallimenti dell'implementazione. Vedi: http://safecurves.cr.yp.to

Ed25519 ha il vantaggio di poter usare la stessa chiave per firmare un accordo chiave (normalmente non lo faresti). Non conosco abbastanza bene la matematica abbastanza da dire se questa è una proprietà del fatto che sia una curva di Edwards, anche se so che viene convertito nel sistema di coordinate Montgomery (in effetti in Curve25519) per un accordo chiave ... Ed25519 è più piuttosto che una curva, specifica anche la generazione deterministica delle chiavi tra le altre cose (ad es. hash), da tenere a mente. Questa è una cosa frustrante per le implementazioni di DJB, come accade, poiché devono essere trattate in modo diverso per mantenere l'interoperabilità.

34
zenith

Qualcosa a cui nessuna risposta finora indirizzata direttamente è che le tue domande mescolano diversi nomi più o meno indipendenti tra loro come se fossero alternative equivalenti tra loro, il che non è proprio il caso.

ECDH ed ECDSA sono solo nomi di metodi crittografici.

ECDH è un metodo di scambio di chiavi che due parti possono utilizzare per negoziare una chiave sicura su un canale di comunicazione non sicuro. È una variazione del metodo [~ # ~] dh [~ # ~] (Diffie-Hellman). ECDH sta per Diffie – Hellman a curva ellittica . Eppure ECDH è solo un metodo, ciò significa che non puoi semplicemente usarlo con una curva ellittica specifica, puoi usarlo con molte diverse curve ellittiche.

ECDSA è un algoritmo di firma che può essere utilizzato per firmare un dato in modo tale che qualsiasi modifica ai dati provocherebbe il fallimento della convalida della firma, tuttavia un utente malintenzionato non sarebbe in grado di re-firmare correttamente i dati dopo tale modifica. È una variazione di [~ # ~] dsa [~ # ~] (algoritmo di firma digitale). ECDSA sta per Algoritmo di firma digitale della curva ellittica . Inoltre ECDSA descrive solo un metodo che può essere utilizzato con diverse curve ellittiche.

La sicurezza di ECDH e ECDSA dipende quindi da due fattori:

  1. Quanto è sicuro il metodo stesso? Se il metodo non è sicuro, la migliore curva nella Parola non cambierebbe questo.
  2. Quanto è sicura la curva utilizzata? Se la curva non è sicura, non avrà un ruolo se teoricamente lo è.

Curve25519 è il nome di una curva ellittica specifica. Altre curve sono denominate Curve448, P-256, P-384 e P-521.

Ed25519 è il nome di una variazione concreta di EdDSA . Quando si esegue EdDSA utilizzando SHA-512 e Curve25519 , questa variazione è denominata Ed25519. EdDSA è un algoritmo di firma, proprio come ECDSA.

Quindi, se un'implementazione dice solo che utilizza ECDH per lo scambio di chiavi o ECDSA per firmare i dati, senza menzionare alcuna curva specifica, di solito puoi presumere che utilizzerà le curve NIST (P-256, P-384 o P-512), tuttavia l'implementazione in realtà dovrebbe sempre nominare esplicitamente la curva utilizzata.

Per rispondere alla tua domanda sulla sicurezza: ECDH ed ECDSA hanno praticamente dimostrato di essere metodi di scambio e firma chiave sicuri concepiti, quindi la sicurezza di ECDH ed ECDSA dipende praticamente dal fatto se qualcuno trova un modo per rompere la crittografia ellittica in generale (poco probabile ma non impossibile) o per trovare un difetto all'interno delle curve in uso (più probabile).

Il motivo per cui alcune persone preferiscono Curve25519 rispetto alle curve standard NIST è il fatto che il NIST non ha chiaramente documentato perché ha scelto queste curve a favore delle alternative esistenti. L'affermazione generica " Le curve sono state presumibilmente scelte per sicurezza ottimale ed efficienza di implementazione " assomiglia molto al marketing balderdash e non convincerà gli esperti di crittografia.

Il NIST ha anche standardizzato una crittografia a curva ellittica basata su un generatore di numeri casuali (Dual_EC_DRB) nel 2006 e il New York Times ha affermato (dopo aver esaminato i memo trapelati da Edward Snowden) che era il NSA che influenza il NIST per standardizzare questo specifico generatore di numeri casuali. In quel generatore sono stati scoperti enormi punti deboli e si ritiene che si tratti di una backdoor intenzionale posizionata da NSA per essere in grado di rompere la crittografia TLS basata su quello generatore. Apparentemente l'ANSI ha scoperto la debolezza quando Dual_EC_DRB è stato presentato per la prima volta a loro, ma nonostante fossero consapevoli di come evitarlo, non hanno migliorato l'algoritmo né pubblicizzato le debolezze, quindi si ritiene che non gli sia stato permesso ( ordine di bavaglio) Quando la debolezza è diventata nota al pubblico, lo standard è stato ritirato nel 2014.

Con quella conoscenza di base, ovviamente, le persone hanno iniziato a chiedersi se forse la fonte dei misteriosi parametri della curva NIST è in realtà anche il NSA poiché forse queste curve hanno anche delle debolezze nascoste che non sono pubblicamente note ma il NSA può conoscerli e quindi essere in grado di rompere la crittografia basata su queste curve. Non ci sono prove per tale affermazione, nemmeno una prova presuntiva ma sicuramente sembra possibile e più realistica di una fiaba. Ecco perché le persone hanno perso la fiducia in queste curve e sono passate a alternative dove è altamente improbabile che queste siano state influenzate da qualsiasi servizio segreto in tutto il mondo.

Curve25519 è stato pubblicato dal matematico e criptologo tedesco-americano Daniel J. Bernstein nel 2005, che ha anche progettato il famoso codice di flusso Salsa20 e la variante ChaCha20 ormai ampiamente utilizzata. Ha anche inventato l'autenticazione del messaggio Poly1305. Google ha deciso che ChaCha20 in combinazione con Poly1305 è un'alternativa sicura da utilizzare in TLS dopo che RC4 doveva essere rimosso perché l'algoritmo era stato rotto. Richiede molta meno potenza di calcolo rispetto all'utilizzo del chipherher AES (molto utile per i dispositivi mobili in quanto consente di risparmiare l'autonomia della batteria), ma si ritiene che fornisca una sicurezza comparabile. ChaCha20/Poly1305 è standardizzato in RFC 7905 e oggi è ampiamente utilizzato nelle comunicazioni client-server TLS. Quindi se Bernstein fosse una NSA spia, il che è molto improbabile, saremmo tutti condannati già allora come TLS come viene spesso usato oggi sarebbe probabilmente inutile per proteggere i dati dagli occhi del segreto Servizi.

6
Mecki