È possibile creare una "Time Capsule" utilizzando la crittografia?


14

Voglio creare una capsula del tempo digitale che rimarrà illeggibile per un certo periodo di tempo e quindi diventerà leggibile. Non voglio fare affidamento su alcun servizio esterno per, ad esempio, mantenere la chiave segreta e quindi rivelarla al momento richiesto. È possibile? In caso contrario, è possibile avere qualche prova che non lo sia?

Una strategia si baserebbe sulle proiezioni delle future capacità informatiche, ma ciò è inaffidabile e fa ipotesi su quante risorse verrebbero applicate all'attività.


1
Se è possibile garantire che il dispositivo non sia manomesso, è possibile utilizzare componenti (leggermente) radioattivi con un tempo di dimezzamento noto, quindi è possibile concedere l'accesso solo se la radioattività è diminuita sufficientemente.
Raffaello

Risposte:


5

Il problema è noto come crittografia a rilascio temporizzato . Per alcuni riferimenti / introduzioni guarda:

La nostra motivazione è la nozione di "crittografia a rilascio temporizzato", in cui l'obiettivo è crittografare un messaggio in modo che non possa essere decrittografato da nessuno, nemmeno dal mittente, fino a quando non è trascorso un periodo di tempo predeterminato. L'obiettivo è "inviare informazioni nel futuro" ...


7
Potresti almeno riassumere i documenti?
svick,

5
I documenti fanno uno studio approfondito dei due approcci "naturali": o usano una terza parte fidata, o richiedono al destinatario di eseguire un calcolo che non si parallelizza bene e impiega approssimativamente la giusta quantità di tempo.
a3nm,

1

Ho trovato una risposta parziale, ma non una risposta rigorosa alla domanda come indicato. Sospetto che questo possa essere il più vicino possibile, ma non ne sono sicuro.

Innanzitutto, codifichiamo la capsula con la chiave richiesta per la decrittazione.

Non so come aggirare avere una sorta di autorità per tenere la chiave, ma è possibile distribuire quella funzione. Se rompiamo la chiave in n pezzi, allora possiamo chiedere a n autorità di trattenere i pezzi. Quindi al momento opportuno tutti potrebbero pubblicare i loro pezzi per consentire la ricostruzione della chiave.

Questa soluzione è vulnerabile alla mancata disponibilità di nessuna delle autorità, ma utilizzando la codifica m-out-of-n, possiamo distribuire i pezzi a n autorità, ma richiediamo solo a m di pubblicare i loro pezzi.

Anche in questo caso, un certo numero di autorità con un orologio preciso deve fornire un corretto servizio di gestione delle chiavi. È possibile indebolire questa ipotesi oltre la m-out-of-n suggerita sopra?


1

Penso che questo sia un approccio praticabile:

Genera un set di chiavi usando il tuo schema di crittografia preferito usando una passphrase generata casualmente. Il trucco qui è con la passphrase. La chiave è nota, ma creeremo una capsula del tempo usando la passphrase.

Scegli una passphrase tale che, se creiamo da essa un hash salato, ci vorranno circa "n" anni per calcolare la passphrase data il sale e l'hash noti utilizzando la potenza di calcolo di oggi. Se vogliamo creare una capsula da 20 anni, stimare la nostra potenza di calcolo tra 20 anni e creare un hash che sarà calcolabile in un mese da un utente o da un supercomputer tra 20 anni, a seconda dell'obiettivo della capsula. Immagina, per una capsula temporale di 20 anni, che sarà decifrabile da un megacorp tra 15 anni o da un utente tra 20.

Crittografa i dati utilizzando chiavi con passphrase casuale, archivia la chiave e la passphrase con hash e non memorizza la passphrase effettiva. Ora conserva i dati e, ad un certo punto in futuro, spero che tu abbia la potenza di calcolo per recuperare i tuoi dati!


0

Non sono un crittografo, solo un ingegnere, quindi la mia soluzione è più fisica che computazionale, ma lasciami provare comunque. Propongo la seguente procedura:

  1. Genera la coppia di chiavi asimmetrica
  2. Crittografa il messaggio in chiaro utilizzando la chiave pubblica
  3. Memorizza la chiave privata nella memoria volatile di un microcontrollore e rendila in uscita solo dopo un certo periodo di tempo.
  4. Distruggi tutte le altre copie della chiave privata
  5. Raggruppa insieme il testo cifrato e il microcontrollore e attendi.

Si pone quindi la domanda ovvia: perché preoccuparsi della crittografia quando è possibile archiviare il messaggio in chiaro nel chip? La risposta a questa domanda è che in questo modo, il testo in chiaro può essere arbitrariamente lungo, senza colpire la capacità di memoria del chip, perché lì è memorizzata solo la chiave a lunghezza fissa. Inoltre, puoi conservare una copia della chiave pubblica, generando più messaggi con essa in seguito, che vengono poi sbloccati contemporaneamente. Ma questo è tutto.

Per renderlo ancora più sicuro, è possibile collegare un sensore di luce al chip e racchiudere il gruppo in una custodia a prova di luce (o avere un interruttore collegato alla porta o qualche altro meccanismo di rilevamento della manomissione), dove esponendo il sensore alla luce attiverà la cancellazione dei tasti. Questo per evitare di ottenere la chiave usando metodi invasivi come l'attacco. Alcuni chip hanno anche i loro strati di silicio strutturati in modo da rendere quasi impossibile la lettura invasiva, mettendo altri circuiti essenziali sopra la memoria, per oscurare i singoli bit.


Se c'è un orologio interno, qualcuno potrebbe accelerarlo o rimuoverlo. Non è affatto buono.
Male

@Evil Ci ho pensato, e non è un problema proprio perché il chip può essere overcloccato solo così tanto prima di diventare instabile, quindi rischiare di perdere la chiave. Ad esempio, la maggior parte degli AVR a 8 bit funzionerà fino a 20 MHz, può essere overcloccato a circa 25 MHz, ma soprattutto la possibilità di un incidente aumenta in modo significativo.
programma il

1
Stai reinventando hardware a prova di manomissione ... qualcosa che è difficile da fare bene, specialmente su scale temporali lunghe.
DW
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.