Domanda:
Why even use a one-time pad if the key distribution is fully secured?
Riley Willow
2016-06-11 13:26:35 UTC
view on stackexchange narkive permalink

Ieri ho avuto un colloquio di lavoro in cui mi hanno chiesto quale sarebbe l'unico scenario in cui un blocco unico può essere rotto, la mia risposta è stata "quando il processo di distribuzione delle chiavi non è abbastanza sicuro".

Hanno elogiato la mia risposta, ma mi hanno fatto un'altra domanda: perché dovresti usare anche un blocco unico se la distribuzione delle chiavi è sicura al 100%? Perché non inviare semplicemente il messaggio di testo normale poiché sei sicuro che la distribuzione sia sicura al 100%?

Qual è la risposta corretta a questa domanda?

Non sono sicuro di cosa comporti la definizione di "canale protetto", ma la distribuzione delle chiavi è in una direzione (A -> B) e il messaggio è nell'altra (B -> A).
anche una cattiva generazione di chiavi può essere problematica, vedere VENONA et al
Potrebbe essere che tu voglia che qualcuno sprechi risorse cercando di violare il tuo codice (non sapendo che è un OTP) sul canale insicuro.
@Bergi nel canale protetto OTP è un metodo per ottenere molte informazioni condivise tra le parti senza intercettazioni (la dimensione delle informazioni deve essere almeno la lunghezza di tutto il messaggio che si sta per inviare con quello, e tutti i messaggi se lo stessopad verrà utilizzato poiché non è possibile riutilizzare nessuna sezione di esso).La direzione dello scambio non ha molta importanza con OTP, ma non si può semplicemente inviare il pad con il messaggio, non funziona.
Inoltre, il tuo metodo di distribuzione delle chiavi non ti consente di scegliere direttamente la chiave effettiva.Ad esempio, diffie hellman consente a due parti di creare un segreto condiviso, ma nessuna delle parti sceglie il segreto stesso.
Metterei in dubbio la premessa: come puoi essere certo al 100% che il tuo canale di distribuzione sia davvero sicuro?Usare la chiave come ulteriore livello di sicurezza in più significherebbe prendere la stessa profondità di mantra di sicurezza come l'hashing delle password sul tuo database, anche se sei assolutamente sicuro che nessuno sarebbe in grado di hackerare il tuo server.
"100% sicuro" non è qualcosa che esiste realmente, che vale la pena tenere a mente.
* Solo una supposizione ... * Perché i one-time pad sono banali da implementare (semplice XOR), e quindi è più facile verificare il codice.E dovrebbe funzionare su dispositivi * molto * di fascia bassa o anche manualmente (se gestisci lo scambio di chiavi).
Sull'intervista: ho imparato che le persone di solito si aspettano che tu risponda "Quando la chiave viene riutilizzata", anche se ciò infrange la stessa premessa.
Il carattere "una volta" del pad significa che ciascuna * porzione * del pad viene utilizzata una volta.Ad esempio, se usi due mazzi di carte come un blocco orario, puoi inviare 52 caratteri prima di aver esaurito il tuo blocco, supponendo che tu consideri non sicuro riciclare il blocco.Potrebbero essere fino a 52 messaggi.E, come sottolinea kaay, il pad può essere riciclato, il che non è terribile se la lunghezza (e la natura) del pad stesso viene tenuto segreto.Ad esempio, non vorrai riutilizzare un mazzo da 52 carte se le persone * sanno * che stai usando un mazzo da 52 carte.
Riutilizzare una OTP è superbad anche se la lunghezza non è nota, specialmente se lo stream non è compresso o ha una struttura, ad esempio le intestazioni.Se effettui uno XOR a turno a ogni turno, otterrai un calo di 1 quando il pad viene riutilizzato.I bit impostati su A saranno correlati con i bit impostati su B, quindi A + B avrà più zeri, quindi (A + K) + (B + K) = A + B avrà anche più zeri.
@Simba Non importa se lo chiamiamo sicuro al 100% o sicuro al 50% o qualsiasi altro numero.La stessa domanda che pone l'OP si applica: perché non inviare il tuo messaggio su quel canale invece di un OTP?Se riesci a interrompere il canale e ottenere il messaggio, puoi interrompere il canale e ottenere l'OTP esattamente allo stesso modo.L'OTP non aggiunge alcuna profondità di sicurezza: aggiunge solo sicurezza attraverso l'oscurità, una volta che il canale stesso è compromesso, ovvero l'unica speranza rimasta è che l'attaccante non si renda conto di avere un'OTP per un messaggio futuro.
@Simba Al contrario, il tuo esempio di hashing delle password ** ** fornisce una profondità di sicurezza.Se l'aggressore hackera il tuo server, non ha ancora le password senza rompere in qualche modo il meccanismo di hashing.Con l'OTP, non appena lo ottiene, ha accesso illimitato al contenuto crittografato.
Dieci risposte:
Jeff
2016-06-11 14:30:59 UTC
view on stackexchange narkive permalink

