Sono ancora nuovo nella sicurezza delle informazioni, ma ho letto un po 'del one-time pad . Il punto che mi viene maggiormente in mente è che è presumibilmente infrangibile. Questo metodo di crittografia è mai stato incorporato in qualsiasi applicazione Web su scala più ampia? Come avrebbero passato la chiave?
Il problema con una volta sola è che deve essere uguale in lunghezza (o più lungo) rispetto ai dati crittografati e non deve mai essere riutilizzato.
Proprio come si indica, how would they send the key? , l'OTP deve quindi essere inviato in modo sicuro ... tuttavia questo è il problema che di solito è lasciato all'utente ed è in genere il motivo per cui OTP è inutile.
Se hai la possibilità di inviare un OTP di grandi dimensioni in modo sicuro, potresti pensare di inviare semplicemente le informazioni che desideri crittografare direttamente al destinatario su quel canale protetto.
Tuttavia il vantaggio di un OTP è di spostare la segretezza nel tempo . Se hai un canale sicuro ora (ad esempio una riunione di persona) puoi scambiare un OTP. Hai messo un po 'di segretezza per dopo. Più tardi, quando non hai un canale sicuro, puoi utilizzare una parte del tuo pad per rendere segreto il tuo messaggio.
Il miglioramento rispetto a OTP è dove fanno un piccolo seme (una chiave) e usano un expander chiamato PRNG per espandere quella chiave in quella che è essenzialmente una cifratura di flusso. In questo modo invii solo una piccola quantità di dati in modo sicuro e puoi crittografare molti dati con quella chiave espansa. Questo è chiamato "key stretching".
How would they pass they key?
Questo arriva alla radice da dove provengono gli OTP, e in effetti come hanno ottenuto quel nome.
Questo è per la corrispondenza durante la guerra con navi o altri agenti simili [*] . Quando la nave lascia il porto, esce con un blocco di dati casuali. Quando ricevono una comunicazione crittografata via radio, la decodificano usando il foglio indicato dal loro pad casuale, quindi distruggono quel foglio.
Quindi qual è il livello di segretezza della trasmissione? Se il pad viene utilizzato e implementato correttamente, allora la segretezza del messaggio è uguale alla segretezza del pad . Non ha nulla a che fare con la segretezza della trasmissione radio. Invece, per quanto siano attenti a gestire e archiviare il decryption pad, determinano la vulnerabilità del messaggio. Stanno usando efficacemente la tecnica OTP per conferire il livello di segretezza di un oggetto consegnato in un punto a un messaggio consegnato in seguito.
Questo è l'uso e lo scopo della (solo) della tecnica. Se vedi le OTP in uso oggi per la crittografia generale, l'utente quasi certamente non capisce cosa sta facendo. Questa tecnica non può essere incorporata correttamente nella comunicazione elettronica comune ed è totalmente inappropriata per cose come le applicazioni web.
[*] Non sono sicuro che questo sia mai stato effettivamente utilizzato per la comunicazione shore-to-ship, ma il concetto di un agente che lascia la base per un periodo di tempo si adatta alla metafora della "nave" più da vicino. Spesso gli OTP sono stati usati dalle spie.
Non proprio "Internet", ma il blocco temporaneo è stato documentato per essere stato utilizzato per Rosso Telefono (un nome di stampo occidentale, non so come l'abbiano chiamato a Mosca). I pad sono stati scambiati su nastri magnetici, inviati da aerei su base settimanale. È possibile che il sistema attuale utilizzi ancora un metodo di crittografia simile.
Questo ha senso: sebbene il one-time pad richieda una chiave tanto grande quanto i dati che devono essere trasmessi, offre comunque un vantaggio basato sul tempo: puoi scambiare le chiavi in anticipo, in un momento in cui il trasferimento sicuro di massa è fattibile e quindi li usa quando il tempo è essenziale (ad esempio dieci minuti prima di lanciare l'ICBM, non dieci minuti dopo).
Pidgin instant messenger ha un plugin che implementa la crittografia OTP dei messaggi inviati via cavo, chiamata pidgin-paranoia . Quindi esiste almeno un sistema di crittografia OTP.
Tuttavia, in base alla presentazione di USE OTR al FOSDEM 2014, Pidgin non è assolutamente un software sicuro perché ha oltre 300.000 linee di codice C scarsamente controllato, molti dei quali si occupano di analizzare i dati binari. Dovrebbe essere abbastanza sfruttabile, e una volta sfruttato l'aggressore potrebbe semplicemente sottrarre il testo in chiaro.
La sicurezza sembra migliorare con l'imminente Pidgin 3.0, ma se sei abbastanza paranoico da usare OTP, non dovresti mai usare Pidgin (o anche i sistemi operativi generici per quella materia).
Anche OTP in Pidgin non ha visto largo uso perché ci deve essere un buon cryptosystem IM chiamato OTR che è più che sufficiente per la stragrande maggioranza dei casi d'uso.
Non supposto; Notoriamente, Claude Shannon ha dimostrato che una volta sola ha "segretezza perfetta" e non può essere infranta con un attacco di forza bruta.
Ma nessuno lo usa su Internet perché risulta che in pratica non si ha realmente bisogno di una segretezza perfetta. Sto bene se puoi forzare la crittografia che sto usando se ci vorranno 20 milioni di anni.
E gli schemi di crittografia alternativi hanno un grande vantaggio rispetto ai one-time pad: le chiavi possono essere molto più piccole e quindi sono molto più facili da proteggere e scambiare.
es. la banca finlandese di Pohjola usa pad monouso. Ho ottenuto il primo tramite normale snailmail e ne ho ricavati di nuovi quando visito la banca. Una lista ha 350 voci e ne ho bisogno una per registrarmi e un'altra per accettare il pagamento delle fatture. Se l'importo è maggiore (migliaia di euro), la banca invia come messaggio di testo le informazioni che scelgo il numero di una sola volta. Si sente molto sicuro e maneggevole, almeno finché non so come vengono creati i numeri. L'elenco ripiegato ha esattamente le stesse dimensioni di una carta di credito nel mio portafoglio.
L'articolo di WikiPedia ha una descrizione abbastanza buona sui punti deboli pratici di OTP, e perché non usato nel calcolo moderno.
Ad esso posso solo aggiungere che anche sulle reti moderne la trasmissione non è perfetta ei bit possono capovolgere, e quindi i messaggi vengono controllati (credo includendo un hash del messaggio originale) per verificare che il messaggio sia stato consegnato intatto. Senza di esso, non ci sarebbe alcun modo per verificare che il messaggio ricevuto sia effettivamente passato attraverso il filo intatto e sia quindi un messaggio valido. Questo, inturn, toglierebbe il segreto perfetto poiché ora può essere forzato bruto (con successo della forza bruta valutata facendo corrispondere l'hash all'originale).
Ad esempio, esaminiamo l'esempio nell'articolo nella sezione "Tentativo di crittanalisi" che illustra che l'autore dell'attacco non può sapere se "LATER" è il messaggio originale per una potenziale chiave bruta-forzata "TQURI".
Lascia che una funzione di hash della convalida della trasmissione (a.k.a. decrittografia) sia definita come H = Sum(characters) Mod Count(characters) , che somma tutti i caratteri del messaggio e quindi la divisione dei moduli per numero di caratteri.
Con tale funzione di hashing, il messaggio originale HELLO verrebbe codificato con il codice hash (7 + 4 + 11 + 11 + 14) % 5 = 2 . Il destinatario del messaggio prenderebbe quindi un messaggio decrittografato, ricalcolare l'hash sui dati ricevuti e verificare che il risultato sia 2 .
Ora, valutando la potenziale chiave bruta forzata TQURI , il testo decrittografato è LATER . Senza il codice hash per convalidare il messaggio, l'intercettore non ha modo di sapere se la chiave TQURI effettivamente ha funzionato o meno (sicurezza perfetta). Con la chiave hash, l'intercettore può ora convalidare calcolando la chiave hash per LATER che è (11 + 0 + 19 + 4 + 17) % 5 = 1 . Poiché il codice hash calcolato 1 non corrisponde all'hashcode% del2 del messaggio originale, l'interceptor ora sa che il messaggio originale non è LATER e la chiave TQURI non è una chiave valida, quindi continua ad enumerare e brute-force chiavi finché un tasto non produce un codice hash corrispondente (non una sicurezza perfetta a causa dell'abilità bruta-forzante).
Il pad singolo non viene quasi mai utilizzato per motivi già trattati. Come è stato sottolineato ha una sicurezza perfetta (supponendo che sia stato generato da una fonte veramente casuale) - poiché la "password" è di uguale lunghezza per il messaggio, non c'è nessuna deviazione statistica da "perfettamente casuale" con cui interrompere la password.
Gli algoritmi di crittografia moderni cercano di approssimare un pad singolo utilizzando ciò che è chiamato key schedule . La pianificazione chiave viene utilizzata per generare il "pad" secondo necessità. Tuttavia, non sono perfetti, motivo per cui non è consigliabile crittografare i messaggi di una certa dimensione, ad esempio AES-128 non è raccomandato per l'uso con "messaggi" di dimensioni superiori a 1 TB.
Prima di passare a un'app mobile, la mia banca usava qualcosa del genere per firmare e accedere. Hanno inviato una carta (tramite posta raccomandata) con un codice temporale che in combinazione con il mio PIN è stato utilizzato per verificare l'accesso.
Leggi altre domande sui tag encryption key-exchange one-time-pad