Domanda:
Assicurati che un file possa essere decrittografato solo dopo una data specifica
Martin Vegter
2015-05-12 23:05:41 UTC
view on stackexchange narkive permalink

Esistono schemi / protocolli crittografici che mi permettano di crittografare un file, renderlo pubblicamente disponibile, ma garantire che possa essere decrittografato solo dopo una data specifica?

Presumo che sarebbe quasi impossibile senza un'autorità di fiducia (notaio). O c'è un modo?

Sono stato ispirato dall'idea di "trigger sicuri", che è uno schema per decrittografare i dati dopo che si è verificato un evento specifico. Ma questo "evento scatenante" è noto solo all'autore.

Al contrario, sono interessato a uno schema crittografico che consenta la decrittografia dei dati in (o dopo) una data specifica che è pubblicamente nota.

Possibile duplicato: https://crypto.stackexchange.com/questions/606/time-capsule-cryptography
In superficie, sembra che la risposta alla tua domanda sia "puzzle di blocco del tempo" che richiedono che qualcuno esegua X quantità di lavoro per ottenere la chiave. Questo potrebbe funzionare per te se qualcuno è disposto a dedicare un server alla risoluzione del puzzle e quindi rilascia la chiave pubblicamente, ma è def. non è una buona soluzione lato client.
Per inciso, Cicada3301 ha precedentemente lavorato a un progetto di deposito di informazioni.
Devi pensare un po 'alla tua domanda per vedere se ha senso. Chi imposta la data e l'ora in primo luogo? Se il Congresso decide che l'ora legale sta finendo improvvisamente in questo momento e il tuo file è appena diventato decodificabile 10 secondi fa, ti aspetti davvero che venga nuovamente sigillato? Se attraversi il confine di un paese, la tua pratica dovrebbe reagire in qualche modo? Non è abbastanza ovvio che poter decriptare il file debba necessariamente richiedere la collaborazione di chi sta decretando la data / ora corrente?
Mi chiedo se c'è qualcuno che sembra degno di fiducia che abbia rilasciato un carico di chiavi pubbliche in anticipo e abbia dato date prestabilite in cui rilasceranno ogni chiave privata corrispondente. Potrebbe essere un servizio utile.
@Mehrdad Tempo Unix. Finché non ci muoviamo a velocità relativistiche, il tempo di unix non è ambiguo :)
Ti è permesso essere "nel giro?" È banale farlo se pubblichi semplicemente la chiave di decrittazione nella data in cui sei disposto a consentire la decrittografia. Diventi effettivamente la parte fidata. Altrimenti, l'informazione è teoricamente impossibile (significa che ora stai parlando di soluzioni hardware, piuttosto che di soluzioni crittografiche teoriche).
Che ne dici di collegarlo in qualche modo a server NTP pubblici? L'intera argomentazione che il tempo è effimero è difficile da sostenere al di là del mondo teorico poiché lavoriamo tutti su orari. Quando il mio capo dice: "Entra alle 8 del mattino" non gli chiedo "In quale fuso orario". Quindi, per quanto riguarda la domanda, c'è un modo per impostare la decrittografia, ad esempio, su un po 'di ora / data GMT e poi eseguirlo solo se il computer può accedere a un server NTP pubblico?
@Navin In che modo "tempo Unix" non è ambiguo in questo caso? Posso impostare la "data / ora corrente" del mio server come preferisco. In che modo il tempo di Unix potrebbe aiutare? Potrei persino accedere ai time server se controllo la mia rete locale.
@user2338816 Certo, ma se si modifica l'ora del server, l'ora sarebbe sbagliata. Il tempo è definito dal progresso di qualsiasi processo fisico. Non sto dicendo che la domanda sopra abbia una soluzione. È solo che il tempo non ha nulla a che fare con l'ora legale o con ciò che definiscono le leggi.
@Navin Il tempo universale che stai cercando è probabilmente UT1 o TT. UT1 è il tempo solare medio a 0 ° di longitudine, quindi è una misura puramente fisica basata sull'anno terrestre. TT (Terrestrial Time) si basa sul conteggio dei secondi standard in un quadro di riferimento noto, che funziona anche. Il TCG è il sistema fondamentale, che utilizza il centro della Terra, meno la gravità terrestre. TT aggiunge una correzione della gravità al TCG per abbinare un orologio atomico sulla Terra. (L'onnipresente UTC è un sistema ibrido: ogni secondo è la lunghezza di un secondo TT, ma alcuni giorni hanno 86401 secondi in modo che UTC rimanga a meno di un secondo da UT1.)
Sedici risposte:
Tom Leek
2015-05-12 23:26:04 UTC
view on stackexchange narkive permalink

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 = xe 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).

