Questa semplice comunicazione crittografata XOR è assolutamente sicura?

23

Supponiamo che Alice e Peter abbiano ciascuno una chiavetta USB da 4 GB. Si incontrano e salvano su entrambi i bastoncini due file denominati alice_to_peter.key(2 GB) e peter_to_alice.key(2 GB) che contengono bit generati casualmente. Non si incontrano mai più, ma comunicano elettronicamente. Alice mantiene anche una variabile chiamata alice_pointere Peter mantiene la variabile chiamata peter_pointer, entrambe inizialmente impostate su zero.

Quando Alice ha bisogno di inviare un messaggio a Peter, lo fa (dov'è nl'ennesimo byte del messaggio):

encrypted_message_to_peter[n] = message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]
encrypted_payload_to_peter = alice_pointer + encrypted_message_to_peter
alice_pointer += length(encrypted_message_to_peter)

~~(e per la massima sicurezza, la parte usata della chiave può essere cancellata)~~

Peter riceve encrypted_payload_to_peter, legge alice_pointermemorizzato all'inizio del messaggio e fa:

message_to_peter[n] = encrypted_message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]

~~E per la massima sicurezza, dopo aver letto il messaggio cancella anche la parte usata della chiave.~~ - EDIT: In effetti questo passaggio con questo semplice algoritmo (senza controllo di integrità e autenticazione) riduce la sicurezza, vedi di seguito il messaggio di Paŭlo Ebermann.

Quando Peter ha bisogno di inviare un messaggio ad Alice, fanno il contrario, questa volta con peter_to_alice.keye peter_pointer.

Con questo schema banale possono inviare ogni giorno per i prossimi 50 anni 2 GB / (50 * 365) = ~ 115 kB di dati crittografati in entrambe le direzioni. Se hanno bisogno di più dati per inviare, potrebbero usare chiavi più grandi, ad esempio con HD da 2 TB di oggi (chiavi da 1 TB), sarebbe possibile scambiare 60 MB / giorno per i prossimi 50 anni! Ci sono molti dati in pratica; ad esempio, usando la compressione è più di un'ora di comunicazione vocale di alta qualità.

Mi sembra che non sia possibile per un aggressore leggere i messaggi crittografati senza le chiavi, perché anche se hanno un computer infinitamente veloce, con la forza bruta possono ottenere tutti i messaggi possibili sotto il limite, ma questo è un numero astronomico dei messaggi e l'attaccante non sa quale di essi sia il messaggio effettivo.

Ho ragione? Questo schema di comunicazione è davvero assolutamente sicuro? E se è sicuro, ha il suo nome? La crittografia XOR è ben nota, ma sto cercando il nome di questa pratica applicazione concreta che utilizza chiavi di grandi dimensioni su entrambi i lati? Mi aspetto umilmente che questa applicazione sia stata inventata qualcuno prima di me. :-)

Nota: se è assolutamente sicuro, allora è sorprendente, perché con i moderni dispositivi di archiviazione di grandi dimensioni a basso costo, sarebbe molto più economico fare comunicazioni sicure rispetto alla costosa crittografia quantistica, e questo ha una sicurezza equivalente!

EDIT: penso che questo sarà più pratico in futuro con la riduzione dei costi di archiviazione.~~Può risolvere comunicazioni sicure per sempre.~~Oggi non hai alcuna certezza se qualcuno attacca con successo cifre esistenti anche un anno dopo e rende insicure le sue implementazioni spesso costose. In molti casi prima che avvenga la comunicazione, quando entrambe le parti si incontrano personalmente, è il momento di generare le chiavi. Penso che sia perfetto per la comunicazione militare, ad esempio tra sottomarini che possono avere HD con tasti di grandi dimensioni, e la centrale militare può avere un HD per ogni sottomarino. Potrebbe anche essere pratico nella vita di tutti i giorni, ad esempio per controllare il tuo conto bancario, perché quando crei il tuo account incontri la banca ecc.

communication encryption

— user3123061
fonte

4

Oltre allo schema specifico per coordinare quale parte della chiave usare, questo è solo un pad una tantum . Ma sotto un esame più attento risulta non essere effettivamente utile per il 99% dei casi d'uso.

10

Poiché questa domanda riguarda la forza di un particolare algoritmo di crittografia, potrebbe essere più adatta a crypto.stackexchange.com . Per spostare la tua domanda lì, puoi segnalare l'attenzione del moderatore e chiedere la migrazione.

— Bart van Ingen Schenau,

12

Gli OTP furono inventati oltre un secolo fa e furono usati, come veri e propri blocchi di carta fisici, in entrambe le guerre mondiali. ( en.wikipedia.org/wiki/One-time_pad ) Il problema nella crittografia allora come adesso è lo scambio di chiavi.

