Assicurarsi che un file possa essere decifrato solo dopo una data specifica

Il tempo è relativo. La crittografia vive nel mondo etereo delle macchine informatiche astratte: ci sono macchine che possono fare operazioni. Le macchine più grandi possono eseguire le operazioni più velocemente. Non c'è un orologio che puoi applicare; il tempo fisico non ha significato. In altre parole, se un utente malintenzionato desidera ottenere il file in precedenza, deve solo acquistare un computer più veloce.

Ora si può ancora fare uno sforzo. Potresti essere interessato ai rompicapo a tempo> . L'idea è di essere in grado di creare un'istanza del problema facile da costruire ma costosa da aprire, in cui il costo è configurabile. La soluzione trovata da Rivest, Shamir e Wagner (per quanto ne so, questo è l'unico rompicapo pratico a chiusura temporale conosciuto finora) funziona in questo modo:

• Genera un modulo RSA casuale n = pq dove p e q sono grandi numeri primi (e anche < em> p = 3 mod 4 e q = 3 mod 4).
• Genera un x modulo n casuale
• Per alcuni interi w , definisci e = 2 ^w e calcola y = x ^e mod n .
• Hash y con qualche funzione di hash, producendo una stringa K che usi come chiave per crittografare il file che vuoi bloccare a tempo.
• Pubblica x , n , w e il file crittografato. Elimina p , q , y e K .

Il punto difficile è che il calcolo di y , in generale, ha un costo proporzionale a w : è una successione di w squadrature modulari. Se w è compreso nell'intervallo di miliardi o più, questo sarà costoso. Tuttavia, quando sono noti i fattori p e q , è possibile calcolare e modulo p-1 e < em> q-1 , che sarà molto più breve, e il calcolo di y può essere eseguito in pochi millisecondi.

Naturalmente questo non garantisce un rilascio ad una data specifica ; piuttosto, garantisce un minimo sforzo per sbloccare il puzzle. La conversione tra sforzo e data dipende da quanto gli aggressori provano ...

L'enigma del blocco del tempo espresso sopra ha alcune caratteristiche interessanti, in particolare per quanto riguarda il parallelismo. Se provi a spezzare un tale puzzle e hai due computer, non sarai più veloce di quello che potresti fare con un singolo computer.

In un contesto in qualche modo simile, questo puzzle time-lock viene utilizzato nella funzione di hashing della password di Makwa , candidata al corso PHC . Nell'hash delle password, vuoi uno sforzo di apertura configurabile (anche se in un intervallo di tempo molto più breve, in genere meno di un secondo).

Se non vuoi coinvolgere una terza parte, tu (la parte che crittografa il file) potresti semplicemente rilasciare la chiave per decodificare il file nella data di destinazione.

Ho visto questo fatto per le versioni dei videogiochi. I clienti sono autorizzati a scaricare una copia crittografata del gioco in anticipo. Poi, quando arriva il momento del rilascio, la società di giochi rilascia semplicemente la chiave. In questo modo, le persone possono iniziare a giocare immediatamente quando il gioco viene rilasciato, senza dover attendere il download.

Posiziona con cautela un'astronave che trasmette la chiave di decrittografia in orbita attorno a un buco nero. La forza di gravità ritarderà il messaggio fino al momento appropriato.

Oppure potresti semplicemente fare come le persone normali e mettere la navicella spaziale che trasmette la chiave per un numero appropriato di anni luce lontano dal pubblico previsto.

Utilizza la condivisione segreta per dividere una chiave di crittografia privata in N parti, parametrizzata per consentire la ricostruzione della chiave con K o più parti, dove K <= N . Il meglio è fatto usando CRM, come descritto nella pagina seguente:

link

Quindi invia ciascuna parte a servizi indipendenti che accettano di pubblicare in una determinata data in futuro.

Fino a K-1 dei servizi possono "correggere" pubblicando in anticipo senza influire sullo schema.

Fino a N-K dei servizi può non riuscire a pubblicare del tutto, anche senza influire sullo schema.

Credo che per progettare correttamente il tuo sistema, devi definire che cosa "tempo" significa nel tuo contesto e perché hai scelto un momento specifico . Supponendo che il tuo messaggio sia decrittografato il 29 agosto 1997 alle 02:14, qual è la differenza tra l'attimo prima e il momento dopo la scadenza? Perché specificamente questa data? Potresti essere in grado di utilizzare questo evento come componente del tuo schema.

Ad esempio, se ti aspetti che Skynet diventi consapevole della data in questione e desideri che il messaggio venga decrittografato solo dopo che Skynet diventa consapevole, la chiave di decrittografia potrebbe essere "skynet_became_self_aware". È improbabile che sia forzato bruto, soprattutto perché contiene una parola non dizionario. Tuttavia, diventa molto probabile che sarà provato dopo che si è verificato l'evento, specialmente se ci sono sistemi automatici che cercano di forzare la forza che aggiungerà la parola "skynet" ai loro dizionari al momento giusto.

Questo schema non è perfetto, dato che esiste ancora la possibilità di forzare la chiave bruta e persino dopo la data potrebbe non essere in uso risorse idonee che tentano di craccarla. Tuttavia, questo schema ha il vantaggio aggiuntivo che se l'evento di cui scegli si verifica prima o dopo il previsto , il messaggio non verrà decrittografato troppo tardi / troppo presto.

Se l'unica parte fidata è te stesso e non puoi garantire la disponibilità quando il contenuto del messaggio deve essere reso pubblico, allora ciò che puoi fare è costruire un dispositivo (fisico o virtuale) che automaticamente farà pubblica chiave al momento richiesto, quindi nascondi il dispositivo.

Un modo semplice sarebbe quello di acquistare un server virtuale da Amazon o una qualsiasi delle centinaia di altre società - forse diversi server in paesi stranieri - con un'identità diversa, non riconducibile all'identità della persona che ha pubblicato il messaggio. Idealmente, dovresti acquistare questo server diversi anni prima che rilasci il messaggio. Questi server si limitano a sedersi e ad attendere, senza fare nulla (magari ospitando un'e-mail dall'aspetto innocente o un server FTP), fino alla data specificata e quindi pubblicare la chiave di decrittografia attraverso più canali pubblici in modo da soddisfare la propria definizione di rendere le informazioni "pubbliche". "

Nessuno potrebbe nemmeno sapere che questi server esistono, quindi nessuno li sta cercando; e il loro scopo può essere sufficientemente offuscato dal fatto che nessuno che vi si imbatta per caso capisce a cosa servono. Ci sono molti milioni di server connessi a Internet: i tuoi sono semplicemente persi nel rumore.

Questo sarebbe sufficiente a meno che il messaggio non sia considerato abbastanza importante da far sì che ci sia uno sforzo a livello mondiale per individuare la chiave, su una scala che ispirerebbe i governi a eseguire sofisticate analisi del traffico ogni server virtuale e fisico che è andato online negli ultimi dieci anni, e quindi esamina manualmente tutti i file e il codice su ognuno dei (milioni di) sospetti, alla ricerca di informazioni nascoste.

In tal caso, è possibile nascondere ulteriormente il dispositivo. Se vuoi davvero fare questo stile di James Bond, metti il messaggio su un nastro collegato a un trasmettitore radio ad onde corte con una riserva di batteria in Antartide (dove potrebbe essere sepolto nella neve), o in una remota giungla del Brasile (dove potrebbe essere danneggiato dagli animali), o sul fondo dell'oceano, con un airbag gonfiato chimicamente per farlo galleggiare in superficie a la data e l'ora specificate (dove potrebbe corrodersi - forse il Lago Superiore è più sicuro?), o sepolto superficialmente sottoterra, con un'antenna simile al periscopio.

Naturalmente, la difficoltà e il costo di una di queste opzioni dipende da quanto tempo si desidera mantenere il dispositivo nascosto. Se è un secolo, è probabile che i protocolli Internet siano cambiati e qualsiasi cosa più complessa della radio analogica a onde corte potrebbe essere impossibile. (E potrebbe anche darsi che nessuno stia ascoltando più neanche l'onda corta). Se sono solo pochi mesi, il tuo dispositivo potrebbe semplicemente essere uno smartphone prepagato collegato a un pacco batteria esterno e lasciato cadere in un posto moderatamente oscuro. Esistono già molti sensori remoti basati su celle sul mercato, che effettuano automaticamente una telefonata o una connessione Web quando vengono soddisfatti alcuni criteri, quindi questo sarebbe quasi inosservabile: sembrerebbe alla società di telefonia cellulare come un altro questi dispositivi sempre più diffusi.

Non sono completamente sicuro se questo documento sulla crittografia a blocco orario è stato ispirato da questa discussione ma sarebbe la soluzione più formale alla domanda "Come costruire la crittografia a blocco del tempo?", che è una riformulazione di "Come proteggere i dati in modo che possano essere decifrati solo dopo una data specifica? "

Ma ora esaminiamo i dettagli su come funziona.

Si costruisce fondamentalmente un clock di riferimento usando la computazione disponibile pubblicamente (come i calcoli di Bitcoin). Quindi, per quanto ho capito, questo dipende dal blockcoin di Bitcoin per raggiungere una certa dimensione (cresce ogni 10 minuti, relativamente precisamente). In questo modo, "crittografia testimone" consentirà a tutti di decrittografare i dati (dove la blockchain contiene qualche testimone, che diventa disponibile solo quando la catena raggiunge una certa dimensione). Poiché è impossibile rompere gli schemi di crittografia dei testimoni e essere più veloci dell'intera rete bitcoin (eseguendo più di 300 ID / s ora) è improbabile che un utente malintenzionato possa ottenere i dati decrittografati ( che può essere una chiave) prima che scada il time-lock.

Si può anche notare che questo schema non soffre costi elevati (viaggi nello spazio), non ha bisogno di terze parti fidate (non è necessario fidarsi della rete Bitcoin) e la parte crittografica non deve essere disponibile al momento della decodifica e le parti con risorse computazionali elevate hanno poche possibilità di conoscere il segreto precedente .

Si potrebbe anche voler leggere questo documento , seguendo un approccio simile e riducendo la sicurezza al problema del sottogruppo , che si crede sia difficile.

Criptare il file con una chiave molto lunga, dividerlo in parti e consegnare ciascuna parte a una persona fidata insieme alle istruzioni di non cedere la parte suddetta fino alla data indicata. È possibile aggiungere ridondanza assegnando ciascuna parte a più persone, nel caso in cui una di esse dovesse essere investita da un autobus.

Naturalmente, una rete di computer potrebbe farlo proprio come gli umani. In effetti, l'algoritmo di retargeting della difficoltà basato sul tempo di Bitcoin, sebbene abbia uno scopo diverso, si basa su principi simili. Non so che qualsiasi programma esiste effettivamente per questo scopo, tuttavia.

Un approccio ipotetico è fornito nel documento citato nella domanda (che è molto interessante a proposito di BTW, nonostante la grammatica goffa occasionale) che consiste nell'utilizzare un software contenente un carico utile crittografato, che innesca un valore esterno come una notizia, e fare in modo che le persone in tutto il mondo lo eseguano fino al momento in cui viene eseguito il payload. Questo non soddisfa il requisito "data / ora pubblicamente noto", ma la premessa è un buon punto di partenza. Un servizio distribuito, molto simile a TOR / Bitcoin, potrebbe essere eseguito in modo P2P da molte persone in tutto il mondo al solo scopo di mantenere i rilasci delle chiavi dipendenti dal tempo. Questo è noto come bizantina Fault Tolerance (aka il problema dei generali bizantini, vedi link per una spiegazione completa) ma in questo caso il "difetto" da difendere sarebbe la prematura liberazione delle informazioni quindi non è un'applicazione diretta, ma una tangenziale che richiederebbe una nuova serie di tecniche.

È possibile utilizzare un'accurata codifica per creare uno schema in cui ogni utente contiene una piccola parte della chiave, molti utenti hanno copie ridondanti di singoli pezzi e vi è un strong mezzo per prevenire il "raccolto" prematuro, tra cui l'evasione del malware e supporto della piattaforma (in cui le chiavi vengono intenzionalmente suddivise equamente tra gli utenti che eseguono il software su Windows, IOS, Android, OS X, Linux, ecc.)

Dovrebbe quasi funzionare come un inverso della blockchain bitcoin, dove invece di ogni utente che ha una copia verificabile di ciò che è accaduto in passato, ogni utente ha una fetta unica di ciò che accadrà in futuro, e solo come il futuro si rivolge al presente sono ogni blocco rilasciato al mondo per il consumo. In questo caso si poteva usare una tecnica di onion-ing a la TOR, in cui ogni pezzo della tua chiave segreta veniva inviato a un gruppo di utenti, lo trasfiguravano e lo inviavano conservando solo una chiave di traduzione, e continuava ad andare per N giri a monte. Ogni livello può avere il proprio timer casuale per passare successivamente il materiale a valle, avvicinandosi all'origine dove l'ultimo timer farà il conto alla rovescia e innescando il rilascio delle parti chiave per riunirsi su una serie di colleghi concordati ed essere inviato via email, oppure qualcosa.

L'unico pezzo mancante sarebbe come evitare la collusione di massa, come un insieme di taglie per invogliare abbastanza utenti a rinunciare al loro materiale chiave in cambio di una scissione del piatto, dal momento che non si può presumere che molti di essi considera le loro informazioni riservate per avere un > 0 valore se lasciato intatto. Sarebbe auspicabile un modo per offuscare completamente il materiale, in modo che ogni utente avesse una grossa quantità di dati senza sapere quali fette di eventi erano a loro carico. Questo è un problema interessante, infatti.

In definitiva, la seconda legge della termodinamica ti ostacola. Guarda il tuo testo semplice come un sistema chiuso; può solo aumentare sempre di entropia.

La crittografia delle informazioni aumenta la sua entropia, ma la chiave lo compensa. L'entropia totale della chiave + testo cifrato è la stessa dell'entropia del testo normale.

Quando distruggi la chiave, l'entropia generale del sistema aumenta. Il che significa che non puoi mai tornare indietro (eccetto con un massiccio apporto di energia attraverso la potenza di calcolo a forza bruta).

Ciò significa che è necessario conservare la chiave; non puoi distruggerlo temporaneamente.

Ovviamente puoi nascondere la chiave, crittografarla di nuovo, tenerla con una terza parte attendibile, ecc. Ma la chiave deve sempre essere da qualche parte .

Encrypt con un pad XOR monouso e disporre di una sorta di automazione per inviare il flusso di crittografia all'ora stabilita. Una volta i pad XOR sono completamente resistenti agli attacchi di pattern perché non ci sono pattern.

Affinché ciò avvenga è necessario

• produci tu stesso la chiave e non condividerla con chiunque
• costruire un'automazione di consegna temporizzata a prova di manomissione
• nasconde il vero scopo del sistema di consegna temporizzato assicurando che faccia un buon lavoro eseguendo uno scopo infrastrutturale immensamente noioso ma essenziale, in modo che nessuno cerchi di indagare, sconnettere, modificare o ri-finalizzarlo
• distruggi tutte copie del pad XOR al di fuori del sistema di consegna temporizzato a prova di manomissione

Si noti che per essere veramente a prova di manomissione deve rispondere alla manomissione effettuando un'accurata scansione del pad XOR. Fortunatamente, poiché i pad XOR contengono dati casuali, non c'è modo di dire se si è autodistrutto o meno.

Potresti ulteriormente nascondere il pad XOR steganograficamente per evitare che l'inquisitore si chieda perché qualcuno dovrebbe nascondere molti dati apparentemente casuali.

Mi rendo conto che ci sono elementi di sicurezza oscuri in questo approccio. Questo è inevitabile; se conoscessi un tale sistema e volessi attaccarlo, inizierei privandolo del potere e dissaldando tutto ciò che sembrava immagazzinamento in modo da poter esaminare i contenuti senza consentirgli di rispondere alle manomissioni. Anche allora potresti incorporare un UPS.

L'attacco informato dipende dalla conoscenza a priori del sistema, a partire dalla sua esistenza. Se solo il mittente sa anche della sua esistenza, questo può essere robusto. Una strategia comune è quella di evitare che qualsiasi parte costruisca un frammento abbastanza grande da avere uno scopo coerente.

Potrebbe essere possibile costruire un sistema basato su blockchain che dia ad ogni blocco in futuro un payload aggiuntivo che il minatore di quel blocco deve risolvere.

Ogni blocco può creare una chiave privata per una chiave pubblica conosciuta in anticipo. Crittografa il tuo messaggio con una chiave simmetrica e quindi cripta quella chiave con le note chiavi pubbliche dei prossimi 10000 blocchi che verranno estratti.

Se la rete raccoglie più potenza di calcolo, può aggiungere ulteriori problemi numerici ai blocchi estratti per mantenere il tempo di generazione dei blocchi di in media 10 minuti.

Se la rete perde potenza di elaborazione, sarà comunque necessario più tempo per crittografare il file.

Utilizzando fonti non attendibili, è possibile inviare la chiave di decrittazione tramite posta ordinaria alla parte fidata. Questo non si fida completamente del gruppo poiché non è possibile postare in anticipo, ma non è possibile pubblicare nulla, quindi per ridurre al minimo il rischio, è possibile utilizzare più fonti attendibili.

Per aumentare il ritardo temporale, è possibile utilizzare un servizio online per chiedere di inviare la cartolina dall'esterno del paese (ma ciò renderebbe vulnerabile agli attacchi man in the middle), ad esempio link per gli altoparlanti olandesi, ma sono certo che servizi simili esistono altrove.

Funziona per il trigger al momento di un evento che tu fai.

Crea un'automazione (vedi la risposta di Peter Wone) che controlla se hai una pagina di wikipedia nel tuo nome. e si attiva se lo fa.

Questo è ovviamente molto sensibile al trigger & funziona solo se sei sconosciuto al momento della costruzione.

Potresti risolvere entrambi i problemi includendo la condizione che alcune informazioni sull'evento siano contenute nella voce di Wikipedia.

Sono sicuro che usando Google ci sono un paio di altri trigger interessanti da trovare

Come altri hanno detto, non è possibile fornire la decifratura entro una data specifica, ma con uno sforzo specifico. Per quanto riguarda un algoritmo a scopo singolo, lo sforzo è strongmente correlato all'interesse delle parti che cercano di sbloccarlo prima e quindi abbastanza sconosciuto.

Quindi la soluzione migliore potrebbe implicare il collegamento del puzzle a un interesse molto più ampio e inerte. La cosa più fattibile che mi è venuta in mente in questi giorni è la catena di blocchi Bitcoin. Poiché i bitcoin sono realtà da alcuni anni e la loro generazione coinvolge oggi grandi quantità di hardware, abbiamo buone possibilità di prevedere il loro tasso di generazione a lungo termine (forse da settimane a mesi).

Mi chiedo se questo potrebbe essere fatto. Quello che sarebbe necessario è un collegamento tra i bitcoin generati e la chiave necessaria. Non possiamo fare affidamento su un singolo bitcoin per essere generato, ma dobbiamo usare qualcosa come un piccolo n di una grande quantità precedentemente scelta di m possibili bitcoin fornirà la decrittazione. Questo è possibile con la "condivisione segreta" ( link ). Dato che gli hash bitcoin dipendono dalle transazioni effettuate in precedenza, sarebbe abbastanza complicato costruire% puzzle di% di enigma che risolverebbe l'hash bitcoin un giorno.

L'unico modo per farlo è quello di garantire che a) tu controlli il codice che esegue la decrittografia e b) che tu stia ottenendo la data da una fonte immutabile. Ad esempio, se si include come parte della decrittografia una chiamata a un servizio Web di orologio atomico (idealmente uno sicuro che non potrebbe essere falsificato). A quel punto, devi solo controllare la data e se è inferiore alla tua data desiderata, non ti preoccupare di decifrare.