Puoi distribuire la chiave adesso e inviare il messaggio più tardi”.

Supponi di essere una spia inviata in missione dietro le linee nemiche. Prendi la chiave con te (distribuzione sicura) e quando scopri un segreto puoi inviarlo in modo sicuro utilizzando il One-Time pad.

anche la differenza tra la dimensione di una chiave e un messaggio effettivo è un punto valido?
@user13267 Non per un blocco unico.Una chiave OTP deve essere lunga almeno quanto il messaggio;questo è il punto centrale del sistema.
@cpast Questo è il motivo per cui le spie utilizzano spesso OTP di grandi dimensioni per consentire loro di inviare messaggi protetti in un secondo momento.La distribuzione chiave in questa analogia sarebbe qualunque processo tu abbia per ottenere l'OTP nelle mani della tua spia (e di un gestore o di chiunque comunichi con lui).
La [hotline Mosca-Washington] (https://en.wikipedia.org/wiki/Moscow%E2%80%93Washington_hotline) (chiamata "telefono rosso", ma mai effettivamente un telefono) è un altro buon esempio.(È stato riferito che questo in realtà utilizzava le OTP, almeno durante la prima installazione.) Di tanto in tanto si scambiavano le OTP tramite valigia diplomatica - molto sicuro, ma lento e che doveva essere programmato in anticipo.Ma dopo averlo fatto, la hotline poteva essere utilizzata nel momento in cui si fosse reso necessario, che era il punto centrale.
Un altro ottimo esempio è SIGSALY della Seconda Guerra Mondiale, come descritto nell'episodio di 99% Invisible [Vox Ex Machina]) http://99percentinvisible.org/episode/vox-ex-machina/).Ha utilizzato record con rumore casuale come un time pad per crittografare le telefonate tra la casa bianca ei leader alleati in tutto il mondo.I record sarebbero stati inviati in modo sicuro in anticipo.Sarebbero stati distrutti al termine della comunicazione per garantire la segretezza in avanti.
Baard Kopperud
2016-06-11 20:11:23 UTC
view on stackexchange narkive permalink

Il fatto che tu possa distribuire qualcosa in modo sicuro oggi non garantisce di poterlo fare domani, o la prossima settimana o il prossimo anno.

Inoltre, il tuo canale protetto utilizzato per distribuire la chiave potrebbe avere limitazioni. Forse dipende da una persona che viaggia effettivamente tra il punto A e B ... Forse è disponibile solo in determinati orari, ad es. nei fine settimana o durante l'inverno ... Forse la sua capacità è molto limitata: dimensione massima per messaggio e / o messaggi totali che possono essere inviati (ad esempio, sembrerà sospetto se usato troppo spesso con troppo) ... Potresti anche volerlo "salva" quel canale per inviare elementi fisici (come OneTime-Pad o campioni di virus), che in realtà non possono essere trasmessi tramite radio o Internet, a differenza di testo e immagini ...

Ma il più grande ostacolo è probabilmente l'aspetto temporale. L'intelligence - il tipo di raccolta delle spie e utilizzato in guerra e in politica - ha una durata di conservazione molto limitata. Se non riesci a estrarre le informazioni immediatamente, perdono il loro valore, o perché il leggero vantaggio è andato, perché qualunque cosa avvertiva è accaduta, o perché le stesse informazioni arrivano da altre fonti.

A differenza del tuo canale protetto, è quasi garantito al 100% che telefoni, radio e Internet saranno disponibili anche il prossimo anno.

Se la capacità è limitata, OTP non funziona poiché OTP necessita di una chiave della dimensione del messaggio e la stessa chiave non può essere utilizzata per più messaggi, quindi abbiamo bisogno di una chiave sufficiente per coprire tutti i messaggi futuri prima del prossimo aggiornamento della chiave (più grande delmessaggi).
@ewanm89 Mi riferivo a problemi di capacità con il "canale sicuro" - quello usato per trasportare il OneTime-pad in primo luogo.Per definizione, non sarebbe necessario crittografare il messaggio se fosse stato inviato attraverso un canale sicuro garantito.Tuttavia, quel canale può ancora porre limiti di capacità sul mezzo inviato: forse è un corriere con un tacco di scarpa cavo che può prendere solo dieci fogli di carta.Forse è un modo per contrabbandare * un * microfilm o una scheda di memoria.Forse - per tornare alla vecchia scuola - è un piccione viaggiatore che può portare solo un piccolo foglio di carta.OTP + radio nessun tale limite!
Sì, ma la stessa OTP ** deve ** essere inviata da un canale così sicuro.Quando si utilizza un OTP, si inviano una quantità uguale o maggiore di dati tramite quel canale protetto rispetto all'invio diretto del messaggio, quindi la capacità non può essere il problema perché non utilizzare quel canale protetto per inviare messaggi direttamente.Il resto va bene e i limiti di tempo o il mancato accesso affidabile a quel canale protetto sono validi motivi per utilizzare OTP piuttosto che il canale protetto.
Ora potresti voler aggiungere, se il canale protetto sta consegnando le informazioni quando torni al quartier generale e ti trovi in territorio nemico, beh, non c'è alcuna garanzia che tu possa tornare indietro, meglio crittografare e inviare al quartier generale entroradio ora piuttosto che consegnarla di persona in seguito, quando potresti essere colpito prima di arrivarci.
@ewanm89 Ma è quindi un canale * sicuro *?Ma sì, ho capito il tuo punto.Potresti assicurarti che il messaggio venga distrutto: pellicola non sviluppata o un contenitore che brucerebbe il contenuto se aperto in modo errato. Potrebbe essere inviato da diplomatico-bracconiere.Potrebbe essere trasportato su una nave - che è il territorio della nazione in cui la nave è registrata - dal capitano della nave.Ma sì, sarebbe prudente crittografare i messaggi per ogni evenienza.Ma se il messaggio fosse abbastanza breve da essere inviato da un canale così limitato in primo luogo, non diventerebbe molto più lungo crittografandolo con OTP.
@ewanm89 Per quanto riguarda l'OTP e il canale sicuro utilizzato per distribuirlo, penso che la soluzione migliore sarebbe che l'agente lo portasse personalmente.Se fosse stato arrestato all'ingresso, l'OTP sarebbe stato compromesso ... Ma con l'agente che prigione, non sarebbe mai entrato in uso in primo luogo - almeno supponendo che l'agente avrebbe dovuto chiamare a casa e riferire di essere pronto prima di esserecontattato.
Non sto dicendo che il messaggio sarebbe più lungo, la chiave deve essere così lunga o più lunga e sto indicando direttamente che la capacità del canale sicuro non è un motivo per cui OTP dovrebbe essere utilizzato invece come la domanda chiede, ogni altro motivo inla risposta è sana.Sì, il metodo comune sarebbe portarlo fuori con te come canale sicuro che è coperto da tutte le ragioni temporali fornite.
@ewanm89, se il limite di capacità è il numero di messaggi piuttosto che la dimensione del messaggio (pensa: se stai inviando un CD, non importa se è mezzo pieno o completamente pieno, ma importa se ne stai inviando uno pergiorno contro uno all'anno), la distribuzione di una chiave OTP su un canale limitato può essere ancora pratica.
user2483352
2016-06-11 20:18:08 UTC
view on stackexchange narkive permalink

Ci sono alcuni scenari pratici, in cui si scambia una chiave e si sa solo che non è stata intercettata (ovvero lo scambio era sicuro al 100%) dopo che l'ha inviata. Se avessi trasmesso direttamente il messaggio segreto, potrebbe essere stato compromesso, ma poiché hai solo scambiato la chiave, puoi semplicemente scartarlo. Questa è tra l'altro l'idea della crittografia quantistica.

Un'altra caratteristica della crittografia quantistica è che non sei in grado di scegliere la chiave. È solo casuale e non contiene informazioni di per sé. In effetti non sei nemmeno in grado di inviare informazioni non generate casualmente attraverso il canale quantistico sicuro al 100%, il che significa che non puoi inviare direttamente il tuo messaggio segreto. Se vuoi saperne di più sull'argomento, posso consigliare la pagina di Wikipedia sulla distribuzione delle chiavi Quantum.

Buon punto sulla distribuzione delle chiavi quantistiche.
Sebbene questa sia una buona informazione da avere, non sono sicuro che questo sia uno scenario pratico per un colloquio poiché QKD non è esattamente prevalente nel settore.Come ho detto in un commento qui sotto, questo è un colloquio di lavoro, non una dissertazione sugli accademici della crittografia.
+1.Potresti aggiungere a questa risposta sistemi storici che utilizzavano sigilli a prova di manomissione sui pacchetti utilizzati per inviare blocchi unici, come il [sistema OTFP / OTLP canadese] (http://www.jproc.ca/crypto/otfp_otlp.html);il [sistema OTP DDR e URSS] (http://www.cryptomuseum.com/crypto/otp/ddr/index.htm);eccetera.
Mike Maxwell
2016-06-13 01:12:26 UTC
view on stackexchange narkive permalink

Le risposte all'effetto che la distribuzione sicura oggi non garantisce la distribuzione sicura domani sono ok, immagino, ma non c'è un altro motivo: la distribuzione delle chiavi di solito viene eseguita da qualche sito centrale alle "spie", mentre le spie inviano i loro messaggi nella direzione opposta? (Supponendo che le spie siano quelle che generano i messaggi; ovviamente i messaggi possono essere inviati in entrambe le direzioni.) La sicurezza in una direzione non implica necessariamente la sicurezza nell'altra direzione.

Un caso ovvio sarebbe l'invio di sottomarini in missione. Gli vengono dati dei pad monouso prima di andarsene, ma usa quei pad per crittografare i messaggi che stanno rimandando alla base. (La base potrebbe rispedirgli dei messaggi, il che ovviamente riporta all'altra risposta: non vuoi che i sottomarini debbano tornare in porto per raccogliere in modo sicuro i messaggi dalla base.)

È molto positivo che la Marina tedesca abbia usato Enigma, piuttosto che i blocchi di una volta, nella seconda guerra mondiale.

Ma i sottomarini usano effettivamente le OTP?L'uso di un OTP limiterebbe la quantità di testo che potrebbero crittografare (o decrittografare) in una particolare missione.
Un blocco temporale nella forma di un CD / nastro / disco rigido da leggere una volta e poi da cancellare darebbe una quantità abbastanza grande di comunicazioni totalmente sicure.
La compressione basata sul dizionario @DavidRicherby viene utilizzata comunque in [submarine comms] (https://en.wikipedia.org/wiki/Communication_with_submarines) (ad es. Radio VLF, per nave da terra).Storicamente è stato utilizzato per le comunicazioni navali sia per mascherare il contenuto del messaggio che per codificarlo in modo efficiente (il bit rate anche di un operatore morse efficiente era piuttosto basso).All'inizio degli anni '70 si poteva ottenere un'unità a nastro che memorizzava 20 MB (e non sono necessari 8 bit / simbolo, 6 è abbastanza facilmente)
dr_
2016-06-13 20:00:00 UTC
view on stackexchange narkive permalink

Ieri ho avuto un colloquio di lavoro in cui mi hanno chiesto quale sarebbe l'unico scenario in cui un blocco unico può essere rotto, la mia risposta è stata "quando il processo di distribuzione delle chiavi non è abbastanza sicuro".

Non intendo darti insicurezze sulla tua intervista, ma sono abbastanza sicuro che questa non sia la risposta corretta o, altrimenti, non ho capito la tua risposta. Questo perché la tua risposta si applica a qualsiasi metodo di crittografia: se non puoi comunicare in modo sicuro una chiave simmetrica, il gioco è finito.

L'unico scenario in cui un OTP può essere rotto ( lasciando da parte gli errori evidenti delle parti in comunicazione, come il riutilizzo di parti dell'OTP o il lasciare che il nemico ci metta le mani sopra) è quando è stato generato utilizzando una fonte non propriamente casuale . Ciò consentirebbe al nemico di eseguire un'analisi della frequenza e cercare di dedurre il testo che viene scambiato.

Infatti, un pad monouso garantisce una sicurezza perfetta ed è teoricamente indistruttibile. L'unico motivo per cui non viene utilizzato ampiamente è a causa della sua impraticabilità.

Perché dovresti utilizzare anche un blocco unico se la distribuzione delle chiavi è sicura al 100%? Perché non inviare semplicemente il messaggio di testo normale poiché sei sicuro che la distribuzione sia sicura al 100%?

La risposta a questa domanda è: poiché il canale sicuro potrebbe non essere sempre disponibile, potrebbe avere una larghezza di banda limitata o potrebbe essere troppo costoso da usare. Quindi può essere utilizzato per scambiare (una volta) una chiave di piccole dimensioni ma non (spesso) lunghe comunicazioni private.

"una chiave di piccole dimensioni ma non (spesso) lunghe comunicazioni private" - ma una chiave OTP deve essere lunga almeno quanto il messaggio che crittografa.La disponibilità limitata è un motivo valido, ma non la larghezza di banda.
Per definizione, la chiave OTP è generata da una fonte veramente casuale.È impossibile essere indistruttibili senza questo presupposto.Pertanto, non essere generati da una fonte veramente casuale non è un modo valido per violare l'OTP.L'unico modo per romperlo è conoscere la chiave.Per questo motivo, la sua risposta è corretta (poiché la chiave è sicura solo quanto lo scambio e le protezioni a riposo. In questo caso, si presume che le protezioni a riposo non siano pratiche da attaccare).
Sono d'accordo con @Qwerty01: approfittare di un'implementazione imperfetta di uno schema di crittografia non significa che hai rotto lo schema di crittografia stesso.
@Qwerty01 Potresti citare la definizione che esclude la generazione non realmente casuale?Lo chiedo perché l'articolo di Wikipedia su OTP ha una cronologia di> 10 anni di modifiche che definiscono le chiavi veramente casuali "una sfida", o l'uso condizionale "se la chiave è veramente casuale" quindi impossibile da interrompere.Se è una questione di definizione, gli intervistatori potrebbero usarne una diversa.
Il motivo per cui lo menzionano è perché la generazione di dati veramente casuali è difficile.Per questo motivo, le persone tendono a utilizzare CSPRNG per generare i dati necessari piuttosto che dati veramente casuali.Se i dati non sono veramente casuali, stai attaccando l'algoritmo che ha generato la chiave e non l'OTP.Un altro modo di pensarla è così: se usi un RNG che restituisce lo stesso numero ogni volta per generare una chiave RSA, la chiave sarà facilmente rotta: non a causa di un problema in RSA, ma a causa di un problema nel tuoRNG.
Jon Bentley
2016-06-14 17:19:58 UTC
view on stackexchange narkive permalink

Ecco un altro motivo che le altre risposte non menzionano:

Puoi utilizzare il tuo canale protetto una volta per trasmettere OTP e quindi inviare messaggi protetti più volte in seguito fino a quando le tue OTP non si esauriscono.

Questo può essere utile perché ottenere un canale sicuro al 100% (o vicino ad esso) può essere molto difficile e / o costoso, mentre i canali non sicuri sono economici, veloci e prontamente disponibile, quindi c'è un vantaggio nel ridurre al minimo la frequenza del tuo utilizzo del canale protetto.

Esempio: trasporti 1 terabyte di dati OTP trasportando fisicamente un disco rigido fino alla destinazione (operazione costosa e scomoda). È quindi possibile inviare 1 terabyte di messaggi crittografati tramite Internet come e quando necessario. È meglio che utilizzare ripetutamente il canale protetto per inviare i messaggi a mano.

Grant
2016-06-14 23:19:54 UTC
view on stackexchange narkive permalink

Un blocco unico può essere danneggiato se il messaggio da crittografare è significativamente più lungo (come più volte) del numero di caratteri / byte nel blocco. Ciò equivale a un uso ripetuto dello stesso "blocco unico" ed è ugualmente vulnerabile alla decrittazione.

Se ripeti il pad, non è più un one-time pad.
Jesse Williams
2016-06-14 23:33:55 UTC
view on stackexchange narkive permalink

Onestamente, penso che una risposta plausibile sia che non puoi garantire la sicurezza al 100%. O almeno questa sarebbe la mia risposta, probabilmente seguita da "chiunque presuma la sicurezza al 100% non capisce la sicurezza. Inoltre, chiunque presuma la sicurezza al 100% è tanto a rischio, e forse di più, di qualcuno che presume una sicurezza inferiore al 100%".

Questo è irrilevante per la domanda.Che tu abbia il 100% di sicurezza, il 99% di sicurezza o il 50% di sicurezza sul canale scelto, la domanda rimane ancora: dovrei inviare una OTP su quel canale e poi inviare un messaggio crittografato in un secondo momento, o dovrei semplicemente inviare il messaggio su quellocanale?Quanto sia sicuro il canale non fa alcuna differenza: se c'è un modo per interrompere il canale e ottenere il messaggio, lo stesso modo ti consentirà di ottenere l'OTP.
Non sarei d'accordo - questa non è una dissertazione sulla sicurezza, è una domanda di intervista.Essendo stato un responsabile delle assunzioni in Ricerca e sviluppo sulla sicurezza, mi aspetto che un candidato mi dia una risposta che mostra un'iniezione di pensiero del mondo reale in una domanda del genere.Se stavo cercando una risposta accademica, affermerei volentieri che dopo che una tale risposta è stata data.
Se fossi un responsabile delle assunzioni e ottenessi quella risposta, sarei meno preoccupato della validità della risposta e più preoccupato che non siano riusciti a capire correttamente la domanda.Ciò indica problemi con attenzione ai dettagli e capacità di seguire le istruzioni.Preferirei una risposta sbagliata che almeno tentasse la domanda (dopotutto, non ci si può aspettare che nessun essere umano sappia tutto), piuttosto che un'informazione "corretta" che è irrilevante.
Esaminando la domanda - * "Perché dovresti usare anche un blocco unico se la distribuzione della chiave è sicura al 100%? Perché non inviare semplicemente il messaggio di testo normale poiché sei sicuro che la distribuzione sia sicura al 100%?" * - èÈ molto chiaro che si presume la sicurezza del canale e vogliono sapere perché dovresti preoccuparti di un OTP.Non stanno chiedendo se sia possibile o meno che un canale sia sicuro al 100%.
Non sono d'accordo, ma ... questo dimostra che quando rispondi a una domanda in un'intervista, sei in balia della posizione dell'intervistatore su una questione.Non è come se questa domanda fosse "risolvi per x" o "quali sono i componenti dello stack del protocollo TCP / IP".Preferirei vedere uno scettico in materia di sicurezza piuttosto che qualcuno con una nuova laurea e libri intelligenti che pensano di poter superare in astuzia il sistema - detto sistema essendo che la sicurezza anche in condizioni ideali è imperfetta.
Quindi la tua domanda dovrebbe essere: "Pensi che sia possibile ottenere il 100% di sicurezza?"se vuoi quella risposta.Fare una domanda non correlata e sperare nella tua risposta crea solo un processo di intervista confuso.
Che, per quanto riguarda l'attenzione ai dettagli, è probabilmente la risposta più dettagliata.Capisco quello che stai dicendo e presumo che una risposta come quella che ho proposto porterebbe a domande di follow-up o una richiesta di una risposta più accademica, il che va bene.Ma in realtà preferirei che questo scambio avvenisse prima.
Count Iblis
2016-06-15 11:28:05 UTC
view on stackexchange narkive permalink

La domanda:

Perché dovresti usare anche un blocco unico se la distribuzione delle chiavi è sicura al 100%? Perché non inviare semplicemente il messaggio di testo normale dato che sei sicuro che la distribuzione sia sicura al 100%?

Questo presume che al momento della distribuzione della chiave ci siano informazioni da inviare che potrebbero non essere sia il caso. Altre risposte fornite qui hanno affrontato questo punto. Un altro problema è che anche in linea di principio la distribuzione delle chiavi può essere sufficiente solo per la distribuzione delle chiavi mentre potrebbe non essere sicura per il trasferimento di informazioni desiderato.

Un esempio è il problema di come Edward Snowden può inviarti informazioni in modo sicuro. Partiamo dal presupposto che tutte le comunicazioni da Snowden siano monitorate, se lo incontri faccia a faccia, sarai monitorato, tutto ciò che ritiri da lui non sarà sicuro. Quindi, non c'è modo che Snowden possa darti un file di testo normale senza che sia compromesso. Al massimo puoi portare qualcosa a Snowden in sicurezza. Per implementare il metodo OTP è tutto ciò che devi fare.

Un protocollo sicuro che utilizza l'OTP potrebbe quindi funzionare come segue. Faccio copie delle immagini che ho sul mio disco rigido e le metto su una chiavetta USB. Chiedo a qualcuno di cui mi fido di dare questa chiavetta USB a Snowden. Dopo che questa persona ha incontrato Snowden, viene individuato, tutti i suoi beni vengono perquisiti, la CIA lo controlla, la sua casa finisce regolarmente per essere svaligiata, uno spyware installato sul suo computer. Quindi, ovviamente, non può ricevere nulla da Snowden in modo sicuro.

Ma Snowden può inviarmi informazioni in modo sicuro applicando il metodo OTP per suddividere i messaggi in due parti di rumore bianco e aggiungendo quel rumore come falso rumore ISO alto a due foto che ha ottenuto da me e caricando queste due immagini su Flickr. Tutto quello che devo fare è scaricare i suoi ultimi due post su Flickr, sottrarre i file di immagine dalle immagini sul mio disco rigido e sommare le due parti di rumore per ottenere il messaggio.

Penso che tu non abbia capito la domanda.L'OP sa cos'è una OTP e come funziona.Seguendo il tuo esempio, la domanda è: se puoi consegnare in modo sicuro alla persona la pen drive contenente l'OTP, allora perché non passare semplicemente il messaggio in primo luogo, dal momento che hai già un canale sicuro con cui dare loro il polliceguidare.
@JonBentley Ho capito correttamente la domanda, l'ho affrontata sul punto già fatto in alcune altre risposte sul trasferimento delle informazioni che avviene in seguito quando non sono disponibili canali sicuri.
@CountIblis Come risponde alla domanda "Perché dovresti usare un OTP se sei sicuro al 100% che la distribuzione delle chiavi sia sicura?" È chiaro che non hai capito la domanda.Questo è rispondere a una domanda del tipo "Come puoi rendere più sicura la distribuzione delle chiavi?"
@Qwerty01 Ho capito la domanda, è solo che nel contesto dell'OTP nel modo in cui lo si userebbe in pratica, questa è una cosa estremamente banale.La distribuzione delle chiavi non è il punto in cui le informazioni vengono trasferite, potrebbe non essere nemmeno possibile trasferire le informazioni in modo sicuro attraverso questo canale.Il Guardian potrebbe inviare un giornalista a Snowden e dargli una chiavetta USB contenente immagini.Ma sulla via del ritorno si possono perquisire tutti i suoi averi.Non è quindi disponibile alcun canale sicuro per le comunicazioni da Snowden al Guardian, tuttavia è possibile utilizzare l'OTP.
Quindi, la chiave OTP può essere inviata in modo sicuro solo in un modo, perché quando vado a Snowden, i servizi di intelligence non sanno che ho intenzione di incontrarlo.Ma dopo averlo incontrato potrei essere stato notato da agenti segreti che controllano il suo appartamento, quindi tutto ciò che gli porto indietro non è sicuro.
Capisco a cosa stai arrivando, ma manca ancora l'intento della domanda.Non sta chiedendo di _come_, sta chiedendo di _perché_ (il che, in questo caso, sarebbe che potresti dover trasferire i file su Snowden _later_ e avere solo una possibilità su un canale sicuro al 100% _now_)
@Qwerty01 Ok., Riscriverò questa risposta in base all'esempio di Snowden.
Duszek Smsaczek
2016-06-11 21:24:00 UTC
view on stackexchange narkive permalink

Se invii un testo davvero sicuro che non può essere intercettato dai computer in nessuna circostanza, dovresti usare OTP e consegnare la chiave faccia a faccia, ma puoi inviare messaggi crittografati tramite l'ufficio postale. Se usato correttamente, chiunque non può rompere i messaggi. Anche in 1'028'526'910 anno.

La domanda non riguarda le OTP o come funzionano.La domanda è: se puoi consegnare l'OTP faccia a faccia, perché non consegnare il messaggio faccia a faccia e saltare la complicazione aggiuntiva dell'utilizzo di un'OTP.Per rispondere alla domanda, è necessario affrontare specificamente i motivi per utilizzare una OTP anziché il messaggio stesso.
@JonBentley Sicuramente, il problema non è come comunicare in modo sicuro con tua moglie a casa ....
@CountIblis Non capisco davvero il tuo commento.Il punto è che, se hai un modo per consegnare in modo sicuro l'OTP, avresti potuto usarlo in quel modo per consegnare il messaggio, e l'OP sta chiedendo perché dovresti preoccuparti di usare un OTP in quel caso.
@JonBentley Chi dice che c'è un messaggio da consegnare da me al destinatario della chiave OTP?Potrebbe anche essere il contrario e quel percorso inverso potrebbe non essere affatto sicuro.Snowden vuole inviarmi un messaggio sicuro ma non è in grado di consegnarmi una chiave OTP.Posso consegnargli una chiave OTP, ma non posso ritirare alcun messaggio da lui perché verrò notato dopo averlo visitato e sarò perquisito.
@CountIblis Sì ... questa è una possibile risposta alla domanda.Qual è il tuo punto?Sembra che tu pensi che io stia facendo la domanda, ma non lo sono.Chiarisco qual è la domanda ** **, poiché questa risposta non comprende la domanda.
Odio gli antipatisti!


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...