Domanda:
ECDSA vs ECDH vs Ed25519 vs Curve25519
Omar
2014-02-04 15:53:50 UTC
view on stackexchange narkive permalink

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

È un modo piuttosto strano di metterlo. Curve25519 è una curva specifica su cui puoi eseguire Diffie-Hellman (ECDH). Diffie-Hellman viene utilizzato per scambiare una chiave. Ed25519 e ECDSA sono algoritmi di firma.
correlato: [Chiave SSH: Ed25519 vs RSA] (http://security.stackexchange.com/questions/90077/ssh-key-ed25519-vs-rsa)
Vedi anche [Curve25519: nuovi record di velocità Diffe-Hellman] di Bernstein (https://cr.yp.to/ecdh/curve25519-20060209.pdf).Sembra fare un buon lavoro e risponde a molte delle tue domande.
Cinque risposte:
#1
+108
Tom Leek
2014-02-04 18:32:23 UTC
view on stackexchange narkive permalink

In SSH vengono utilizzati due algoritmi: un algoritmo di scambio di chiavi (Diffie-Hellman o la variante a curva ellittica chiamata ECDH) e un algoritmo di firma. Lo scambio di chiavi fornisce la chiave segreta che verrà utilizzata per crittografare i dati per quella sessione. La firma è in modo che il client possa assicurarsi di parlare con il server corretto (un'altra firma, calcolata dal client, può essere utilizzata se il server impone 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, del P-256. La differenza di prestazioni è molto piccola in termini umani: stiamo parlando di calcoli inferiori a un millisecondo su un piccolo PC, e questo accade solo una volta per sessione SSH. Non lo noterai. Nessuna curva può essere definita "più forte" dell'altra, né praticamente (sono entrambe abbastanza lontane nel regno "non può romperla") né accademicamente (entrambe sono al "livello di sicurezza a 128 bit").

Anche quando ECDH viene utilizzato per lo scambio delle chiavi, la maggior parte dei server e dei client SSH utilizzerà le chiavi DSA o RSA per le firme. Se vuoi un algoritmo di firma basato su curve ellittiche, allora questo è ECDSA o Ed25519; per alcune ragioni tecniche dovute alla definizione precisa dell'equazione della curva, questa è 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 supportano più l'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. Tuttavia, per un dato server che configuri e a cui desideri accedere dalle tue macchine, l'interoperabilità non ha molta importanza: controlli sia il software client che quello server.

Quindi, in fondo, la scelta dipende dall'estetica, cioè completamente da te, senza motivo razionale. I problemi di sicurezza non saranno comunque causati da quella scelta; gli algoritmi crittografici sono la parte più forte dell'intero sistema, non la più debole.

Il "passo di vendita" per 25519 è più: non è NIST, quindi non è NSA. Non velocità.
In realtà, è anche molto veloce. Le curve di Edwards / Montgomery ben costruite possono essere più volte più veloci di quelle stabilite dal NIST. Http://www.imperialviolet.org/2010/12/21/eccspeed.html
In effetti, se vuoi veramente la velocità su un PC recente, le curve binarie di Koblitz approvate dal NIST sono ancora più veloci (grazie all'opcode "carryless moltiplication" fornito con l'istruzione x86 AES); fino a qualcosa come 40000 cicli per una moltiplicazione di punti generica in K-233, più del doppio più veloce di Curve25519 - ma trovare uno scenario in cui questa velocità extra fa effettivamente una differenza notevole è difficile.
Più "presentazione di vendita" proviene da [questa bozza IETF] (https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03#section-4): _ Anche se le curve NIST sono pubblicizzate come scelte a caso in modo verificabile, non c'è spiegazione per i semi usati per generarle.Al contrario, il processo utilizzato per selezionare queste curve è completamente documentato e sufficientemente rigido da consentire una verifica indipendente.Questo è ampiamente visto come un vantaggio per la sicurezza, poiché impedisce al generatore di manipolare maliziosamente i parametri.
Secondo il sito web http://safecurves.cr.yp.to/ di DJB, la curva NIST potrebbe non essere sicura o infallibile come Curve25519.
In realtà ci sono tre algoritmi.L'algoritmo di chiave host (e client) (autenticazione), l'algoritmo di scambio di chiavi (kex) e il codice.
@MartinSchröder, Enigma non è stato nemmeno inventato dagli americani ...
Apprezzo che la chiave pubblica con ed25519 sia molto più corta dell'RSA a 4096 bit per l'uso con SSH.
#2
+82
Brian Minton
2014-03-14 20:53:08 UTC
view on stackexchange narkive permalink

Dalla 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 a diversi attacchi di canale laterale:

  • Nessun indice di 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 agli 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 ramo segreto. Il software non esegue mai rami condizionali basati su dati segreti; lo schema dei salti è completamente prevedibile. Il software è quindi immune agli attacchi di canale laterale che si basano sulla fuga di informazioni attraverso l'unità di previsione del ramo.

Per fare un confronto, sono stati dimostrati diversi attacchi di cache-timing nel mondo reale su vari algoritmi. http://en.wikipedia.org/wiki/Timing_attack

* "Uno dei vantaggi di sicurezza più interessanti è che è immune a diversi attacchi di canale laterale" * - Per affermare l'ovvio, ciò dipende dall'implementazione.Il codice del team di Bernstein, il codice di Adam Langley, il codice di Andrew Moon (e altri) dovrebbero essere OK.Ma non credo che si possa dire lo stesso per un'implementazione arbitraria.
Immagino che sarebbe più preciso dire che il design dell'algoritmo rende possibile implementarlo senza utilizzare indici di array segreti o condizioni di ramo.Certo che hai ragione che sarebbe comunque possibile implementarlo male.
Un time pad non è sicuro perché dipende dall'implementazione.
#3
+39
lxgr
2014-12-01 17:53:29 UTC
view on stackexchange narkive permalink

Esiste un importante vantaggio pratico di Ed25519 rispetto a (EC) DSA: quest'ultima famiglia di algoritmi si rompe completamente quando viene utilizzata per le firme insieme a un generatore di numeri casuali interrotto. Un tale errore RNG è accaduto prima e potrebbe benissimo accadere di nuovo.

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

#4
+35
zenith
2014-02-08 03:27:41 UTC
view on stackexchange narkive permalink

Avevo l'impressione che Curve25519 SIA effettivamente più sicuro delle curve NIST a causa della forma della curva che lo rende meno suscettibile a vari attacchi di canali laterali e errori di implementazione. Vedi: http://safecurves.cr.yp.to

Ed25519 ha il vantaggio di poter utilizzare la stessa chiave per la firma dell'accordo di chiave (normalmente non lo faresti Fai questo). Non conosco abbastanza bene la matematica per dire se questa è una proprietà del fatto che sia una curva di Edwards, anche se so che è convertita nel sistema di coordinate di Montgomery (effettivamente in Curve25519) per l'accordo chiave ... Ed25519 è più rispetto a una curva, specifica anche la generazione di chiavi deterministiche tra le altre cose (ad esempio hashing), che vale la pena tenere a mente. Questa è una cosa frustrante delle implementazioni DJB, dato che devono essere trattate in modo diverso per mantenere l'interoperabilità.

#5
+12
Mecki
2019-06-07 18:04:24 UTC
view on stackexchange narkive permalink

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

ECDH e 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 una non sicura canale di comunicazione. È una variazione del metodo di scambio delle chiavi DH (Diffie-Hellman). ECDH sta per Diffie-Hellman a curva ellittica . Eppure ECDH è solo un metodo, il che significa che non puoi usarlo solo con una curva ellittica specifica, puoi usarlo con molte curve ellittiche diverse.

ECDSA è un algoritmo di firma che può essere utilizzato per firmare una parte di dati in modo tale che qualsiasi modifica ai dati causerebbe il fallimento della convalida della firma, ma un utente malintenzionato non sarebbe in grado di firmare nuovamente i dati correttamente dopo tale modifica. È una variazione di DSA (algoritmo di firma digitale). ECDSA è l'acronimo di Elliptic Curve Digital Signature Algorithm . Inoltre ECDSA descrive solo un metodo che può essere utilizzato con diverse curve ellittiche.

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

  1. Quanto è sicuro il metodo stesso ? Se il metodo non è sicuro, la migliore curva nella parola non lo cambierebbe.
  2. Quanto è sicura la curva utilizzata? Se la curva non è sicura, non giocherà un ruolo se il metodo in teoria 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 semplicemente 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 dovrebbe sempre denominare in modo esplicito la curva utilizzata.

Per rispondere alla tua domanda sulla sicurezza: ECDH ed ECDSA hanno praticamente dimostrato di essere metodi concettuali di scambio e firma sicuri delle chiavi, quindi la sicurezza di ECDH e ECDSA dipende in gran parte dal fatto che qualcuno trovi un modo per rompere la crittografia ellittica in generale (poco probabile ma non impossibile) o per trovare un difetto nelle curve utilizzate (più probabile).

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

Il NIST ha anche standardizzato una crittografia a curva ellittica basata su generatore di numeri casuali (Dual_EC_DRB) nel 2006 e il New York Times ha affermato (dopo aver esaminato i promemoria trapelati da Edward Snowden) che era la NSA a influenzare il NIST a standardizzare questo specifico generatore di numeri casuali. Un enorme punto debole è stato scoperto in quel generatore e si ritiene che sia una backdoor intenzionale posizionata dalla NSA per poter violare la crittografia TLS basata su quel generatore. Apparentemente l'ANSI ha scoperto la debolezza quando Dual_EC_DRB è stato sottoposto loro per la prima volta, ma nonostante fossero consapevoli di come evitarlo, non hanno né migliorato l'algoritmo, né pubblicizzato i punti deboli, quindi si ritiene che non gli fosse permesso di (gag order ). Quando la debolezza è diventata pubblicamente nota, lo standard è stato ritirato nel 2014.

Con queste conoscenze di base, ovviamente, le persone hanno iniziato a chiedersi se forse la fonte dei misteriosi parametri della curva NIST sia in realtà anche l'NSA poiché forse queste curve hanno anche punti deboli nascosti che non sono ancora noti pubblicamente ma l'NSA potrebbe saperlo su di loro e quindi essere in grado di rompere la crittografia basata su queste curve. Non ci sono prove per questa affermazione, nemmeno una prova presunta ma sembra sicuramente possibile e più realistica di una fiaba. Ecco perché le persone hanno perso la fiducia in queste curve e sono passate ad alternative dove è altamente improbabile che queste siano state influenzate da qualsiasi servizio segreto in tutto il mondo.

Curve25519 è stato pubblicato dal matematico e crittologo tedesco-americano Daniel J Bernstein nel 2005, che ha anche progettato il famoso cifrario a flusso Salsa20 e la variante ChaCha20 ora 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 è stato rotto. Richiede molta meno potenza di calcolo rispetto all'utilizzo del chipher AES (molto utile per i dispositivi mobili in quanto consente di risparmiare la durata 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 spia della NSA, il che è molto improbabile, saremmo già tutti condannati perché allora TLS, poiché viene spesso utilizzato oggi, sarebbe probabilmente inutile per proteggere i dati dagli occhi dei servizi segreti.

Sebbene l'ECDSA possa essere utilizzato con più curve, in realtà non viene utilizzato con quello di Bernstein.Ed25519 e Ed448 sono istanze di EdDSA, che è un algoritmo diverso, con alcuni vantaggi tecnici.E in OpenSSH (come richiesto) l'opzione di comando `ssh-keygen -t ecdsa` e il nome file predefinito` id_ecdsa * `non specificano la curva, ma la chiave effettiva (contenuto) inclusa sul cavo e in` known_hosts` ecc _do_;vedere rfc5656.Compreso nistP-521, non P-512 che non esiste.
@dave_thompson_085 Non ho mai affermato che l'ECDSA sia utilizzato con Bernstein.Non ho mai affermato che openSSH specifichi una curva.Quindi, per favore, evita di commentare cose che non ho mai scritto.E P-512 era chiaramente un errore di battitura proprio come ECDSA per EdDSA, dopotutto ho scritto molto testo, quindi si verificano errori di battitura.
Volevo solo far notare che hai un errore di battitura nella descrizione della revisione in cui hai scritto male "fastidiosi pignoli".


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...