— Gort the Robot

6

Si noti che ciò lascia ancora a risolvere il problema di generare abbastanza chiavi univoche per tutti i dati previsti fino a quando le due parti si incontrano di nuovo, e che le chiavi devono essere generate tramite un processo GENUINAMENTE casuale - i generatori di numeri pseudocasuali sono vulnerabili all'analisi, sempre più man mano che diventano disponibili più campioni utilizzando lo stesso PRNG.

— Keshlam,

1

@keshlam. La generazione di veri numeri quantici casuali sta diventando molto economica. Interessante articolo su arxiv: generazione di numeri casuali quantistici su un telefono cellulare: arxiv.org/abs/1405.0435

— user3123061

50

Sì, questo è un pad One-time . Se il materiale chiave non viene mai riutilizzato, è teoricamente sicuro.

L'aspetto negativo è che avresti bisogno di una chiave per coppia di entità comunicanti e che avresti bisogno di un modo sicuro per scambiare il materiale chiave prima di comunicare.

— Vatine
fonte

52

Penso che valga la pena sottolineare che "teoricamente sicuro" significa che è matematicamente dimostrato infrangibile , a condizione che le chiavi siano veramente casuali e non riutilizzate. Questa è praticamente la più forte garanzia che puoi ottenere ovunque nella crittografia.

— Michael Borgwardt,

1

@MichaelBorgwardt punto enorme lì. In questo caso "teoricamente sicuro" in realtà è meglio di "praticamente sicuro".

— Segna il

2

caso specifico: ho una chiave casuale da 2 GB che ha 16 byte sequenziali di 0.

— Michael

@Michael Le probabilità che ciò accada sono circa 1 su 10 ^ 27.

— questo

1

@Floris Il mio "calcolo": un byte ha 256 valori possibili. Quello è uno su 256 che tutto sarà zero. 256 ^ 16 per avere la possibilità di 16 byte. E quindi dividi il numero di byte in 2 GB per quella possibilità. Penso di aver perso una divisione per 16, comunque qui (1024 * 1024 * 1024 * 1024 * 2 * (1/16)) / (256 ^ 16) Il tuo ultimo punto rende comunque questo calcolo irrilevante.

— questo

32

Come indica la risposta di Vatine , il tuo algoritmo è sostanzialmente un pad unico.

Tuttavia, per commentare una delle tue note:

Nota: se è assolutamente sicuro, allora è sorprendente perché con grandi memorie oggi a basso costo è praticamente un modo molto più economico di comunicazione sicura rispetto alla costosa crittografia quantistica e con una sicurezza equivalente!

La mia risposta è no, non è sorprendente. Il diavolo è sempre nei dettagli, e il diavolo qui è nello scambio di chiavi. Il tuo metodo dipende da uno scambio di chiavi impeccabile, faccia a faccia. Non posso permettermi di inviare James Bond con un disco flash da 4 GB per me a tutti i commercianti su Internet ogni volta che voglio comprare qualcosa o avere altre connessioni sicure.

Infine, l'aspetto XOR del tuo algoritmo non è importante. Un semplice codice di sostituzione va bene con un OTP. Il punto di forza dell'OTP è che la chiave non viene mai riutilizzata e si presume che James Bond stia scambiando le chiavi in modo impeccabile per entrambe le parti (ovvero un precedente scambio sicuro di chiavi)

— comesichiama
fonte

13

L'altra cosa su un'OTP è che la chiave è (almeno) fino a quando il messaggio da cifrare, e ha bisogno di molto alta qualità fonte di numeri casuali.

— Donal Fellows,

Molti algoritmi di crittografia funzionano in qualche modo convertendo una chiave in un flusso di dati indistinguibile da dati casuali, quindi utilizzando tali dati come un time pad. Dal punto di vista di un utente malintenzionato, non vi è alcuna differenza tra i dati realmente casuali e quelli che sono indistinguibili dai dati casuali (per definizione; se hai trovato una differenza, non era indistinguibile), quindi in teoria questo è sicuro quanto OTP . Naturalmente, quando diciamo che i dati sono indistinguibili da veri dati casuali, di solito c'è un mucchio di avvertenze. Questa spiegazione è ovviamente una grossolana semplificazione.

— Brian,

21

Mentre il one-time-pad ha una garanzia di privacy incondizionata (provata matematicamente) contro un utente malintenzionato che può solo leggere i messaggi, presenta alcuni punti deboli.

