Pytanie:
Upewnij się, że plik można odszyfrować dopiero po określonej dacie
Martin Vegter
2015-05-12 23:05:41 UTC
view on stackexchange narkive permalink

Czy istnieją jakieś schematy / protokoły kryptograficzne, które pozwoliłyby mi zaszyfrować plik, udostępnić go publicznie, ale zapewniają, że można go odszyfrować dopiero po określonej dacie?

Zakładam, że byłoby to prawie niemożliwe bez zaufanego organu (notariusza). Czy jest jakiś sposób?

Zainspirował mnie pomysł „bezpiecznych wyzwalaczy”, czyli schematu do odszyfrowania danych po wystąpieniu określonego zdarzenia. Ale to „zdarzenie wyzwalające” jest znane tylko autorowi.

W przeciwieństwie do tego jestem zainteresowany schematem kryptograficznym, który umożliwiłby odszyfrowanie danych w (lub po) określonym, powszechnie znanym dniu. / p>

Możliwy duplikat: https://crypto.stackexchange.com/questions/606/time-capsule-cryptography
Pozornie wydaje się, że odpowiedzią na twoje pytanie są „zagadki z blokadą czasową”, które wymagają od kogoś wykonania X pracy w celu uzyskania klucza. Może to zadziałać, jeśli ktoś zechce poświęcić serwer do rozwiązania zagadki, a następnie opublikuje klucz, ale zdecydowanie tak. nie jest dobrym rozwiązaniem po stronie klienta.
Nawiasem mówiąc, Cicada3301 wcześniej pracowała nad projektem depozytu informacji.
Musisz trochę pomyśleć o swoim pytaniu, aby zobaczyć, czy ma ono w ogóle sens. Kto w pierwszej kolejności ustala datę i godzinę? Jeśli Kongres zdecyduje, że czas letni nagle się kończy, a plik został odszyfrowany 10 sekund temu, czy naprawdę oczekujesz, że zostanie ponownie zapieczętowany? Jeśli przekraczasz granicę kraju, czy Twój plik ma na to jakoś zareagować? Czy nie jest całkiem oczywiste, że możliwość odszyfrowania pliku musi koniecznie wymagać współpracy tego, kto decyduje o bieżącej dacie / godzinie?
Zastanawiam się, czy jest ktoś, kto wydaje się godny zaufania, kto wcześniej udostępnił pakiet kluczy publicznych i podał ustalone daty, w których wyda każdy pasujący klucz prywatny. To może być przydatna usługa.
Czas @Mehrdad Unix. Dopóki nie poruszamy się z relatywistycznymi prędkościami, czas uniksowy jest jednoznaczny :)
Czy możesz być na bieżąco? Jest to trywialne, jeśli po prostu opublikujesz klucz odszyfrowywania w dniu, w którym chcesz zezwolić na odszyfrowanie. Skutecznie stajesz się stroną zaufaną. W przeciwnym razie jest to teoretycznie niemożliwe do uzyskania informacji (co oznacza, że ​​mówisz teraz o rozwiązaniach sprzętowych, a nie o teoretycznych rozwiązaniach kryptograficznych).
A co z powiązaniem go z publicznymi serwerami NTP? Cały argument, że czas jest efemeryczny, jest trudny do argumentowania poza światem teoretycznym, ponieważ wszyscy pracujemy według harmonogramów. Kiedy mój szef mówi „Przyjdź o 8 rano”, nie pytam go „W jakiej strefie czasowej”. Jeśli chodzi o pytanie, czy jest jakiś sposób, aby ustawić deszyfrowanie na, powiedzmy, godzinę / datę GMT a następnie wykonać to tylko wtedy, gdy komputer ma dostęp do publicznego serwera NTP?
@Navin W jakim sensie „czas uniksowy” jest w tym przypadku jednoznaczny? Mogę ustawić „bieżącą datę / godzinę” na serwerze tak, jak chcę. Jak pomógłby czas Unix? Mógłbym nawet uzyskać dostęp do serwerów czasu, jeśli kontroluję moją sieć lokalną.
@user2338816 Jasne, ale jeśli zmienisz czas serwera, ten czas byłby zły. Czas jest określony postępem wszelkich procesów fizycznych. Nie twierdzę, że powyższe pytanie ma rozwiązanie. Po prostu czas nie ma nic wspólnego z czasem letnim ani z tym, co definiują prawa.
@Navin Czas uniwersalny, którego szukasz, to prawdopodobnie UT1 lub TT. UT1 to średni czas słoneczny na 0 ° długości geograficznej, więc jest to czysto fizyczna miara oparta na roku ziemskim. TT (Terrestrial Time) opiera się na liczeniu standardowych sekund w znanym układzie odniesienia, który również działa. TCG to podstawowy system, który wykorzystuje środek Ziemi - bez ziemskiej grawitacji. TT dodaje korektę grawitacji do TCG, aby dopasować zegar atomowy na Ziemi. (Wszechobecny UTC jest systemem hybrydowym: każda sekunda to długość sekundy TT, ale niektóre dni mają 86401 sekund, więc UTC pozostaje mniej niż sekunda z dala od UT1.)
Szesnaście odpowiedzi:
Tom Leek
2015-05-12 23:26:04 UTC
view on stackexchange narkive permalink

Czas jest względny. Kryptografia żyje w eterycznym świecie abstrakcyjnych maszyn obliczeniowych: są maszyny, które mogą wykonywać operacje. Większe maszyny mogą wykonywać operacje szybciej. Nie ma zegara, który możesz wymusić; czas fizyczny nie ma znaczenia. Innymi słowy, jeśli napastnik chce uzyskać Twój plik wcześniej, musi po prostu kupić szybszy komputer.

