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 esiste un orologio che puoi applicare; il tempo fisico non ha significato. In altre parole, se un utente malintenzionato vuole ottenere il tuo file prima, deve solo acquistare un computer più veloce.

Ora si può ancora fare uno sforzo. Potresti essere interessato a puzzle a tempo. L'idea è quella di poter creare un'istanza problematica facile da costruire ma costosa da aprire, il cui costo è configurabile. La soluzione trovata da Rivest, Shamir e Wagner (che io sappia, questo è l'unico rompicapo pratico del blocco del tempo finora noto) funziona in questo modo:

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

il punto è che calcolare y , in generale, ha un costo proporzionale a w : è una successione di w quadrature modulari. Se w è dell'ordine di miliardi o più, allora sarà costoso. Tuttavia, quando i fattori p e q sono noti, è possibile calcolare e modulo p-1 e q-1 , che sarà molto più breve, e il calcolo di y può essere eseguito in pochi millisecondi.

Ovviamente questo non garantisce un rilascio in una data specifica; piuttosto, garantisce uno sforzo minimo per sbloccare il puzzle. La conversione tra sforzo e data dipende da quanto si sforzano gli attaccanti ...

Il rompicapo del blocco del tempo espresso sopra ha alcune caratteristiche interessanti, in particolare l'essere impermeabile al parallelismo. Se provi a rompere uno di questi 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 rompicapo del blocco del tempo viene utilizzato nella funzione di hashing della password Makwa, candidata al PHC in corso. Nell'hashing delle password, desideri uno sforzo di apertura configurabile (anche se in un lasso di tempo molto più breve, di solito meno di un secondo).

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

L'ho visto fare per il video versioni del gioco. I clienti possono scaricare in anticipo una copia crittografata del gioco. Quindi, 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 cura un'astronave che trasmette la chiave di decrittazione in orbita attorno a un buco nero. L'attrazione della gravità ritarderà il messaggio fino al momento opportuno.

Oppure potresti semplicemente fare come le persone normali e posizionare l'astronave principale che trasmette un numero appropriato di anni luce di distanza dal pubblico previsto.

Usa 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 . È meglio farlo utilizzando CRM, come descritto nella pagina seguente:

http://en.wikipedia.org/wiki/Secret_sharing

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

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

Fino a NK dei servizi può non essere pubblicato del tutto, anche senza influire sullo schema.

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

Ad esempio, se prevedi che Skynet diventerà consapevole di sé alla data in questione e desideri che il messaggio venga decrittografato solo dopo che Skynet diventa consapevole di sé, la chiave di decrittazione potrebbe essere "skynet_became_self_aware". È improbabile che sia forzato, soprattutto perché contiene una parola non del dizionario. Tuttavia, diventa molto probabile che verrà provato dopo che si è verificato l'evento, specialmente se ci sono sistemi automatici che tentano di forzarlo, aggiungendo la parola "skynet" ai loro dizionari al momento opportuno.

Questo schema non è perfetto, poiché esiste ancora la possibilità di forzare bruta la chiave e anche dopo la data potrebbero non essere disponibili risorse adeguate per tentare di decifrarlo. Tuttavia, questo schema ha il vantaggio aggiuntivo che se l'evento di cui hai scelto la data accade prima o dopo il previsto , il messaggio non verrà decrittografato troppo tardi / troppo presto.

Se l'unica parte fidata sei te stesso e non puoi garantire di essere disponibile quando i contenuti del messaggio devono essere resi pubblici, quello che puoi fare invece è costruire un dispositivo (fisico o virtuale) che renderà automaticamente chiave pubblica al momento richiesto, quindi nascondere il dispositivo.

Un modo semplice sarebbe acquistare un server virtuale da Amazon o da una qualsiasi delle centinaia di altre società, forse diversi server in paesi stranieri, con un diverso identità, non riconducibile all'identità della persona che ha pubblicato il messaggio. Idealmente, dovresti acquistare questo server diversi anni prima di rilasciare il messaggio. Questi server rimangono semplicemente seduti e aspettano, senza fare nulla (magari ospitando un'e-mail dall'aspetto innocente o un server FTP), fino alla data specificata, quindi pubblicano la chiave di decrittazione attraverso più canali pubblici in modo da soddisfare la tua definizione di rendere "pubbliche le informazioni". "

Nessuno saprebbe nemmeno che questi server esistono, quindi nessuno li sta cercando; e il loro scopo può essere sufficientemente offuscato che nessuno che li incontra per caso si rende conto 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 dal pubblico abbastanza importante da richiedere uno sforzo a livello mondiale per individuare la chiave, su una scala che ispirerebbe i governi a eseguire sofisticate analisi del traffico su ogni server virtuale e fisico che è andato online negli ultimi dieci anni, e quindi esaminare manualmente tutti i file e il codice su ciascuno dei (milioni di) quelli sospetti, cercando per informazioni nascoste.

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

Ovviamente, la difficoltà e il costo di una qualsiasi di queste opzioni dipendono da quanto tempo si desidera mantenere nascosto il dispositivo. Se è un secolo, è probabile che i protocolli Internet siano cambiati e qualcosa di più complesso della radio analogica a onde corte potrebbe essere irrealizzabile. (E può anche darsi che nessuno ascolti più le onde corte.) Se sono solo pochi mesi, il tuo dispositivo potrebbe essere semplicemente uno smartphone prepagato collegato a un pacco batteria esterno e lasciato cadere in un luogo moderatamente oscuro. Ci sono già molti sensori remoti basati su cellulare sul mercato, che effettuano automaticamente una telefonata o una connessione web quando vengono soddisfatti alcuni criteri, quindi questo sarebbe quasi impercettibile - sembrerebbe all'azienda di telefonia cellulare come solo un'altra di questi dispositivi sempre più diffusi.

Non sono del tutto sicuro che questo documento sulla crittografia time-lock sia stato ispirato da questa discussione, ma sarebbe la soluzione più formale alla domanda "Come per costruire la crittografia time-lock? ", che è una riformulazione di" Come proteggere i dati in modo che possano essere decifrati solo dopo una data specifica? "

Ma ora entriamo nei dettagli su come funziona .

Si costruisce fondamentalmente un orologio di riferimento utilizzando calcoli disponibili pubblicamente (come i calcoli Bitcoin). Quindi, per quanto ho capito questo dipende dalla blockchain di Bitcoin per raggiungere una certa dimensione (cresce ogni 10 minuti, relativa precisamente). Quando ciò accade, la "crittografia del testimone" consentirà a tutti di decrittografare i dati (dove la blockchain contiene qualche testimone, che diventa disponibile solo quando la catena assume una certa dimensione). Poiché è impossibile violare gli schemi di crittografia del testimone ed essere più veloce dell'intera rete bitcoin (eseguendo più di 300PHash / s al momento) è improbabile che un utente malintenzionato sia in grado di ottenere i dati decrittografati ( che può essere una chiave) prima della scadenza del time-lock.

Si può anche notare che questo schema non soffre di costi elevati (viaggi nello spazio), non necessita di terzi affidabili parti (non è necessario fidarsi della rete Bitcoin) e la parte che esegue la crittografia non deve essere disponibile al momento della decrittografia e le parti con risorse di calcolo elevate hanno poche possibilità di conoscere il segreto prima .

Si potrebbe anche voler leggere questo documento, seguendo un approccio simile e riducendo la sicurezza al problema del sottoinsieme, che si ritiene essere duro.

Criptare il file con una chiave molto lunga, dividerlo in parti e consegnare ciascuna parte a una persona di fiducia insieme alle istruzioni di non cedere detta parte fino alla data stabilita. Puoi aggiungere un po 'di ridondanza dando ogni parte a più persone, nel caso in cui una di loro dovesse essere investita da un autobus.

Ovviamente, una rete di computer potrebbe farlo proprio come fanno gli esseri umani. In effetti, l'algoritmo di retargeting della difficoltà basato sul tempo di Bitcoin, sebbene abbia uno scopo diverso, si basa su principi simili. Tuttavia, non so se esista effettivamente alcun programma per questo scopo.

Un approccio ipotetico è fornito nel documento citato nella domanda (che è molto interessante a proposito, nonostante la grammatica occasionale goffa) che consiste nell'utilizzare un software contenente un payload crittografato, innescando un valore esterno come una notizia, e chiedere a persone in tutto il mondo di eseguirlo fino al momento in cui viene eseguito il carico utile. Ciò non soddisfa il requisito di "data / ora di pubblico dominio", 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 Byzantine Fault Tolerance (noto anche come Byzantine Generals Problem, vedere http://en.wikipedia.org/wiki/Byzantine_fault_tolerance per una spiegazione completa) ma in questo caso la "colpa" deve essere evitare il rilascio prematuro delle informazioni, quindi non è un'applicazione diretta, ma tangenziale che richiederebbe un nuovo insieme di tecniche.

Si potrebbe utilizzare un'attenta codifica per creare uno schema in cui ogni utente detiene un piccolo pezzo della chiave, molti utenti hanno copie ridondanti di singole parti e c'è un mezzo efficace per prevenire la "raccolta" prematura inclusa l'evasione del malware e il supporto multipiattaforma (in cui le chiavi sono intenzionalmente divise equamente tra gli utenti che eseguono il software 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 quando il futuro si volge al presente, ogni blocco viene rilasciato al mondo per il consumo. In questo caso si potrebbe usare una tecnica di onion-ing a la TOR, in base alla quale ogni pezzo della tua chiave segreta veniva inviato a un insieme di utenti, lo trasfiguravano e lo inviavano conservando solo una chiave di traduzione, e questo continuava ad andare per N turni a monte. Ogni livello potrebbe avere il proprio timer randomizzato per passare successivamente il materiale a valle, avvicinandosi all'origine dove l'ultimo timer farebbe il conto alla rovescia e innescherebbe il rilascio delle parti chiave per riunirsi su una serie di peer concordati e ricevere email, oppure qualcosa.

L'unico tassello mancante sarebbe come evitare la collusione di massa, come un set di taglie per invogliare abbastanza utenti a rinunciare al loro materiale chiave in cambio di una divisione del piatto, dal momento che non può si presume che molti di loro considerino le loro informazioni depositate in garanzia per avere un valore> 0 se non vengono toccate. Sarebbe desiderabile un modo per offuscare completamente il materiale, in modo che ogni utente avesse una grande quantità di dati senza sapere quali sezioni di eventi erano a loro cura. Questo è davvero un problema interessante.

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

Quindi la soluzione migliore potrebbe comportare il collegamento del puzzle a un interesse molto più grande e inerte . Il più fattibile che mi è venuto 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 su un ragionevole lungo termine (forse settimane o mesi).

potrebbe essere fatto. Ciò che sarebbe necessario è un collegamento tra i bitcoin generati e la chiave necessaria. Non possiamo fare affidamento sulla generazione di un singolo bitcoin, ma dobbiamo usare qualcosa come un piccolo n di una grande quantità precedentemente scelta di m possibili bitcoin che forniranno la decrittazione. Ciò è possibile con la "condivisione segreta" ( https://en.wikipedia.org/wiki/Secret_sharing). Dato che gli hash di bitcoin dipendono dalle transazioni effettuate in precedenza, sarebbe piuttosto complicato costruire puzzle m che un giorno potrebbero essere risolti dall'hash bitcoin.

Alla fine, la seconda legge della termodinamica ti ostacola. Considera il tuo testo in chiaro come un sistema chiuso; può solo aumentare l'entropia.

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

Quando si distrugge la chiave, l'entropia complessiva del sistema aumenta. Il che significa che non puoi mai tornare indietro (tranne che con un massiccio input di energia attraverso la potenza di calcolo della forza bruta).

Ciò significa che devi mantenere la chiave; non puoi distruggerla temporaneamente.

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

Crittografa con un pad XOR una tantum e disponi di una sorta di automazione per inviare il flusso di cifratura all'ora stabilita. I pad XOR una volta sono completamente resistenti agli attacchi dei pattern perché non ci sono pattern.

Affinché questo abbia successo, devi

• produrre la chiave da solo e non condividerla con nessuno
• costruire manomissioni prova l'automazione della consegna a tempo
• nasconde il vero scopo del sistema di consegna a tempo assicurandosi che svolga un buon lavoro di esecuzione di uno scopo infrastrutturale estremamente noioso ma essenziale, in modo che nessuno cerchi di indagare, scollegare, modificare o riutilizzarlo
• distruggere tutte le copie del pad XOR al di fuori del sistema di consegna temporizzata antimanomissione

Nota che per essere veramente manomissione prova che deve rispondere alla manomissione rimescolando molto accuratamente il pad XOR. Fortunatamente, poiché i pad XOR contengono dati casuali, non c'è modo di dire se si sono autodistrutti o meno.

Puoi nascondere ulteriormente il pad XOR steganograficamente per impedire al curioso di chiedersi perché qualcuno dovrebbe nascondere molti dati apparentemente casuali.

Mi rendo conto che ci sono elementi di sicurezza per oscurità in questo approccio. È inevitabile; se conoscessi un sistema del genere e volessi attaccarlo, inizierei privandolo di energia e dissaldando tutto ciò che sembrava un archivio in modo da poter esaminare il contenuto senza permettergli di rispondere a manomissioni. Anche così potresti incorporare un UPS.

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

Utilizzando fonti non completamente attendibili, è possibile inviare la chiave di decrittazione tramite posta ordinaria alla parte attendibile. Questo non si fida completamente della parte poiché non possono pubblicare in anticipo, ma non potrebbero pubblicare affatto, quindi per ridurre al minimo il rischio, è possibile utilizzare più fonti attendibili.

Per aumentare il ritardo, potresti usare un servizio online per chiedere loro di inviare la cartolina dall'estero (ma ciò la renderebbe vulnerabile agli attacchi di man in the middle), ad esempio http://mijnkaart.bpost.be/fotokaarten-maken per gli altoparlanti olandesi, ma sono sicuro che servizi simili esistono altrove.

Funziona per attivarsi al momento di un evento che causi.

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

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

Puoi risolvere entrambi i problemi includendo la condizione che le informazioni sull'evento sono contenute nella voce di Wikipedia.

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

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

Ogni blocco potrebbe creare una chiave privata per una chiave pubblica nota in anticipo. Cifrate il vostro messaggio con una chiave simmetrica e quindi crittografate quella chiave con le chiavi pubbliche note dei successivi 10000 blocchi che verranno estratti .

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

Se la rete perde potenza di elaborazione tuttavia, occorrerà più tempo per la crittografia del file.

L'unico modo per farlo è assicurarti di a) controllare il codice che esegue la decrittazione eb) di ottenere la data da una fonte immutabile. Ad esempio, se includi come parte della tua decrittografia una chiamata a un servizio Web dell'orologio atomico (idealmente uno sicuro che non può essere falsificato). A quel punto, controlli la data e se è inferiore alla data desiderata, non ti preoccupi di decrittografarla.