Riguardo alla sicurezza, perché la crittografia one-time pad è incondizionatamente protetta contro l'intercettazione?
Inoltre, perché il triplo DES utilizza una combinazione di crittografia-decrittografia-crittografia piuttosto che una tripla combinazione di lettere?
Un codice Vernam (il nome ufficiale del one-time pad) è sicuro perché qualsiasi valore crittografato può essere ugualmente decrittografato su qualsiasi valore di testo normale. Se ho il valore del testo cifrato HFKCV, potrebbe decifrare su HELLO, o START, o STOP !, dipende esclusivamente dalla chiave.
Ma la sicurezza si basa sul fatto che i byte della chiave siano veramente casuali, con la proprietà critica che ogni byte della chiave non deve essere correlato ad ogni altro byte della chiave. (La sicurezza può anche essere infranta se il materiale della chiave viene mai riutilizzato, ma ciò consente un attacco diverso da quello che descrivo qui sotto.)
Il problema è che molti cosiddetti one-time-pad non tengono conto delle implicazioni di un processo di generazione di chiavi non casuali. Credono di poter prendere l'output di rand () o l'output di un algoritmo hash e che sia sufficientemente casuale. Ma questi algoritmi sono spesso deterministici, generano byte correlati tra loro e questo è sufficiente per rompere la crittografia.
Usiamo un "generatore di numeri casuali" deliberatamente scarso come un generatore di chiavi per dimostrare l'importanza del processo di selezione del numero casuale. Questa povera routine di numeri casuali prende il seme, ne aggiunge uno e lo emette come un numero casuale. Per crittografare il messaggio in chiaro HELLO con questo meccanismo, avremmo un flusso di chiavi generato di 1, 2, 3, 4, 5 e il valore crittografato sarebbe IGOPT. Come utente malintenzionato che apprende IGOPT == HELLO, potrei esaminare il flusso di chiavi utilizzato per generarlo e notare che il modello è 1, 2, 3, 4, 5. Ciò potrebbe consentire di eseguire il reverse-engineer del generatore di numeri casuali e trovare un modo per decodificare qualsiasi messaggio. (In questo caso, ho appreso che la funzione di crittografia si è spostata da un pad casuale ad "addizione".) L'idea importante è lo stesso approccio all'ingegneria inversa indipendentemente da quale "funzione casuale" viene utilizzata per generare la chiave Materiale.
-
Per rispondere alla tua altra domanda non correlata, 3DES ha utilizzato EDE per abilitare la migrazione dalle vecchie installazioni a 8 byte chiave alle nuove installazioni a 24 byte chiave. Quando molti istituti finanziari hanno utilizzato DES singolo con chiavi a 8 byte per proteggere le transazioni bancarie e le autorizzazioni di addebito al dettaglio. Una volta che il singolo DES è stato scoperto debole, è stato necessario trovare un modo per aumentare la sicurezza rimanendo compatibile con le versioni precedenti, perché non tutte le banche e i rivenditori potevano sincronizzare tutti i loro sistemi di crittografia durante la notte. (Le banche avrebbero "moduli di sicurezza hardware" (HSM), mentre i dettaglianti avevano decine di migliaia di pad PIN ai loro registratori di cassa, tutti hanno bisogno di usare la stessa chiave di base per la crittografia. La modifica di alcuni HSM è stata moderatamente costosa per le banche, ma cambiare migliaia di pad PIN è stato incredibilmente costoso per i rivenditori.)
L'uso di 3DES in modalità EDE consente di utilizzare un singolo tasto a 8 byte per tutte e tre le operazioni (chiamato "opzione di codifica 3") e di rimanere compatibile con qualcuno che ha solo DES singolo e una chiave a 8 byte. È compatibile perché la prima crittografia viene completamente annullata dalla seguente decrittografia, quindi la terza crittografia diventa l'unica crittografia efficace. In questo modo una banca poteva aggiornare silenziosamente i propri sistemi in modo da essere in grado di supportare 3DES mantenendo la stessa vecchia chiave da 8 byte, mentre i loro clienti continuavano a utilizzare un singolo DES con la stessa chiave. Infine, i loro clienti hanno quindi aggiornato i loro pad PIN ai sistemi 3DES che hanno permesso loro di essere iniettati con una chiave da 24 byte. Solo allora le comunicazioni saranno correttamente protette da 3DES.
La pagina di Wikipedia su One-Time Pad ha una spiegazione ragionevole sul perché OTP sia incondizionatamente sicuro; ma qui è più breve: OTP è incondizionatamente sicuro perché qualsiasi messaggio crittografato potrebbe essere la crittografia di qualsiasi altro messaggio in chiaro della stessa dimensione, con uguale probabilità.
Per 3DES, vedi questa risposta , come suggerisce @CodesInChaos. Riepilogo: è per facilitare la retrocompatibilità con DES e una transizione graduale.
Leggi altre domande sui tag encryption