Un utente malintenzionato intercettante che indovina correttamente il testo in chiaro può manipolare il testo cifrato in base a ciò che desidera (con la stessa lunghezza).
Se un utente malintenzionato inserisce o elimina un messaggio (o parte di esso), i puntatori di Alice e Bob diventano fuori sincrono e ogni comunicazione futura viene interrotta.

Aggiornamento: questo presupponeva che entrambe le parti tenessero traccia di entrambi i puntatori. Se si invia il valore corrente del puntatore, si è vulnerabili agli attacchi a due tempi (se si consente di utilizzare lo stesso intervallo di chiavi più di una volta) o agli attacchi DOS (se non si consente lo stesso intervallo di chiavi da utilizzare più di una volta, ad es. eliminandoli).

Entrambi questi problemi sono causati dalla mancanza di integrità e protezione dell'autenticazione: hai un codice perfetto, ma nessun MAC.

Aggiungi un MAC al protocollo one-time-pad per renderlo effettivamente sicuro. Ogni messaggio dovrebbe ottenere un "checksum" che garantisce che sia stato effettivamente inviato dal presunto mittente e che non sia stato modificato nel mezzo. Inoltre, è necessario inviare un numero di sequenza in modo che il destinatario sappia quale parte della chiave utilizzare quando un messaggio precedente è stato perso (o per rifiutare il messaggio se è duplicato) - includerlo nel calcolo del checksum.

Un normale algoritmo MAC farebbe qui, ma suppongo che potresti voler usare un MAC polinomiale una tantum per avere la sicurezza corrispondente al tuo pad una tantum. (Prendi la chiave MAC dai bit prima o dopo la chiave di crittografia, ovvero non riutilizzare una chiave per entrambi gli obiettivi.)

— Paŭlo Ebermann
fonte

Se un utente malintenzionato inserisce o elimina un messaggio (o parte di esso), i puntatori di Alice e Bob diventano fuori sincrono e ogni comunicazione futura viene interrotta. I puntatori sono indipendenti e non devono essere sincronizzati, quindi nessuna comunicazione futura viene interrotta in caso di perdita del messaggio (l'offset effettivo della chiave utilizzata per crittografare il messaggio viene inviato con quel messaggio). Ma hai in parte ragione: la parte fuori sincrono viene utilizzata parte della chiave sul lato di ricezione che non viene cancellata perché il messaggio eliminato non viene ricevuto (la parte utilizzata verrà cancellata con il successivo messaggio ricevuto).

— user3123061

Ma hai ragione. Presentato algoritmo semplice perdere integrità e autenticazione. L'implementazione pratica dovrà essere più solida.

— user3123061

@ user3123061 Non mi limiterei a scrollarmi di dosso integrità e autenticazione se fossi in te. La tecnica di attacco di testo cifrato scelto adattivo sfrutta l'assenza di protezione dell'integrità per violare la riservatezza . Vorrei dire che il classico pad una tantum (che è quello che hai reinventato) è assolutamente insicuro , nonostante la sua apparente solidità matematica, proprio a causa di questo attacco.

— zwol,

2

L'attacco adattivo cipertext scelto è una scelta piuttosto scarsa di attacco contro un OTP controllato dall'uomo. OOS verrà notato e il tuo attaccante verrà colpito abbastanza velocemente. Solo se il ricevitore viene elaborato a macchina e produce una risposta, questo attacco è assolutamente utile.

— Giosuè,

@Zack Ci sono molti problemi con gli OTP, ma nessuno minaccia la riservatezza. Si noti che anche se si indovina perfettamente la chiave + plantext del messaggio precedente, il messaggio successivo viene crittografato con una chiave completamente nuova e indipendente (anche di dimensioni considerevoli). Non c'è nulla su cui adattarsi per interazioni multiple.

4

In realtà non è del tutto sicuro. Ciò che perde il protocollo è la LUNGHEZZA del messaggio comunicato.

Ad esempio, se la spia sa che risponderai con "sì" o "no" e vedrà la lunghezza = 2 può dedurre che è "no".

In realtà è sorprendente quanto si possa dedurre solo da lunghezze note se si può indovinare il contesto.

— w.pasman
fonte

3

È abbastanza facile da risolvere, tuttavia, a un livello ragionevole di sicurezza, poiché puoi riempire il messaggio con spazzatura casuale, quindi la lunghezza del messaggio è multipla di una dimensione di blocco fissa, ad esempio 256 caratteri. Ciò vanificherebbe una semplice analisi sì / no, al costo di utilizzare l'OTP più velocemente.

— Peter Bagnall,

Infatti, poiché puoi inviare ~ 115kB ogni giorno per i prossimi 50 anni, potresti aspettarti che ogni blocco sia almeno 20kb, il che significa che la lunghezza non è così importante.

— apnorton,