Teraz nadal można się postarać. Mogą Cię zainteresować łamigłówki związane z blokadą czasową. Chodzi o to, aby móc utworzyć problematyczną instancję, która jest łatwa do zbudowania, ale droga do otwarcia, której koszt można skonfigurować. Rozwiązanie znalezione przez Rivesta, Shamira i Wagnera (według mojej wiedzy jest to jedyna znana dotychczas praktyczna łamigłówka z blokadą czasową) działa tak:

  • Wygeneruj losowy moduł RSA n = pq gdzie p i q to duże liczby pierwsze (a także p = 3 mod 4, i q = 3 mod 4).
  • Wygeneruj losowy x modulo n.
  • Dla jakiejś liczby całkowitej w , zdefiniuj e = 2 w i oblicz y = xe mod n.
  • Hash y with jakaś funkcja skrótu, dająca ciąg K , którego używasz jako klucza do zaszyfrowania pliku, który chcesz zablokować czasowo.
  • Publikuj x , n , w i zaszyfrowany plik. Odrzuć p , q , y i K.

Trudne Chodzi o to, że obliczenia y , ogólnie rzecz biorąc, mają koszt, który jest proporcjonalny do w : jest to ciąg w modularnych kwadratów. Jeśli w jest rzędu miliardów lub więcej, będzie to kosztowne. Jednak gdy znane są czynniki p i q , to można obliczyć e modulo p-1 i q-1 , co będzie dużo krótsze, a obliczenie y można wykonać w ciągu kilku milisekund.

Oczywiście nie gwarantuje to wydania w określonym dniu ; raczej gwarantuje minimalny wysiłek , aby odblokować zagadkę. Konwersja między wysiłkiem a datą zależy od tego, jak bardzo starają się atakujący ...

Opisana powyżej łamigłówka z blokadą czasu ma kilka fajnych cech, w szczególności jest odporna na równoległość. Jeśli spróbujesz złamać jedną taką łamigłówkę i masz dwa komputery, nie osiągniesz prędkości szybciej niż to, co mógłbyś zrobić na jednym komputerze.

W nieco podobnym kontekście, ta łamigłówka blokująca czas jest używana w funkcji mieszania haseł Makwa, kandydacie do trwającego PHC. Podczas haszowania haseł potrzebujesz konfigurowalnego wysiłku otwierania (aczkolwiek w znacznie krótszym czasie, zwykle mniej niż sekunda).

Jednak rozumiem, że odporność na paralelizm nie ma znaczenia dla haszowania haseł.
Dobrze powiedziane i dobrze odebrane.
@RickyDemer: w rzeczywistości, odporność na paralelizm można argumentować jako _zła rzecz_ dla haszowania haseł, ponieważ atakujący ma tyle równoległości, ile może sobie życzyć (ma wiele potencjalnych haseł do haszowania), podczas gdy obrońca otrzymuje hasło pojedynczo. Jeśli obrońca ma architekturę równoległą (np. GPU lub nawet komputer z kilkoma rdzeniami), może preferować funkcję obsługującą umiarkowany równoległość. Serwery uwierzytelniania o dużej wydajności korzystają z równoległości dzięki możliwości jednoczesnego uruchamiania wielu uwierzytelnień opartych na hasłach.
Czas jest względny, ale prędkość światła jest absolutna. Umieść klucz deszyfrujący w odpowiedniej odległości od atakujących. Żaden potężny komputer nie może tego pokonać.
Jest to przypadek prawdziwego „depozytu klucza”, który działa podobnie do zwykłego depozytu… Zaszyfruj plik za pomocą klucza symetrycznego, przekaż klucz firmie depozytowej wraz z opłatą, zniszcz swoją kopię, zwolnij klucz w dniu X.
@emory nie blokuje tylko atakujących, którzy nie mają dostępu do egzotycznej materii?
Lily Finley
2015-05-12 23:18:36 UTC
view on stackexchange narkive permalink

Jeśli nie chcesz angażować strony trzeciej, Ty (strona szyfrująca plik) możesz po prostu zwolnić klucz, aby odszyfrować plik w docelowym dniu.

Widziałem to w przypadku wideo wydania gier. Klienci mogą wcześniej pobrać zaszyfrowaną kopię gry. Następnie, gdy nadejdzie czas wydania, firma po prostu wypuszcza klucz. W ten sposób ludzie mogą zacząć grać natychmiast po wydaniu gry, bez konieczności czekania na pobranie.