Tuttavia, la mia comprensione è che la resistenza al parallelismo non è rilevante per l'hashing delle password.
Ben messo e ben risposto.
@RickyDemer: infatti, la resistenza al parallelismo può essere considerata una _ cosa cattiva_ per l'hashing della password, perché l'attaccante ha tutto il parallelismo che può desiderare (ha molte potenziali password per l'hash) mentre il difensore ottiene la password una alla volta. Se il difensore ha un'architettura parallela (ad esempio una GPU o anche un PC con pochi core), potrebbe preferire una funzione che supporti un parallelismo moderato. I server di autenticazione heavy-duty traggono vantaggio dal parallelismo in virtù dell'esecuzione simultanea di più autenticazioni basate su password.
Il tempo è relativo, ma la velocità della luce è assoluta. Metti la chiave di decrittazione a una distanza sufficiente dagli aggressori. Nessun computer potente può superarlo.
Questo è un caso di autentico "deposito a garanzia delle chiavi", e funziona in modo simile al normale deposito a garanzia ... Crittografa un file con una chiave simmetrica, dai la chiave a una società di deposito a garanzia insieme alla commissione, distruggi la tua copia e rilascia la chiave alla data X.
@emory non si limita a bloccare gli aggressori che non hanno accesso a materia esotica?
Lily Finley
2015-05-12 23:18:36 UTC
view on stackexchange narkive permalink

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.

Assolutamente. Non è necessaria un'autorità attendibile: crea un [tweet programmato] (https://blog.twitter.com/2013/now-available-scheduled-tweets) con la chiave di crittografia simmetrica o usa [un altro] (http: // futuretweets.com/)/ costruisci il tuo servizio se non ti fidi di Twitter. Se hai intenzione di essere in giro in futuro, potresti anche creare il tweet da solo. Crittografa e condividi i tuoi dati insieme alle informazioni sull'algoritmo di crittografia e sul tuo nome utente Twitter, e (generalmente) non saranno in grado di decrittografarli fino a quando il tuo tweet non diventerà pubblico.
@AronFoster: A meno che la parte che esegue la crittografia non crei il proprio servizio, ciò che stai descrivendo implica comunque l'utilizzo di una terza parte fidata. Quella festa è semplicemente Twitter.
Vero, anche se dipende da come OP definisce "autorità fidata". Non ha bisogno di pagare un avvocato per rivelare la chiave in una certa data; ci sono molti modi per rivelare automaticamente una chiave. Tuttavia, se non ti fidi affatto di nessuno (e presumi che non sarai in grado di pubblicare la chiave da solo), anche costruire il tuo servizio non è una soluzione poiché quel servizio sarà vulnerabile a sequestro o compromissione. Un sito ospitato da TOR, acquistato con bitcoin, programmato per rivelare la chiave in futuro, potrebbe ancora teoricamente essere scoperto da uno stato sufficientemente motivato.
@AronFoster: Non credo che Twitter si qualifichi come una "autorità fidata" in questo contesto. O la chiave fornita sul loro servizio funziona o no. Se per qualche motivo decidono di mentire sulla chiave, il messaggio verrà "decriptato" in modo incomprensibile e tutti sanno cosa hanno fatto. (Beh, quello o l'OP ha mentito sul fornire un testo cifrato legittimo.) Se Twitter decide di non fornire affatto la chiave, l'autore può pubblicare tramite QUALSIASI altro servizio. Il canale qui non ha importanza, poiché il requisito non è la segretezza, ma solo la distribuzione di una chiave che funzioni.
@loneboat: La vera fiducia al lavoro qui è la certezza che Twitter non rivelerà (o tenterà di utilizzare) la chiave prima del tempo specificato.
Ma se sei preoccupato che Twitter Inc. ti isolerà e violi le proprie regole solo per decrittare il tuo segreto in anticipo, avrai problemi molto più grandi del fatto che ti fidi di Twitter per non rivelare la chiave. Proprio come il modo in cui Microsoft non rivelerà una backdoor in BitLocker solo per addebitarti personalmente l'acquisto di droghe su Internet, se arrivi al punto in cui ti aspetti che un'azienda multimiliardaria ti scelga, allora le tue conversazioni sulla sicurezza digitale deve essere a un livello molto più alto di quello che abbiamo qui.
@AronFoster: Una terza parte fidata è ancora una terza parte fidata anche quando hanno più da perdere infrangendo questa fiducia di te.
@Pun Sì, anche se una soluzione senza una terza parte fidata è potenzialmente una cosa diversa da quella richiesta da Martin quando ha detto "senza un'autorità fidata (notaio)".
@Pun: Va bene, ha senso. Pensavo che l'autore non avrebbe dato a Twitter la chiave fino a quando non fosse stato pronto per il rilascio. Darlo loro prima del tempo implicherebbe davvero la fiducia.
Puoi sempre rompere la chiave usando la condivisione segreta e dare condivisioni a un gruppo di terze parti. Non devi fidarti di nessuno individualmente, devi solo fidarti che una parte di loro (e forse la frazione è 1) non riveli le loro azioni troppo presto.
@mikeazo Ora hai diverse terze parti fidate. Anche se se uno o due di loro rompono la loro fiducia non succederà nulla di male (a te).
Nessuna garanzia, ma puoi anche provare a creare una situazione in cui la terza parte fidata non sa di avere l'opportunità di tradirti. Fornisci alcuni caratteri della chiave ai decriptatori previsti ma non dire loro dove verranno pubblicati. Imposta un post a tempo utilizzando un account usa e getta su un'oscura piattaforma di pubblicazione (o su alcune). Possono utilizzare la ricerca di Google per trovarlo, ma * probabilmente * non possono contattare tutti gli editori nel mondo chiedendo loro di controllare i post a tempo memorizzati per trovarne uno che contenga "18B9DC340". Tuttavia, c'è una certa inaffidabilità e ritardo nella ricerca.
emory
2015-05-14 07:10:26 UTC
view on stackexchange narkive permalink

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.

Mi piace questa risposta perché non ha i "problemi di tempo" di altre risposte. Ma penso che potrebbe essere semplificato: hai bisogno di uno specchio a circa x / 2 anni luce di distanza, e poi trasmetti la chiave a quello specchio. Supponendo che nessuno sia in grado di annusarlo / disturbarlo, avresti il ​​ritardo appropriato di x anni.
@domen Non sono un esperto in queste materie, ma non potresti usare la teoria quantistica per assicurarti che la trasmissione allo specchio non venga intercettata. Non importa se la trasmissione viene intercettata durante il viaggio di ritorno.
@emory per quanto ne so, la teoria quantistica consente di rilevare se il messaggio viene intercettato, ma non di prevenirlo.
@DavidZ Ma la teoria quantistica consente anche di trasformare qualsiasi tentativo di intercettazione per trasformare il messaggio in incomprensibile (per il pubblico previsto * e * l'intercettatore)
@HagenvonEitzen ah, suppongo che tu abbia ragione - stavo pensando di "intercettato" nel senso di "bloccato". Una terza parte maligna può impedire al destinatario previsto di ricevere il messaggio, ma (probabilisticamente) non può accedere ai suoi contenuti senza violare anche il canale di comunicazione classico associato.
Sebbene divertente, questo conta davvero come una risposta legittima alla domanda? Sembra che la comunità la pensi così, ma a meno che l'OP non abbia 300 milioni di dollari questo * non * risponde alla domanda. Certo, OP potrebbe essere Bill Gates per quanto ne sappiamo.
Atsby
2015-05-14 08:28:57 UTC
view on stackexchange narkive permalink

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.

Presumibilmente useresti anche diverse classi di archiviazione delle chiavi - indipendente online; una sorta di rappresentante ufficiale / legale di fiducia; famiglia; la tua volontà (a seconda di come viene memorizzata). Il problema è che hai 2 modalità di errore quasi opposte, e se dici che K-2 ha rilasciato la chiave, c'è qualcosa che puoi fare al riguardo? Suggerisco di no.
@ChrisH Se si tratta di impedire la pubblicazione anticipata, è anche possibile fornire a ciascun servizio un checksum sicuro di ciascuna -altra- parte della chiave, e ogni servizio supporterebbe la cancellazione della chiave memorizzata su di essa con almeno `K '' chiavi trapelate in anticipo . Quindi chiedi a un amico fidato di cercare periodicamente tali chiavi trapelate in anticipo e, se ne trova abbastanza, invoca il protocollo di cancellazione su tutti i server rimanenti. I dati andrebbero persi per sempre, ovviamente.
questo è il genere di cose a cui stavo pensando. Ovviamente dovresti cancellare i tasti N-K + 1 solo se comprendo correttamente il sistema. D'altra parte, se il tuo amico fidato ha tradito la tua fiducia, potrebbe impedire il rilascio utilizzando il protocollo di cancellazione. Quindi finisci per aver bisogno di più watcher, ognuno dei quali potrebbe eliminare solo alcune chiavi, il che sono sicuro che introduce i suoi punti deboli.
@ChrisH L'amico fidato non può richiamare il protocollo di cancellazione a meno che le chiavi non siano state effettivamente trapelate. Quindi è un miglioramento che impedisce il rilascio se alcune chiavi sono trapelate, ma non consente all'amico di fare nulla se le chiavi non sono trapelate.
Non utilizzare un protocollo di eliminazione, utilizzare un numero maggiore per K e N. Risolve lo stesso problema.
@Ben Idealmente, ma cosa succede se stai già utilizzando tutti i futuri servizi di pubblicazione di `Nmax` ...
@atsby, Questo è un numero molto grande ..... Un futuro servizio di pubblicazione è "qualcuno di cui ti fidi, e una busta di carta marrone con una data all'esterno e le istruzioni all'interno".
@Ben Beh, non so voi, ma le persone di cui mi fido posso contare sulle dita di una sola mano o_O Inoltre, sarebbe bello se i servizi fossero automatizzati, ad esempio, in modo che le persone interessate ai dati possano ottenere un rapporto sullo stato che dice "sì, abbiamo ancora la chiave (parziale) memorizzata, altri 2 anni alla fine" ecc
@Atsby, a seconda del tuo modello di minaccia, potrebbe essere meglio se nessuno - nessuno - sapesse chi erano i detentori delle chiavi, prima o dopo il rilascio Se ti fidi di nessuno, hai problemi più grandi di un protocollo di impegno futuro :-)
@Ben * potrebbe essere meglio se nessuno - nessuno - sapesse chi erano i possessori delle chiavi, prima o dopo il rilascio * Bene, se nessuno sa chi sono i possessori delle chiavi parziali, come andrà qualcuno a ritirare le chiavi parziali quando è tempo? Il tuo protocollo ha bisogno di qualche riflessione in più ...
@Atsby, sono pubblicati ad es. bitbucket, o inviato via email all'EFF o ad entrambe o più opzioni. Qual è il problema? Essenzialmente: crea una coppia di chiavi RSA. Crittografa la chiave privata K di N e distribuisci le parti ai detentori delle chiavi con istruzioni per il rilascio nell'anno 2025. Pubblica la chiave pubblica. Ora chiunque può utilizzare il protocollo di impegno futuro senza ulteriore coordinamento.
@Ben Lol, le priorità umane cambiano nel corso della vita ed è probabile che la maggior parte non vedrà l'importanza di completare un compito del genere in 10 anni. I computer sono più affidabili.
@Atsby, Non sono in disaccordo! I detentori delle chiavi potrebbero essere organizzazioni commerciali, enti di beneficenza, avvocati, persone fisiche come JP o Notai o chiunque consideri affidabile per i tuoi scopi. Il coordinamento e la consapevolezza reciproca non sono però necessari. Inoltre non sono sicuro di come garantire che un computer funzioni in modo autonomo per dieci anni ...
dotancohen
2015-05-13 20:08:47 UTC
view on stackexchange narkive permalink

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.

Il tuo uso del tempo futuro per descrivere una data nel 1997 mi fa chiedere se hai una macchina del tempo, che renderebbe discutibile la crittografia bloccata nel tempo.
@DavidRicherby: Non è tanto una macchina del tempo in sé, ma uno degli effetti del mio wormhole relativistico è che incontro l'effetto prima della causa. Oh, e per rispondere alla tua prossima domanda: Titano, una luna di Saturno.
Allora, cosa mangi per cena stasera?
È un po 'di appetito! :-)
È quella cosa mangia-pianeti di Silver Surfer. Questo spiega tutto.
Sicuramente se puoi prevedere che Skynet diventerà consapevole in quella data, allora può farlo anche l'attaccante?
@DavidRicherby anche con una potente macchina del tempo, alcuni punti nel continuum spazio-temporale possono ancora essere bloccati nel tempo. Nessun viaggio nel tempo, nessun viaggio nel tempo. È una cosa maliziosa traballante, temporale ...
@immibis Forse l'attaccante (noto anche come NSA) troverebbe più conveniente fingere di non essere consapevole che skynet diventerà consapevole di sé.
Dato che Skynet viaggerà nel tempo, richiedere la conoscenza di un evento futuro per decrittografarlo non sembra un grosso ostacolo ;-)
@emory Perché dovrebbero farlo, se non fingere significa che possono decrittografare i tuoi dati?
@AviD Fammi sapere quando esce la tua fanfic crossover Dr. Who / Terminator.
@Immibis Stavo pensando che se avessero voluto usarlo contro di te in un tribunale avrebbero dovuto spiegare come hanno decrittografato i tuoi dati, ma a un ulteriore pensiero dovrebbero solo ammettere che pensano che pensi che skynet diventerà consapevole di sé una certa data.
Josh
2015-05-17 00:55:11 UTC
view on stackexchange narkive permalink

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.

Il dispositivo si riattiva dopo un secolo: rilevato indirizzo IPv6 duplicato, interfaccia disabilitata ...
SEJPM
2015-05-21 01:46:20 UTC
view on stackexchange narkive permalink

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.

Janna J
2015-05-14 00:46:47 UTC
view on stackexchange narkive permalink

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.

Jeff Meden
2015-05-14 01:18:58 UTC
view on stackexchange narkive permalink

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.

dronus
2015-05-16 15:46:36 UTC
view on stackexchange narkive permalink

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.

Kevin Keane
2015-05-18 04:55:35 UTC
view on stackexchange narkive permalink

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 .

Peter Wone
2015-05-18 18:11:26 UTC
view on stackexchange narkive permalink

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.

minibeyse
2015-11-23 17:55:46 UTC
view on stackexchange narkive permalink

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.

minibeyse
2015-11-23 18:32:39 UTC
view on stackexchange narkive permalink

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

Christian
2015-05-18 19:18:40 UTC
view on stackexchange narkive permalink

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.

Quindi suggerisci di creare un nuovo altcoin (in un mercato già affollato) solo per spostare il rilascio di un file? Anche se prende piede, se il tuo file è prezioso verrà decrittografato prima del previsto. Quelli che estraggono la moneta inizierebbero dal primo blocco e lavorerebbero in avanti, mentre chiunque volesse il file inizierebbe dall'ultimo blocco e lavorerebbe all'indietro, facendo solo il lavoro per rompere le chiavi, non aspettando 10 minuti tra uno e l'altro, e non necessariamente pubblicando i loro risultati. Quando i due gruppi "si sono incontrati", i cracker avrebbero avuto il tuo file.
Le nuove altcoin necessitano di nuove funzionalità per differenziarsi dalle monete esistenti. Questa caratteristica da sola potrebbe non giustificare una nuova moneta, ma insieme ad altre caratteristiche potrebbe. Una tale funzionalità potrebbe essere particolarmente preziosa se la blockchain venisse utilizzata come archivio pubblico di informazioni. Potrei immaginare di preregistrare prove scientifiche su una blockchain. In tal caso, gli scienziati potrebbero voler avere un lasso di tempo prima che le informazioni vengano rese pubbliche, ma allo stesso tempo le informazioni non sono abbastanza preziose per un aggressore.
Jonathan
2015-05-14 02:25:16 UTC
view on stackexchange narkive permalink

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.

Le altre risposte qui mostrano che questo non è l'unico modo. Se mantieni la chiave fino alla data, come suggerisce uno di loro, non è necessario controllare il codice di decrittazione.
Lo spoofing di un orologio o di un altro segnale esterno sarà più facile che decifrare direttamente la crittografia, o semplicemente sposterà il problema: come si impedisce che l'orologio "sicuro" venga violato prima di una data specifica?
Unspoofable sarà impossibile, ma puoi avvicinarti un po 'usando più fonti di tempo affidabili. Usa diversi server NTP affidabili in diversi paesi (possono essere falsificati dal reindirizzamento dell'indirizzo IP) insieme a un orologio basato su GPS (che potrebbe essere falsificato da qualcuno con il budget per costruire un'infrastruttura di simulatore GPS).


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...