Qual è la differenza prestazionale di cki rispetto alla crittografia simmetrica?

StackOverflow https://stackoverflow.com/questions/118463

Domanda

Stiamo cercando di soddisfare alcuni severi requisiti di sicurezza per il nostro progetto e abbiamo bisogno di molta crittografia altamente performante.

Penso di sapere che la PKI è molto più lenta e complessa della crittografia simmetrica, ma non riesco a trovare i numeri per il backup dei miei sentimenti.

È stato utile?

Soluzione

Sì, la crittografia puramente asimmetrica è molto più lenta dei cifrari simmetrici (come DES o AES), motivo per cui le applicazioni reali usano crittografia ibrida : le costose operazioni a chiave pubblica vengono eseguite solo per crittografare (e scambiare) una chiave di crittografia per l'algoritmo simmetrico che verrà utilizzato per crittografare il messaggio reale.

Il problema risolto dalla crittografia a chiave pubblica è che non esiste un segreto condiviso. Con una crittografia simmetrica devi fidarti di tutte le parti interessate per mantenere la chiave segreta. Questo problema dovrebbe essere una preoccupazione molto più grande delle prestazioni (che possono essere mitigate con un approccio ibrido)

Altri suggerimenti

Su un Macbook con OS X 10.5.5 e una build stock di OpenSSL, "openssl speed" clock AES-128-CBC a 46.000 blocchi da 1024 bit al secondo. Quella stessa scatola segna RSA a 1024 bit con 169 firme al secondo. AES-128-CBC è il "libro di testo" algoritmo di crittografia a blocchi e RSA 1024 è il "manuale" " algoritmo a chiave pubblica. Sono le mele alle arance, ma la risposta è: RSA è molto, molto più lento .

Non è per questo che non dovresti usare la crittografia a chiave pubblica. Ecco i veri motivi:

  1. Le operazioni di crittografia a chiave pubblica non sono destinate alla crittografia dei dati non elaborati . Algoritmi come Diffie-Hellman e RSA sono stati concepiti come un modo per scambiare le chiavi con algoritmi a blocchi crittografici. Quindi, ad esempio, useresti un generatore di numeri casuali sicuro per generare una chiave casuale a 128 bit per AES e crittografare quei 16 byte con RSA.

  2. Algoritmi come RSA sono molto meno "facili da usare" di AES . Con una chiave casuale, un blocco di testo in chiaro che invii ad AES diventerà casuale per chiunque senza la chiave. Questo in realtà non è il caso di RSA, che è --- più di AES --- solo un'equazione matematica. Quindi, oltre a archiviare e gestire correttamente le chiavi, devi essere estremamente attento al modo in cui formatti i blocchi di testo in chiaro RSA o finisci con le vulnerabilità.

  3. La chiave pubblica non funziona senza un'infrastruttura di gestione delle chiavi . Se non disponi di uno schema per verificare le chiavi pubbliche, gli aggressori possono sostituire le proprie coppie di chiavi con quelle reali per lanciare "man in the middle" attacchi. Ecco perché SSL ti obbliga a passare attraverso il rigamarole dei certificati. Gli algoritmi di crittografia a blocchi come AES soffrono anche di questo problema, ma senza una PKI, AES non è meno sicuro di RSA.

  4. Le operazioni di crittografia a chiave pubblica sono sensibili a più vulnerabilità dell'implementazione rispetto a AES . Ad esempio, entrambe le parti di una transazione RSA devono concordare parametri , che sono numeri inviati all'equazione RSA. Esistono valori malvagi che gli aggressori possono sostituire per disabilitare silenziosamente la crittografia. Lo stesso vale per Diffie Hellman e ancora di più per Elliptic Curve. Un altro esempio è la vulnerabilità di RSA Signature Forgery verificatasi 2 anni fa in più implementazioni SSL di fascia alta.

  5. L'uso della chiave pubblica è la prova che stai facendo qualcosa "fuori dal comune" . Fuori dall'ordinario è esattamente ciò che non mai vuoi essere con la crittografia; oltre ai soli algoritmi, i design crittografati vengono controllati e testati per anni prima di essere considerati sicuri.

Ai nostri clienti che desiderano utilizzare la crittografia nelle loro applicazioni, facciamo due raccomandazioni:

  • Per " dati a riposo " ;, usa PGP . Veramente! PGP è stato battuto per più di un decennio ed è considerato sicuro da stupidi errori di implementazione. Ci sono varianti open source e commerciali di esso.

  • Per " dati in volo " ;, usa TLS / SSL . Nessun protocollo di sicurezza al mondo è meglio compreso e testato meglio di TLS; gli istituti finanziari lo accettano ovunque come metodo sicuro per spostare i dati più sensibili.

Ecco una scrittura decente [matasano. io e Nate Lawson, un crittografo professionista, ho scritto qualche anno fa. Copre questi punti in modo più dettagliato.

Utilizza OpenSSL speed comando per confrontare gli algoritmi e vedere di persona. 

[dave@hal9000 ~]$ openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 26126940 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 7160075 aes-128 cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     139343.68k   152748.27k   155215.70k   155745.61k   157196.29k


[dave@hal9000 ~]$ openssl speed rsa2048
Doing 2048 bit private rsa's for 10s: 9267 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 299665 2048 bit public RSA's in 9.99s
...
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.001078s 0.000033s    927.6  29996.5

I pratici sistemi di crittografia basati su PKI utilizzano la crittografia asimmetrica per crittografare una chiave simmetrica, quindi la crittografia simmetrica con quella chiave per crittografare i dati (detto ciò, qualcuno indicherà un contro-esempio).

Quindi l'overhead aggiuntivo imposto dagli algoritmi crittografici asimmetrici rispetto a quello simmetrico è fisso - non dipende dalla dimensione dei dati, solo dalle dimensioni della chiave.

L'ultima volta che ho provato questo, convalidando una catena di circa 3 certificati X.509 [modifica per aggiungere: e i dati che stavano firmando] stava impiegando una frazione di secondo su un ARM funzionante a 100MHz o giù di lì (media su molte ripetizioni, ovviamente). Non ricordo quanto piccolo - non trascurabile, ma ben meno di un secondo.

Mi dispiace non ricordare i dettagli esatti, ma il riepilogo è che, a meno che non si utilizzi un sistema molto limitato o si esegua molta crittografia (come se si desidera accettare quante più connessioni SSL possibili al secondo), I metodi di crittografia asimmetrica approvati dal NIST sono veloci.

Apparentemente è 1000 volte peggio. ( http://windowsitpro.com/article/articleid/93787 /symmetric-vs-asymmetric-ciphers.html ). Ma a meno che tu non stia davvero lavorando su molti dati, non importerà. Quello che puoi fare è utilizzare la crittografia asimmetrica per scambiare una chiave di crittografia simmetrica.

Forse puoi aggiungere alcuni dettagli sul tuo progetto in modo da ottenere risposte di qualità migliore. Cosa stai cercando di proteggere? Da chi? Se potessi spiegare i requisiti della tua sicurezza, otterrai una risposta molto migliore. Le prestazioni non significano molto se il meccanismo di crittografia non protegge ciò che pensi che sia.

Ad esempio, i certificati X509 sono un modo standard industriale per proteggere gli endpoint client / server. L'armatura PGP può essere utilizzata per proteggere i file di licenza. Per semplicità, il blocco di cifratura concatenato con Blowfish (e una serie di altri cifrari) è facile da usare in Perl o Java, se controlli entrambi gli end point.

Grazie.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top