Implementazione hardware dell'algoritmo di crittografia

Question

Implementazione hardware dell'algoritmo di crittografia

#1 da (4 voti)

1

Nell'abstract del RFC AES-GCM , il passaggio seguente è in primo piano:

[AES-GCM] can be efficiently implemented in hardware for speeds of 10 gigabits per second and above...

La facilità / efficienza dell'implementazione hardware è una considerazione significativa nella suite di crittografia o nella modalità di crittografia? In tal caso, quanto è grande la popolarità del sistema?

Più in pratica, ci sono esempi di codici comuni che presentano serie sfide nell'implementazione? O questo li sconterebbe immediatamente?

AES Competition

Sul suggerimento di LateralFractal, ho esaminato i criteri di valutazione del progetto per il concorso AES . Esiste una riga che fa riferimento all'hardware (il criterio è indicato come "Idoneità hardware e software"). Detto questo, ciò non dice ancora fino a che punto questo criterio sia preso in considerazione.

Esempio di DFC

Questo documento che descrive un attacco su DFC sembra essere un buon esempio del mondo reale. Visto che questo SO di Thomas Thomas ha avuto un ruolo nello sviluppo del codice, sarei curioso di sentire:

La gravità di questo attacco proposto agli occhi della comunità
Risposta degli autori di crittografia
Possibili modi in cui questo attacco avrebbe potuto essere evitato

hardware cryptography encryption aes

posta msuozzo 16.10.2014 - 03:28

fonte

1 risposta

Leggi altre domande sui tag hardware cryptography encryption aes

Problemi con l'utilizzo di SET in Kali Perché aggiungere "***" in user-agent in questo codice dannoso?

score 4 · Answer 1

Il concorso AES ha ricevuto 15 candidati, due dei quali hanno subito "interruzioni accademiche" (punti deboli che sono solo teorici, ma dimostrano comunque che il codice a blocchi sottostante non è "ottimamente sicuro"). I rimanenti 13 sono, per quanto ne so, ancora ininterrotti fino ad oggi.

Pertanto, la scelta di Rijndael doveva essere fatta per ragioni diverse dalla sicurezza. Le prestazioni, in particolare la facilità di implementazione in modo efficiente su numerose piattaforme software e hardware, erano ciò che contava alla fine. Rijndael è stato scelto perché si è comportato bene su molti sistemi. Su un PC, RC6 era più veloce, ma su altre piattaforme (CPU basata su RISC come Sparc, CPU a 8 bit su smart card, FPGA ...) Rijndael era più veloce / economico (RC6 richiede una moltiplicazione di 32x32 bit, che è economica quando ce l'hai già, non così quando non lo fai). Del resto, DFC era peggio, dal momento che aveva bisogno di una moltiplicazione 64x64. L '"attacco" descritto da Harvey è più un'osservazione che la riduzione modulo 2 ⁶⁴ +13, sebbene possa essere fatta senza una divisione (che sarebbe ancora più costosa), può essere difficile da fare correttamente , ovvero senza informazioni che perdono (vedi attacchi temporali ).

Altri criteri informali comprendevano il fatto che anche il programma chiave di Rijndael era veloce (contrariamente a, diciamo, Twofish), e che gli inventori di Rijndael provenivano da un piccolo paese non minaccioso, non controverso, caratteristico (Belgio), quindi più probabile portare all'adozione in tutto il mondo.

Come altro esempio, quasi tutta la competizione SHA-3 riguardava le prestazioni. Tutti e 14 i candidati del secondo turno sono "ugualmente forti" (non sappiamo come rompere nessuno di essi, anche in un modo accademico non realistico), ma non erano equivalenti se implementati in software o hardware. I criteri di scelta ultimate non sono mai stati chiariti dal NIST (e sembra che siano cambiati a metà competizione), ma il fatto che Keccak sia diabolicamente veloce nell'hardware (ASIC / FPGA) è stato certamente strumentale alla sua vittoria.