Absolutnie. Nie ma potrzeby korzystania z zaufanego organu: utwórz [zaplanowany tweet] (https://blog.twitter.com/2013/now-available-scheduled-tweets) z symetrycznym kluczem szyfrowania lub użyj [innego] (http: // futuretweets.com/)/ zbuduj własną usługę, jeśli nie ufasz Twitterowi. Jeśli planujesz być w przyszłości, możesz również samodzielnie utworzyć tweet. Szyfruj i udostępniaj swoje dane wraz z informacjami o algorytmie szyfrowania i Twojej nazwie użytkownika na Twitterze, a oni (ogólnie) nie będą w stanie ich odszyfrować, dopóki Twój tweet nie zostanie opublikowany.
@AronFoster: O ile strona szyfrująca nie zbuduje własnej usługi, to, co opisujesz, nadal wymaga korzystania z zaufanej strony trzeciej. Tak się składa, że ​​imprezą jest Twitter.
To prawda, chociaż zależy to od tego, jak OP definiuje „zaufany organ”. Nie musi płacić prawnikowi za ujawnienie klucza w określonym dniu; istnieje wiele sposobów automatycznego ujawnienia klucza. Jeśli jednak w ogóle nie ufasz nikomu (i zakładasz, że nie będziesz w stanie samodzielnie wysłać klucza), nawet zbudowanie własnej usługi nie jest rozwiązaniem, ponieważ ta usługa będzie narażona na przejęcie lub naruszenie bezpieczeństwa. Witryna hostowana przez TOR, kupiona za pomocą bitcoinów, zaprogramowana tak, aby ujawniać klucz w przyszłości, teoretycznie mogłaby zostać odkryta przez wystarczająco zmotywowane państwo.
@AronFoster: Nie sądzę, aby Twitter kwalifikował się jako „zaufany organ” w tym kontekście. Albo klucz podany w ich usłudze działa, albo nie. Jeśli z jakiegoś powodu zdecydują się kłamać na temat klucza, wiadomość zostanie „odszyfrowana”, aby bełkotać i wszyscy wiedzą, co zrobili. (Cóż, to lub OP kłamał, podając legalny zaszyfrowany tekst.) Jeśli Twitter zdecyduje się w ogóle nie podawać klucza, to autor może publikować za pośrednictwem JAKIEJKOLWIEK innej usługi. Kanał tutaj nie ma znaczenia, ponieważ wymaganiem nie jest zachowanie tajemnicy, a jedynie dystrybucja klucza, który działa.
@loneboat: Prawdziwe zaufanie w pracy polega tutaj na zapewnieniu, że Twitter nie ujawni (ani nie spróbuje użyć) klucza przed określonym czasem.
Ale jeśli obawiasz się, że Twitter Inc. wyodrębni Cię i naruszy własne zasady tylko po to, aby odszyfrować Twój sekret wcześniej, będziesz miał znacznie większe problemy niż fakt, że zaufałeś Twitterowi, że nie ujawni klucza. Podobnie jak Microsoft nie zamierza ujawniać backdoora w funkcji BitLocker tylko po to, aby osobiście obciążyć Cię zakupem narkotyków przez Internet, jeśli dojdziesz do punktu, w którym spodziewasz się, że warta wiele miliardów dolarów firma Cię wyróżni, to Twoje rozmowy w zakresie bezpieczeństwa cyfrowego musi być na znacznie wyższym poziomie niż tutaj.
@AronFoster: Zaufana strona trzecia jest nadal zaufaną stroną trzecią, nawet jeśli ma więcej do stracenia, łamiąc to zaufanie, niż Ty.
@Pun Tak, chociaż rozwiązanie bez zaufanej strony trzeciej jest potencjalnie inną rzeczą, o którą prosił Martin, gdy powiedział „bez zaufanego organu (notariusza)”.
@Pun: OK, to ma sens. Myślałem, że autor nie da Twitterowi klucza, dopóki nie będzie gotowy na jego wydanie. Przekazanie im tego z wyprzedzeniem rzeczywiście wymagałoby zaufania.
Zawsze możesz złamać klucz za pomocą tajnego udostępniania i przekazać udostępnienia grupie osób trzecich. Nie musisz ufać nikomu z osobna, musisz tylko ufać, że jakaś część z nich (a może ułamek to 1) nie ujawni swoich udziałów zbyt wcześnie.
@mikeazo Teraz masz kilka zaufanych stron trzecich. Jednak jeśli jeden lub dwóch z nich złamie zaufanie, nic złego się nie stanie (tobie).
Brak gwarancji, ale możesz też spróbować stworzyć sytuację, w której zaufana osoba trzecia nie wie, że ma okazję Cię zdradzić. Podaj kilka znaków klucza do odpowiedniego dekryptera (-ów), ale nie mów im, gdzie zostanie wysłany. Skonfiguruj wpis z określonym czasem, używając konta jednorazowego użytku na mało znanej platformie wydawniczej (lub na kilku). Mogą użyć wyszukiwarki Google, aby go znaleźć, ale * prawdopodobnie * nie mogą skontaktować się z każdym wydawcą na świecie, prosząc ich o sprawdzenie, czy w ich przechowywanych postach z określonym czasem znajduje się „18B9DC340”. Istnieje jednak pewna zawodność i opóźnienia w wyszukiwaniu.
emory
2015-05-14 07:10:26 UTC
view on stackexchange narkive permalink

Ostrożnie umieść statek kosmiczny nadający klucz deszyfrujący na orbicie wokół czarnej dziury. Siła grawitacji opóźni przekaz do odpowiedniego czasu.

Lub możesz po prostu postąpić jak normalni ludzie i umieścić kluczowy statek kosmiczny nadający odpowiednią liczbę lat świetlnych od zamierzonej publiczności.

Podoba mi się ta odpowiedź, ponieważ nie zawiera ona „problemów czasowych” innych odpowiedzi. Ale myślę, że można to uprościć - potrzebujesz lustra w odległości około x / 2 lat świetlnych, a następnie przekazujesz klucz do tego lustra. Zakładając, że nikt nie jest w stanie go wąchać / przeszkadzać, miałbyś odpowiednie opóźnienie wynoszące x lat.
@domen Nie jestem ekspertem w tych sprawach, ale nie mógłbyś użyć teorii kwantowej, aby upewnić się, że transmisja do lustra nie zostanie przechwycona. Nie ma znaczenia, czy transmisja zostanie przechwycona w drodze powrotnej.
@emory, o ile wiem, teoria kwantowa pozwala wykryć, czy wiadomość jest przechwytywana, ale nie zapobiega temu.
@DavidZ Ale teoria kwantowa pozwala również zamienić każdą próbę podsłuchania, aby zamienić wiadomość w bełkot (zarówno z docelową publicznością *, jak i * podsłuchującym)
@HagenvonEitzen ah, przypuszczam, że masz rację - myślałem o „przechwyconym” w znaczeniu „zablokowany”. Złośliwa osoba trzecia może w ogóle uniemożliwić zamierzonemu odbiorcy odebranie wiadomości, ale (prawdopodobnie) nie może uzyskać dostępu do jej zawartości bez złamania powiązanego z nią klasycznego kanału komunikacji.
Chociaż zabawne, czy faktycznie liczy się to jako uzasadniona odpowiedź na to pytanie? Wygląda na to, że społeczność tak uważa, ale jeśli OP nie ma 300 milionów dolarów, to * nie * odpowiada na pytanie. To prawda, że ​​OP mógłby być Billem Gatesem z tego, co wiemy.
Atsby
2015-05-14 08:28:57 UTC
view on stackexchange narkive permalink

Użyj tajnego udostępniania, aby podzielić prywatny klucz szyfrowania na N części, sparametryzowanych, aby umożliwić rekonstrukcję klucza z K lub większą liczbą części, gdzie K < = N . Najlepiej zrobić to za pomocą CRM, jak opisano na następującej stronie:

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

Następnie wyślij każdą część niezależnym serwisom, które zgadzają się publikować w określonym terminie w przyszłości.

Aż do K-1 usług może "uszkodzić" poprzez wcześniejsze opublikowanie bez wpływu na schemat.

Aż do NK usług może nie zostać opublikowanych w ogóle, również bez wpływu na schemat.

Prawdopodobnie używałbyś również różnych klas przechowywania kluczy - niezależnego online; jakiś zaufany przedstawiciel urzędowy / prawny; rodzina; Twoja wola (w zależności od tego, jak jest przechowywana). Problem w tym, że masz 2 prawie przeciwne tryby awarii, a jeśli powiesz, że K-2 po zwolnieniu klawisza, czy jest coś, co możesz z tym zrobić - nie radzę.
@ChrisH Jeśli chodzi o zapobieganie wczesnemu publikowaniu, możesz również dostarczyć każdej usłudze bezpieczną sumę kontrolną każdej innej części klucza, a każda usługa będzie obsługiwać usuwanie przechowywanego na niej klucza, mając co najmniej `K '' wcześnie wyciekłe klucze . Następnie poproś zaufanego przyjaciela o okresowe wyszukiwanie takich wcześnie wyciekłych kluczy, a jeśli zostanie znalezionych wystarczająca liczba, wywołaj protokół usuwania na wszystkich pozostałych serwerach. Oczywiście dane zostałyby utracone na zawsze.
o tym właśnie myślałem. Oczywiście wystarczyłoby wyczyścić klawisze N-K + 1, jeśli dobrze rozumiem system. Z drugiej strony, jeśli zaufany przyjaciel zdradził Twoje zaufanie, może uniemożliwić wydanie przy użyciu protokołu usuwania. W końcu potrzebujesz więcej obserwatorów, z których każdy mógłby usunąć tylko niektóre klucze, co z pewnością wprowadza własne słabości.
@ChrisH Zaufany przyjaciel nie może wywołać protokołu usuwania, chyba że klucze faktycznie wyciekły. Jest to więc ulepszenie, które zapobiega wydaniu, jeśli wycieknie niektóre klucze, ale nie pozwala przyjacielowi na nic, jeśli klucze nie wyciekną.
Nie używaj protokołu usuwania, użyj większej liczby dla K i N. Rozwiązuje ten sam problem.
@Ben Idealnie, ale co jeśli już używasz wszystkich przyszłych usług wydawniczych `Nmax` ...
@atsby, To bardzo duża liczba… Przyszła usługa wydawnicza to „każdy, komu ufasz, i brązowa koperta z datą na zewnątrz i instrukcją w środku”.
@Ben No nie wiem jak wy, ale zaufane osoby mogę policzyć na palcach jednej ręki o_O Poza tym fajnie by było, gdyby usługi były zautomatyzowane, np. Aby osoby zainteresowane danymi mogły dostać raport o stanie mówiący „tak, nadal mamy (częściowy) klucz przechowywany, jeszcze 2 lata” itd
@Atsby, w zależności od modelu zagrożenia, może być lepiej, jeśli nikt - nikt - nie wiedział, kim byli posiadacze kluczy, przed lub po wydaniu.Jeśli nikomu nie ufasz, masz większe problemy niż protokół zobowiązań na przyszłość :-)
@Ben * może być lepiej, gdyby nikt - nikt - nie wiedział, kim byli posiadacze kluczy, przed lub po wydaniu * Cóż, jeśli nikt nie wie, kim są posiadacze częściowych kluczy, w jaki sposób ktoś ma chodzić i zbierać częściowe klucze czas? Twój protokół wymaga więcej przemyślenia ...
@Atsby, są publikowane np. bitbucket lub wysłany e-mailem do EFF lub obie lub więcej opcji. W czym problem? Zasadniczo: utwórz parę kluczy RSA. Zaszyfruj klucz prywatny K z N i przekaż części posiadaczom kluczy z instrukcjami wydania w roku 2025. Opublikuj klucz publiczny. Teraz każdy może korzystać z przyszłego protokołu zobowiązań bez dalszej koordynacji.
@Ben Lol, ludzkie priorytety zmieniają się na przestrzeni życia i prawdopodobnie większość nie dostrzeże znaczenia wykonania takiego zadania za 10 lat. Komputery są bardziej niezawodne.
@Atsby, Nie zgadzam się! Kluczowymi osobami mogą być organizacje komercyjne, organizacje charytatywne, prawnicy, osoby fizyczne, takie jak JP lub notariusze, lub ktokolwiek, kogo uważasz za wiarygodnego do swoich celów. Koordynacja i wzajemna świadomość nie są jednak konieczne. Nie jestem też pewien, jak zagwarantować, że komputer będzie działał autonomicznie przez dziesięć lat ...
dotancohen
2015-05-13 20:08:47 UTC
view on stackexchange narkive permalink

Uważam, że aby właściwie zaprojektować swój system, musisz zdefiniować, co oznacza „czas” w Twoim kontekście i dlaczego wybrałeś określony czas . Zakładając, że Twoja wiadomość ma zostać odszyfrowana 29 sierpnia 1997 r. O godzinie 02:14, jaka jest różnica między momentem przed a chwilą po ostatecznym terminie? Dlaczego konkretnie ta data? Możesz wykorzystać to wydarzenie jako element swojego programu.

Na przykład, jeśli spodziewasz się, że Skynet stanie się samoświadomy w tym dniu w pytaniu i chcesz, aby wiadomość została odszyfrowana dopiero po tym, jak Skynet stanie się samoświadomy, kluczem deszyfrującym może być „skynet_became_self_aware”. Jest mało prawdopodobne, aby został brutalnie wymuszony, zwłaszcza że zawiera słowo spoza słownika. Jednak staje się bardzo prawdopodobne, że zostanie wypróbowany po wystąpieniu zdarzenia, zwłaszcza jeśli istnieją zautomatyzowane systemy próbujące go brutalnie wymusić, które dodają słowo „skynet” do swoich słowników w odpowiednim czasie.

Ten schemat nie jest doskonały, ponieważ szansa na brutalne wymuszenie klucza nadal istnieje, a nawet po dacie mogą nie być używane odpowiednie zasoby w celu jego złamania. Ten schemat ma jednak tę dodatkową zaletę, że jeśli wydarzenie, którego datę wybierzesz nastąpi wcześniej lub później niż oczekiwano , wiadomość nie zostanie odszyfrowana zbyt późno / zbyt wcześnie.

Twoje użycie czasu przyszłego do opisania daty w 1997 roku sprawia, że ​​zastanawiam się, czy masz wehikuł czasu, który sprawiłby, że szyfrowanie czasowe byłoby dyskusyjne.
@DavidRicherby: To nie tyle wehikuł czasu jako taki, ale jednym z efektów mojego relatywistycznego tunelu czasoprzestrzennego jest to, że napotykam skutek przed przyczyną. Aha, i odpowiadając na twoje następne pytanie: Tytan, księżyc Saturna.
Więc co masz dziś na kolację?
To trochę apetytu! :-)
To ten zjadacz planet ze Srebrnego Surfera. To wyjaśnia wszystko.
Z pewnością, jeśli potrafisz przewidzieć, że Skynet stanie się samoświadomy w tym dniu, to czy może to zrobić atakujący?
@DavidRicherby nawet z potężnym wehikułem czasu, pewne punkty w czasoprzestrzeni mogą być nadal zablokowane w czasie. Żadnych rozkładów jazdy, żadnych rozkładów jazdy. To chwiejna, chwiejna, dziwaczna rzecz ....
@immibis Być może napastnikowi (znanemu również jako NSA) wygodniej byłoby udawać, że nie jest świadomy, że skynet stanie się samoświadomy.
Biorąc pod uwagę, że Skynet będzie podróżował w czasie, wymaganie wiedzy o przyszłym wydarzeniu do odszyfrowania nie wydaje się dużą barierą ;-)
@emory Dlaczego mieliby to robić, jeśli nie udawanie oznacza, że ​​mogą odszyfrować Twoje dane?
@AviD Daj mi znać, kiedy wyjdzie fanfic na temat crossovera Dr. Who / Terminator.
@Immibis Myślałem, że gdyby chcieli użyć tego przeciwko tobie w sądzie, musieliby wyjaśnić, w jaki sposób odszyfrowali twoje dane, ale po dalszej myśli musieliby tylko przyznać, że sądzą, że skynet stanie się samoświadomy na pewna data.
Josh
2015-05-17 00:55:11 UTC
view on stackexchange narkive permalink

Jeśli jedyną zaufaną stroną jesteś Ty i nie możesz zagwarantować, że będziesz dostępny, gdy treść wiadomości ma zostać upubliczniona, możesz zamiast tego zbudować urządzenie (fizyczne lub wirtualne), które automatycznie klucz publiczny w wymaganym czasie, a następnie ukryj urządzenie.

Łatwym sposobem byłoby zakupienie wirtualnego serwera od Amazon lub którejkolwiek z setek innych firm - być może kilku serwerów w innych krajach - pod innym tożsamość, której nie można prześledzić do tożsamości osoby, która opublikowała wiadomość. Najlepiej byłoby kupić ten serwer kilka lat przed opublikowaniem wiadomości. Te serwery po prostu siedzą i czekają, nic nie robiąc (być może obsługują niewinnie wyglądający serwer e-mail lub FTP) do określonej daty, a następnie publikują klucz odszyfrowywania wieloma kanałami publicznymi, aby spełnić Twoją definicję upublicznienia informacji. "

Nikt nawet nie wiedziałby, że te serwery istnieją, więc nikt ich nie szuka; a ich cel może być na tyle zaciemniony, że nikt, kto natknie się na nie przypadkowo, nie zdaje sobie sprawy, do czego służą. Istnieje wiele milionów serwerów podłączonych do Internetu - twoje są po prostu zagubione w szumie.

To wystarczy, chyba że opinia publiczna zostanie uznana za na tyle ważną, że podjęto by ogólnoświatowy wysiłek zlokalizować klucz na skalę, która zainspiruje rządy do przeprowadzenia zaawansowanej analizy ruchu na każdym serwerze wirtualnym i fizycznym, który wszedł w tryb online w ciągu ostatniej dekady, a następnie ręcznego zbadania wszystkich plików i kodu każdego z (milionów) podejrzanych plików, wyszukując dla ukrytych informacji.

W takim przypadku możesz jeszcze bardziej ukryć urządzenie. Jeśli naprawdę chcesz zrobić to w stylu Jamesa Bonda, umieść wiadomość na taśmie podłączonej do krótkofalowego nadajnika radiowego z rezerwową baterią na Antarktydzie (gdzie może zostać zakopany w śniegu) lub w odległej Brazylii dżungli (gdzie może zostać uszkodzony przez zwierzęta) lub na dnie oceanu, z chemicznie napompowaną poduszką powietrzną, która wypłynie na powierzchnię w określonym dniu i czasie (gdzie może korodować - może Lake Superior jest bezpieczniejsze? ) lub zakopane płytko pod ziemią, z anteną przypominającą peryskop.

Oczywiście trudność i koszt każdej z tych opcji zależą od tego, jak długo chcesz ukryć urządzenie. Jeśli minęło sto lat, prawdopodobnie zmieniły się protokoły internetowe, a cokolwiek bardziej złożonego niż analogowe radio krótkofalowe może być niewykonalne. (I może się zdarzyć, że nikt już też nie słucha fal krótkich.) Jeśli to tylko kilka miesięcy, twoim urządzeniem może być po prostu przedpłacony smartfon podłączony do zewnętrznej baterii i upuszczony w umiarkowanie nieznanym miejscu. Na rynku jest już wiele zdalnych czujników opartych na komórkach, które automatycznie wykonują połączenie telefoniczne lub połączenie internetowe, gdy spełnione są pewne kryteria, więc byłoby to prawie niewykrywalne - dla operatora telefonii komórkowej wyglądałoby to jak kolejny te coraz bardziej wszechobecne urządzenia.

Urządzenie budzi się po stuleciu - wykryto zduplikowany adres IPv6, interfejs wyłączony ...
SEJPM
2015-05-21 01:46:20 UTC
view on stackexchange narkive permalink

Nie jestem do końca pewien, czy ten artykuł o szyfrowaniu z blokadą czasową został zainspirowany tą dyskusją, ale byłoby to najbardziej formalne rozwiązanie pytania „Jak zbudować szyfrowanie z blokadą czasową? ”, co jest przeformułowaniem„ Jak chronić dane, aby można je było odszyfrować dopiero po określonej dacie? ”

Ale teraz przejdźmy do szczegółów, jak to działa .

Zasadniczo konstruuje się zegar odniesienia przy użyciu obliczeń dostępnych publicznie (takich jak obliczenia Bitcoin). Tak więc, o ile rozumiem, zależy to od łańcucha bloków Bitcoin , aby osiągnąć określony rozmiar (rośnie co 10 minut, względnie dokładnie). W takiej sytuacji „szyfrowanie świadków” umożliwi każdemu odszyfrowanie danych (gdzie łańcuch bloków zawiera pewnego świadka, który jest dostępny tylko wtedy, gdy łańcuch osiągnie określony rozmiar). Ponieważ niemożliwe jest złamanie schematów szyfrowania świadka i bycie szybszym niż cała sieć bitcoin (działająca obecnie ponad 300PHash / s), jest mało prawdopodobne, aby osoba atakująca była w stanie uzyskać odszyfrowane dane ( który może być kluczem) przed wygaśnięciem blokady czasowej.

Można również zauważyć, że ten schemat nie wiąże się z wysokimi kosztami (podróże kosmiczne), nie wymaga zaufanej trzeciej strony (nie musisz ufać sieci Bitcoin), a strona szyfrująca nie musi być dostępna w czasie odszyfrowywania, a strony z wysokimi zasobami obliczeniowymi mają niewiele szanse na wcześniejsze poznanie sekretu .

Można również przeczytać ten artykuł, stosując podobne podejście i ograniczając bezpieczeństwo do podzbioru problemu, który uważa się za być trudne.

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

Zaszyfruj plik bardzo długim kluczem, podziel go na części i przekaż każdą część zaufanej osobie wraz z instrukcjami, aby nie oddawać wspomnianej części przed podaną datą. Możesz dodać trochę nadmiarowości, oddając każdą część większej liczbie osób, na wypadek gdyby jeden z nich miał zostać uderzony przez autobus.

Oczywiście sieć komputerów może to zrobić tak samo, jak ludzie. W rzeczywistości algorytm retargetowania trudności oparty na czasie w Bitcoinie, chociaż służy innemu celowi, opiera się na podobnych zasadach. Nie wiem jednak, czy rzeczywiście istnieje jakiś program do tego celu.

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

W artykule cytowanym w pytaniu (co jest bardzo interesujące, pomimo sporadycznej niezgrabnej gramatyki) przedstawiono hipotetyczne podejście, polegające na użyciu oprogramowania zawierającego zaszyfrowany ładunek, wyzwalającego jakąś zewnętrzną wartość, taką jak artykuł prasowy, i pozwolić ludziom na całym świecie uruchamiać go do czasu wykonania ładunku. Nie spełnia to wymogu „publicznie znanej daty / godziny”, ale przesłanka jest dobrym punktem wyjścia. Usługa rozproszona, podobnie jak TOR / Bitcoin, może być uruchamiana w trybie P2P przez wiele osób na całym świecie wyłącznie w celu utrzymania zależnych od czasu wersji kluczy. Jest to znane jako bizantyjska tolerancja błędów (inaczej problem bizantyjskich generałów, patrz http://en.wikipedia.org/wiki/Byzantine_fault_tolerance, aby uzyskać pełne wyjaśnienie), ale w tym przypadku chronione byłoby przedwczesne ujawnienie informacji, więc nie jest to aplikacja bezpośrednia, ale styczna, która wymagałaby nowego zestawu technik.

Ostrożne kodowanie można wykorzystać do stworzenia schematu, w którym każdy użytkownik posiada jeden malutki kawałek klucza, wielu użytkowników ma nadmiarowe kopie poszczególnych elementów, a istnieje silny sposób zapobiegania przedwczesnemu „zbieraniu”, w tym unikaniu złośliwego oprogramowania i obsłudze wielu platform (gdzie klucze są celowo dzielone równo między użytkowników korzystających Windows, IOS, Android, OS X, Linux itp.)

To prawie musiałoby działać jak odwrotność łańcucha bloków bitcoin, gdzie zamiast każdego użytkownika posiadającego możliwą do zweryfikowania kopię tego, co wydarzyło się w przeszłości, każdy użytkownik ma unikalny wycinek tego, co będzie się działo w przyszłości i tylko wtedy, gdy przyszłość zwraca się ku teraźniejszości, każdy blok jest wypuszczany na świat do konsumpcji. W tym przypadku można zastosować technikę cebulowania a la TOR, w której każdy fragment twojego tajnego klucza był wysyłany do zestawu użytkowników, transfigurowali go i wysyłali z zachowaniem tylko klucza tłumaczenia, a to kontynuowało N zaokrągla w górę. Każda warstwa mogłaby mieć swój własny losowy zegar, aby później przekazać materiał w dół, zbliżając się do źródła, w którym ostatni zegar odliczałby i wyzwalał zwolnienie kluczowych części, aby połączyć się w zestawie uzgodnionych partnerów i wysłać e-mailem, lub czegoś.

Jedynym brakującym elementem jest to, jak uniknąć masowej zmowy, takiej jak nagroda ustanowiona, aby zachęcić wystarczającą liczbę użytkowników do oddania kluczowego materiału w zamian za podział puli, ponieważ nie może należy założyć, że wielu z nich uważa, że ​​ich informacje zdeponowane mają wartość> 0, jeśli pozostaną nietknięte. Pożądany byłby sposób pełnego zaciemnienia materiału, tak aby każdy użytkownik miał jedną dużą porcję danych, nie wiedząc, które wycinki zdarzeń są pod jego opieką. To rzeczywiście interesujący problem.

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

Jak powiedzieli inni, nie można zapewnić odszyfrowania do określonej daty, ale przez określony wysiłek. Jeśli chodzi o algorytm jednego celu, wysiłek jest silnie powiązany z interesem stron próbujących go odblokować wcześniej, a zatem jest dość nieznany.

Więc najlepszym rozwiązaniem może być powiązanie układanki z dużo większym i obojętnym interesem . Najbardziej wykonalnym, który przyszedł mi do głowy w dzisiejszych czasach, jest łańcuch bloków Bitcoin. Ponieważ bitcoiny są rzeczywistością od kilku lat, a ich generowanie obejmuje dziś duże ilości sprzętu, mamy duże szanse, aby przewidzieć ich tempo generowania w rozsądnej perspektywie długoterminowej (może tygodni lub miesięcy).

Zastanawiam się, czy to może być zrobione. Potrzebne byłoby powiązanie między wygenerowanymi bitcoinami a potrzebnym kluczem. Nie możemy polegać na wygenerowaniu pojedynczego bitcoina, ale musimy użyć czegoś takiego jak małe n z poprzednio wybranej dużej ilości m możliwych bitcoinów, które zapewni odszyfrowanie. Jest to możliwe dzięki „tajnemu udostępnianiu” ( https://en.wikipedia.org/wiki/Secret_sharing). Ponieważ wartości hashe bitcoin zależą od wcześniej przeprowadzonych transakcji, skonstruowanie puzzli m , które pewnego dnia rozwiązałoby się za pomocą haszy bitcoinów, byłoby dość trudne.

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

Ostatecznie druga zasada termodynamiki staje na przeszkodzie. Spójrz na swój tekst jawny jako na system zamknięty; może tylko wzrosnąć w entropii.

Szyfrowanie informacji zwiększa jej entropię, ale posiadanie klucza to rekompensuje. Całkowita entropia klucza + zaszyfrowanego tekstu jest taka sama, jak entropia zwykłego tekstu.

Po zniszczeniu klucza całkowita entropia systemu wzrasta. Co oznacza, że ​​nigdy nie możesz wrócić (z wyjątkiem ogromnego wkładu energii poprzez moc obliczeniową brutalnej siły).

Oznacza to, że musisz zachować klucz; nie możesz go tymczasowo zniszczyć.

Oczywiście możesz ukryć klucz, zaszyfrować go ponownie, zachować u zaufanej osoby trzeciej itp. Jednak klucz zawsze musi być gdzieś .

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

Szyfruj za pomocą jednorazowego padu XOR i miej jakąś automatyzację do wysyłania szyfrowanego strumienia o wyznaczonej godzinie. Jednorazowe podkładki XOR są całkowicie odporne na ataki wzorcem, ponieważ nie ma wzoru.

Aby to się udało, musisz

  • stworzyć klucz samodzielnie i nie udostępniać go nikomu
  • build sabotaż- dowodowa automatyzacja terminowego dostarczania
  • ukrywa prawdziwy cel systemu czasowego dostarczania, upewniając się, że dobrze wykonuje on niezmiernie nudny, ale niezbędny cel infrastrukturalny, tak aby nikt nie próbował badać, odłączać, modyfikować lub użyj go ponownie
  • zniszcz wszystkie kopie podkładki XOR poza odpornym na manipulacje systemem dostarczania czasowego

Pamiętaj, że aby być naprawdę manipulowanym dowód, że musi reagować na manipulacje, bardzo dokładnie szyfrując pad XOR. Na szczęście, ponieważ pady XOR zawierają losowe dane, nie ma sposobu, aby stwierdzić, czy doszło do autodestrukcji, czy nie.

Możesz dodatkowo ukryć podkładkę XOR steganograficznie, aby powstrzymać ciekawskich przed zastanawianiem się, dlaczego ktokolwiek miałby ukrywać wiele pozornie przypadkowe dane.

Zdaję sobie sprawę, że w tym podejściu są elementy zabezpieczania przez zaciemnienie. To nieuniknione; gdybym wiedział o takim systemie i chciał go zaatakować, zacząłbym od pozbawienia go zasilania i wylutowania wszystkiego, co wyglądało jak pamięć masowa, abym mógł zbadać zawartość, nie pozwalając mu reagować na manipulacje. Nawet wtedy można by osadzić UPS.

Świadomy atak zależy od a priori wiedzy o systemie, począwszy od jego istnienia. Jeśli tylko nadawca wie o jego istnieniu, może to być solidne. Powszechną strategią jest unikanie konstruowania przez jedną ze stron fragmentu wystarczająco dużego, by miał spójny cel.

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

Korzystając z niezupełnie zaufanych źródeł, można wysłać klucz odszyfrowywania pocztą tradycyjną do zaufanej strony. To nie daje pełnego zaufania stronie, ponieważ nie może publikować wcześnie, ale nie może w ogóle publikować, więc aby zminimalizować ryzyko, można użyć wielu zaufanych źródeł.

Aby zwiększyć opóźnienie czasowe, możesz użyć serwis internetowy, w którym można poprosić ich o wysłanie pocztówki spoza kraju (ale to naraziłoby ją na ataki człowieka w środku), na przykład http://mijnkaart.bpost.be/fotokaarten-maken dla głośników holenderskich, ale jestem pewien, że podobne usługi istnieją gdzie indziej.

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

Działa to w momencie wywołania zdarzenia.

Stwórz automatyzację (zobacz odpowiedź Petera Wone), która sprawdzi, czy masz w nazwie stronę Wikipedii. i wyzwala, jeśli tak.

Jest to oczywiście bardzo wrażliwy na wyzwalacz & działa tylko wtedy, gdy jesteś nieznany w momencie tworzenia.

Możesz rozwiązać oba problemy, uwzględniając warunek, że pewne informacje o wydarzeniu zawarte są we wpisie w Wikipedii.

Jestem pewien, że korzystając z Google można znaleźć kilka innych ciekawych wyzwalaczy

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

Możliwe byłoby zbudowanie systemu opartego na łańcuchu bloków, który zapewni każdemu blokowi w przyszłości dodatkowy ładunek, który musi rozwiązać górnik tego bloku.

Każdy blok może utworzyć klucz prywatny dla klucza publicznego, który jest znany z góry. Swoją wiadomość szyfrujesz kluczem symetrycznym, a następnie szyfrujesz ten klucz znanymi kluczami publicznymi z następnych 10000 bloków, które zostaną wydobyte .

Jeśli sieć gromadzi więcej mocy obliczeniowej, może spowodować dodatkowe problemy numeryczne do wydobywanych bloków, aby utrzymać czas generowania bloku wynoszący średnio 10 minut.

Jeśli sieć straci moc obliczeniową Jednak pomyślne zaszyfrowanie pliku zajmie więcej czasu.

Sugerujesz więc utworzenie nowego altcoina (na już zatłoczonym rynku) tylko po to, aby przesunąć w czasie zwolnienie pliku? Nawet jeśli się złapie, jeśli plik jest cenny, zostanie odszyfrowany wcześniej, niż zamierzałeś. Osoby wydobywające monetę zaczęłyby od pierwszego bloku i pracowały do ​​przodu, podczas gdy każdy, kto chciałby plik, zaczynał od ostatniego bloku i pracował wstecz, wykonując tylko pracę nad złamaniem kluczy, nie czekając 10 minut między każdym z nich i niekoniecznie publikując ich wyniki. Kiedy dwie grupy „spotkają się”, cracker (y) będzie miał twój plik.
Nowe altcoiny potrzebują nowych funkcji, aby odróżnić się od istniejących monet. Sama ta funkcja może nie uzasadniać nowej monety, ale w połączeniu z innymi funkcjami może. Taka funkcja może być szczególnie cenna, jeśli blockchain zostanie wykorzystany jako publiczny magazyn informacji. Mogę sobie wyobrazić wstępne rejestrowanie badań naukowych na blockchainie. W takim przypadku naukowcy mogą chcieć mieć opóźnienie czasowe, zanim informacje zostaną upublicznione, ale jednocześnie informacje nie są wystarczająco cenne dla atakującego.
Jonathan
2015-05-14 02:25:16 UTC
view on stackexchange narkive permalink

Jedynym sposobem, w jaki możesz to zrobić, jest upewnienie się, że a) kontrolujesz kod, który wykonuje deszyfrowanie, oraz b) otrzymujesz datę z niezmiennego źródła. Na przykład, jeśli jako część odszyfrowania dołączysz wywołanie usługi sieciowej zegara atomowego (najlepiej zabezpieczonej, której nie można sfałszować). W tym momencie po prostu sprawdzasz datę i jeśli jest ona niższa od żądanej, nie zawracasz sobie głowy odszyfrowywaniem.

Inne odpowiedzi tutaj pokazują, że nie jest to jedyny sposób. Jeśli zachowasz klucz do daty, jak sugeruje jeden z nich, nie musisz kontrolować kodu deszyfrującego.
Sfałszowanie zegara lub innego zewnętrznego sygnału będzie albo łatwiejsze niż bezpośrednie złamanie szyfrowania, albo po prostu zmieni problem - jak zapobiec włamaniu się do „bezpiecznego” zegara przed określoną datą?
Niemożliwe do spreparowania będzie niemożliwe, ale możesz podejść nieco bliżej, korzystając z wielu wiarygodnych źródeł czasu. Użyj kilku niezawodnych serwerów NTP w różnych krajach (mogą być sfałszowane przez przekierowanie adresu IP) wraz z zegarem opartym na GPS (który może zostać sfałszowany przez kogoś, kto ma budżet na zbudowanie infrastruktury symulatora GPS).


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...