Pytanie:
Czy sam wybór algorytmu szyfrowania nie dodaje entropii?
Robert
2019-01-30 17:22:18 UTC
view on stackexchange narkive permalink

Załóżmy, że ktoś ma moje zaszyfrowane dane i chce je odszyfrować. Ludzie zawsze mówią o tym, jak długość klucza (np. 256 bitów) decyduje o entropii szyfrowania, co ma sens. Jeśli napastnik spróbuje wszystkich 2 256 możliwości, jego wspaniałe-wspaniałe-… -nuki-dzieci będą miały moje dane.

Ale co, jeśli przez wszystkie lata używał niewłaściwego algorytmu ? Czy sam wybór algorytmu nie dodaje również entropii, czy też błędnie to zakładam? Więc zamiast nazywać mój plik super_secret.aes256 nadałbym mu po prostu nazwę super_secret.rsa256 lub może nawet nie nadałbym mu nazwy kończącej się w ogóle?

Załóżmy, że istnieje 8 szyfrów, które możesz wybrać w 2019 roku, które mają 256-bitowe klucze i że atakujący nie miał możliwości spojrzenia na zaszyfrowany tekst i stwierdzenia, jakiego rodzaju algorytm został użyty, a następnie Twoim tajnym wyborem algorytmu jest dodanie log2(8) = 3 bity entropii.To pomijalny szum w porównaniu z 256 bitami klucza.
@MikeOunsworth Warto również wziąć pod uwagę, że zastosowanie niektórych szyfrów może potrwać kilka razy dłużej, ale tak naprawdę większość formatów szyfrowania wyraźnie określa, jaki szyfr i tak jest używany.
Czy nie mógłbyś użyć ataku typu side-channel, aby odkryć, czy był to algorytm klucza symetrycznego, czy klucza publicznego?
Jest jeden przypadek, w którym ten pomocny schemat szyfrowania jest tworzony przez ciebie i nigdy nie ujawniłeś projektu, chociaż jest to trudne do osiągnięcia.Niż to jest prawie niemożliwe do złamania.
@kelalaka, jeśli ty lub ja (lub ktokolwiek, kto ma mniej niż kilkadziesiąt lat w tej dziedzinie i ma liczne recenzje) wynaleźli nasz własny schemat szyfrowania, jest praktycznie pewne, że [byłby tak słaby] (https://crypto.stackexchange.com/q / 43272/17796) zostanie złamany na dziesiątki sposobów, które są szybsze niż brutalne.
@Matija Nalis, szyfrowanie to coś więcej niż tylko stosowanie szyfrów.Wymyślenie szyfru wymaga obszernych badań, obliczeń i wiedzy.„Wymyślanie własnego szyfrowania” oznacza myślenie o tym, jak połączyć istniejące narzędzia w celu zabezpieczenia komunikacji.Zawiera szczegółowe informacje, takie jak sposób wymiany kluczy, czy klucze mają okres ważności, kto w organizacji może certyfikować klucze, jakie szyfry mają być używane, co się stanie, jeśli usługi nie mogą sobie ufać…
@sleblanc Oczywiście, ale nawet jeśli używasz tylko znanych bezpiecznych szyfrów, istnieje [dużo] (https://en.wikipedia.org/wiki/HMAC#Design_principles) [z] (https://crypto.stackexchange.com/a / 205/17796) [pułapki] (https://research.swtch.com/openssl) dla ludzi niezbyt intensywnie w tej dziedzinie.(Również to pytanie dotyczyło szyfrów, a nie PKI lub innych problemów, które możesz mieć w świecie kryptowalut)
Wyszukaj [BassOmatic] (https://en.wikipedia.org/wiki/BassOmatic).
Siedem odpowiedzi:
John Deters
2019-01-30 20:05:41 UTC
view on stackexchange narkive permalink

Jeśli projektujesz kryptosystem, odpowiedź brzmi Nie . Zasada Kerckhoffsa mówi: „Kryptosystem powinien być bezpieczny, nawet jeśli wszystko w systemie, z wyjątkiem klucza, jest publicznie dostępne”. Przedstawione jako maksyma Shannona, oznacza to, że „należy projektować systemy przy założeniu, że wróg natychmiast się z nimi zapozna”.

Zakładając, że atakujący nie nauczy się twojego algorytmu, jest bezpieczeństwo poprzez zaciemnienie, podejście do bezpieczeństwa uważane za nieodpowiednie.

Poleganie na napastniku, że nie zna algorytmu, nie doda mu żadnej pracy, ponieważ według Kerckhoffa on lub ona o tym wie lub można się spodziewać, że się dowie. Jeśli nie dodaje niepewności, nie dodaje żadnej entropii. A ich możliwości nie są czymś, co można określić ilościowo.

W przypadku zagubionego kryptosystemu, jak opisujesz, zwykle jest wystarczająco dużo informacji historycznych lub statystycznych, aby określić naturę algorytmu (jeśli nie samego klucza). Ale nie możesz zaprojektować systemu przy założeniu, że zostanie utracony, gdy tylko zostanie użyty. To jest OpSec, a nie kryptografia.

EDYTUJ Komentarze wspominały o używaniu wyboru algorytmu jako części klucza. Problem z tym podejściem polega na tym, że wybór algorytmu musi być koniecznie określony przed odszyfrowaniem danych. Dokładnie tak działają obecnie protokoły, takie jak TLS.

Jeśli naprawdę chcesz mieszać razem algorytmy i używać współczynnika klucza do określania rzeczy, takich jak wybór S-box, itp., efektywnie tworzysz nowy pojedynczy algorytm (przyjmując wszystkie dobrze -znane ryzyko, które pociąga za sobą zmianę własnego algorytmu.) A jeśli utworzyłeś nowy algorytm, to wszystkie bity klucza są częścią tego obliczenia entropii. Ale jeśli możesz wskazać konkretne bity, które określają algorytm zamiast materiału klucza, nadal musisz traktować je jako bity protokołu i wykluczać.

Jeśli chodzi o tajność algorytmów, Twój protokół może być dziś tajny, ale jeśli jeden z Twoich agentów zostanie wykryty, a jego system zostanie skopiowany, nawet jeśli żaden klucz nie zostanie przejęty, stare wiadomości nie będą już używać tajnych algorytmów. Wszelka „entropia”, którą im przypisałeś, przepadła i możesz nawet o tym nie wiedzieć.

To nie jest bezpieczeństwo przez zapomnienie.To nie jest „poleganie na tajemnicy projektu lub implementacji jako głównej metody zapewniania bezpieczeństwa”.Możesz użyć tego samego rozumowania, aby argumentować, że założenie, że atakujący nie znajdzie Twojego klucza prywatnego, jest zabezpieczeniem przez niezrozumiałość.Nie ma sensu martwić się o entropię dodaną przez wybór algorytmu, ponieważ i tak można uzyskać wystarczającą entropię za pomocą klucza.
@FINDarkside "_Mógłbyś zastosować to samo rozumowanie ..._" Różnica polega na tym, że - przy odpowiednim zarządzaniu kluczami - osoba atakująca nigdy nie powinna być w stanie wypracować klucza prywatnego.Musisz jednak założyć, że mają możliwość odkrywania coraz więcej szczegółów dotyczących implementacji, na przykład poprzez inżynierię wsteczną kodu.
@FINDarkside, kwerent pyta, czy utajnienie implementacji dodaje entropię.Innymi słowy, pyta on konkretnie, czy bezpieczeństwo poprzez zaciemnienie powinno być uwzględnione w równaniu.Odpowiedź brzmi: przecząco, częściowo dlatego, że nie ma sposobu na ilościowe określenie możliwości atakującego w tym zakresie.Masz rację, że cała entropia musi pochodzić z klucza.
Potrzebna jest energia, aby uzyskać informacje o algorytmie, czy to inteligencji ludzkiej, inżynierii odwrotnej czy inżynierii społecznej, możesz uwzględnić oszacowanie tej energii ze średnią energią wymaganą do możliwego obejścia algorytmu, gdy już zdobędą tę wiedzę.I być może w pewnych sytuacjach można to wykorzystać do dokonania oceny bezpieczeństwa w organizacji.Z kontekstu informatycznego, jak zauważyłeś, * kryptografia * jest poza zakresem i nie można go obliczyć.
Miałem zamiar zwrócić uwagę na aspekt "bezpieczeństwa przez zaciemnienie", ale widzę, że już omówiłeś ten punkt.+1 ode mnie.
@TripeHound Zakładasz, że wybór algorytmu jest szczegółem implementacji, który można wykryć lub poddać inżynierii wstecznej.Równie dobrze może to być wejście do procesu szyfrowania / deszyfrowania (np. Użytkownik wybiera algorytm za każdym razem z listy).W takim przypadku wybór algorytmu staje się * częścią * klucza.EDYCJA: Właśnie zauważyłem, że faktycznie wysłałeś odpowiedź na ten temat.Zostawię ten komentarz, ponieważ ta odpowiedź nie uwzględniła tej możliwości, a IMO jest błędne, jak napisano.„Nie” powinno brzmieć „to zależy”.
@FINDarkside Problem polega na tym, że nie można chronić algorytmów w ten sam sposób, w jaki można chronić klucz.Klucz można pominąć w systemie (przechowywany oddzielnie lub nawet przechowywany tylko w pamięci osoby), ale algorytm nie może (zakładając, że nie pozwolimy użytkownikowi na przesłanie własnego za pomocą dowolnego kodu).Atakujący będzie miał co najmniej taki sam dostęp do algorytmu, jak uprawniony użytkownik, prawdopodobnie większy.
@jpmc26 Pytanie nie dotyczy żadnego działającego serwera ani systemu.Jeśli mam porcję danych, nie mogę po prostu „znaleźć” algorytmu, ponieważ Kerckhoff powiedział, że powinieneś założyć, że mogę.
@FINDarkside Legalni użytkownicy muszą mieć dostęp do algorytmu lub wiedzę o nim, niezależnie od tego, czy jest to system działający.Zasada Kerchoffa nie jest ostatecznym twierdzeniem, że atakujący zawsze pozna algorytm.Jest to praktyczna zasada, o której powinieneś założyć, że tak się stanie, ponieważ napastnicy są w praktyce ** znacznie bardziej zaradni i sprytni **, niż myślisz.Atakujący są * bardzo dobrzy * w pozyskiwaniu informacji, których nie potrafią, na przykład określaniu algorytmu na podstawie analizy zaszyfrowanych danych.Klucz można jednak zawsze oddzielić od algorytmu i zabezpieczyć.
@jpmc26 Wydaje się, że robisz z góry założenia dotyczące tego „systemu”.Istnieją scenariusze, w których algorytm jest tak samo „oddzielony” jak klucz prywatny, przy założeniu, że osoba atakująca nie została już infiltrowana w systemie, gdy plik był szyfrowany.Nie sądzę jednak, aby spierać się o to w żaden sposób.
@FINDarkside Bez pewnych podstawowych założeń nie możesz nawet prowadzić dyskusji.Wydaje mi się, że po prostu nie chcesz nawet o tym dyskutować, ale mimo to tutaj debatujesz.Są dane.Gdzieś mieszka.Algorytm jest wewnętrznie powiązany z zaszyfrowanymi danymi w sposób, w jaki klucz nie jest.Jest on powiązany na przykład z * formatem * wejścia / wyjścia, który jest znany napastnikowi, który uzyskał dane.
@FINDarkside, myślę, że widzę, skąd pochodzisz.Rozważasz scenariusz „zagubionej wiadomości”, taki, który nie ma kontekstu ani informacji na jego temat.Zastanawiasz się również nad zachowaniem tajemnicy, być może nawet w celu uniknięcia wykrycia.To są atrybuty OpSec i absolutnie mogą pomóc zwiększyć ogólne bezpieczeństwo.Ale ponieważ nie są one określone matematycznie, nie można ich uwzględnić w obliczeniach entropii.Pomyśl o tym w ten sposób: Twoje ogólne bezpieczeństwo obejmuje entropię algorytmu jako składnik, ale ogólne bezpieczeństwo nie jest mierzone entropią - jest mierzone ryzykiem.
@JohnDeters Ok, rozumiem, przepraszam za zamieszanie.
Wszystkie algorytmy @jpmc26 NSA Suite A są sklasyfikowane i, AFAIK, żaden z obecnych nie został ujawniony.Rozumiem, że często są one implementowane w oprogramowaniu, które jest zerowane pod kątem manipulacji.Jednym z aspektów jest to, że skutecznie unika kontroli akademickiej, więc uczelnie nie wykonują za nich pracy zagranicznego wywiadu.
@jpmc26 Myślę, że mówisz o jabłkach (algorytm), podczas gdy OP mówi o pomarańczach (* wybór * algorytmu).Implementacja musi zawierać rzeczywisty (-e) algorytm (y) (i dlatego są one wykrywane przez atakującego), ale * wybór * algorytmu, który jest używany, może pozostać w głowie użytkownika, podobnie jak klucz.
@FINDarkside W swoim cytacie pominąłeś koniec, który odnosi się do „systemu _ lub składnika systemu_”.Twierdzę, że jeśli twoją barierą wejścia do korzystania z kryptosystemu jest to, że ukryłeś używany algorytm, to zastosowałeś zabezpieczenia przez zaciemnienie dla tej części.Teraz twoje inne „komponenty” mogą nie być na to podatne, ale można przynajmniej ominąć jedną „warstwę” systemu, odkrywając fakt.
TripeHound
2019-01-30 20:49:59 UTC
view on stackexchange narkive permalink

W praktyce nie, jak zgrabnie wyjaśnia odpowiedź Jana.

Hipotetycznie, jeśli masz wystarczająco dużo bezpiecznych metod szyfrowania do wyboru, mógłby potencjalnie wybrać losowo jedną metodę i użyć jej do zaszyfrowania danych przy użyciu - na przykład - 256-bitowego klucza. Wybór używanego algorytmu musiałby zostać „dodany” do klucza i stać się częścią „ nieujawnionego tajemnicy ” (zwiększając łączną entropię do 259 bitów, jeśli było osiem algorytmów szyfrowania do wyboru między).

Problemy z zrobieniem tego obejmują:

  • Dodaje się tylko niewielką liczbę bitów: osiem algorytmów dodaje tylko trzy bity entropii. Dodanie ośmiu bitów (łącznie 264 bitów z 256-bitowym kluczem) wymagałoby 256 różnych algorytmów szyfrowania. Znalezienie wystarczająco bezpiecznych algorytmów, aby dokonać praktycznej różnicy, jest prawie na pewno znacznie trudniejsze niż zwykłe przedłużenie długości klucza pojedynczego algorytmu znanego atakującemu.

  • Musisz „rozszerzyć” klucz za pomocą wybranego algorytmu: oznacza to przekazanie wyboru „użytkownikowi”, który ma zostać „zapamiętany”, wraz z normalnym kluczem. To znacznie komplikuje proces zarządzania kluczami. Przechowywanie wyboru w zaszyfrowanych danych nie jest początkiem, ponieważ atakujący z „całkowitą wiedzą” byłby w stanie znaleźć informacje i wiedzieć, którego algorytmu użyć.

  • Jeśli dowolny z wybranych algorytmów pozostawia pewien rodzaj „odcisku palca”, który pozwala napastnikowi zidentyfikować użyty algorytm (lub przynajmniej zmniejszyć zakres możliwych algorytmów), a następnie (częściowo) zniweluje dodatkowe bity entropii.

Ogólnie rzecz biorąc, znacznie łatwiej jest przedłużyć długość używanego klucza i nie martwić się, że atakujący zna metodę szyfrowania.

Co gorsza, trzeba jakoś wymyślić bity używane do wyboru algorytmu.Jeśli ktoś ma algorytm, który może używać 256-bitowego klucza, a drugi naprawdę ma 256 bitów entropii, prawdopodobieństwo kompromisu z powodu niewystarczającej entropii będzie zasadniczo zerowe.Jeśli ktoś nie ma 256 bitów prawdziwej entropii, pobranie entropii, która mogłaby zostać użyta do wygenerowania klucza i użycie jej do wyboru algorytmu, niczego nie poprawi.
Przypuszczam, że jeśli chcesz być naprawdę pedantyczny w kwestii pytania, * mógłbyś * pozwolić użytkownikom na przesyłanie własnych algorytmów zamiast wybierania ich z predefiniowanej listy.Jednak wady związane z wykonaniem dowolnego kodu, fakt, że większość użytkowników nie wybrałaby bezpiecznego algorytmu, oraz zwiększona trudność w zarządzaniu tym przez użytkownika oczywiście przeważają nad wszelkimi korzyściami.
Jedną z interpretacji zasady Kerckhoffsa jest to, że informacja, która musi być utrzymywana w tajemnicy ** obejmuje ** klucz, o czym tutaj mówimy.Zatem wybór algorytmu ze stałego zestawu 8 wymaga dodatkowych 3 bitów w magazynie kluczy.Wybór algorytmu, który zakodowałeś, dodaje znacznie większą ilość do magazynu kluczy (przynajmniej entropia Shannona kodu).To nie jest zbyt dobry stosunek wartości do ceny.
Conor Mancone
2019-01-31 02:06:06 UTC
view on stackexchange narkive permalink

Odpowiedzi @John Deter i @TripeHound wyjaśniają bardzo dobrze, ale chciałem podać przykład, który umieściłby zasadę Kerckhoffsa w kontekście. Naturalne jest podejście do tych pytań z perspektywy zewnętrznego atakującego, ale nie jest to jedyny istotny model zagrożenia. W rzeczywistości mniej więcej połowa wszystkich naruszeń danych zaczyna się od wewnętrznych agentów (czyli pracowników, kontrahentów itp.), Z połączeniem zarówno przypadkowych, jak i celowych wycieków.

Bardziej realistyczne wektory zagrożeń

Posiadanie ukrytego algorytmu szyfrowania może pomóc w walce z napastnikiem z zewnątrz, jeśli nie może on łatwo wywnioskować, z jakiego systemu korzystałeś. Jednak nie zapewnia absolutnie żadnej dodatkowej ochrony przed intruzem wewnętrznym, który ma dostęp do Twojego kodu. Jako skrajny przykład, jeśli twój system przechowuje w bazie danych krytyczne dane osobowe (PII), ale zarówno poświadczenia dostępu do produkcyjnej bazy danych, algorytmy szyfrowania i klucze szyfrowania są przechowywane bezpośrednio w repozytorium kodu, to skutecznie dałeś każdemu, kto ma do nich dostęp do repozytorium kodu dostęp do wszystkich danych osobowych klientów.

Oczywiście nie chcesz tego robić, więc utrzymujesz systemy produkcyjne oddzielone od wszystkich, którzy oczekują administratorów, klucze szyfrujące przechowujesz w osobnym system zarządzania kluczami dostępny (w miarę możliwości) tylko dla aplikacji itp ... Twoi programiści wiedzą, jakie algorytmy szyfrowania są używane (bo widzą to w repozytorium kodu), ale nie mają dostępu do produkcyjnej bazy danych , a nawet gdyby uzyskali dostęp do odczytu bazy danych, nie mieliby kluczy do odszyfrowania danych, które tam są.

Stosowanie zasady Kerckhoffa

O to właśnie chodzi w zasadzie Kerckhoffsa - jedyną rzeczą, którą musisz zachować w tajemnicy, jest właściwy sekret (czyli Twój klucz szyfrowania). Wszystko inne może być znane wszystkim i nadal jesteś bezpieczny. Co jest dobre, ponieważ utrzymanie tylko jednego sekretu jest wystarczająco trudne. Próba opracowania systemu, który ukrywa nie tylko klucze, ale także algorytmy szyfrowania i inne szczegóły przed jak największą liczbą osób, jest nieco trudniejsza i bardziej podatna na awarie.

Krótko mówiąc, ludzie są źli w zachowanie tajemnicy. W rezultacie zaprojektowanie systemu tak, aby mieć mniej tajemnic do zachowania, w rzeczywistości sprawia, że ​​jesteś bardziej bezpieczny, nawet jeśli wydaje się to sprzeczne z intuicją. W końcu to, co sugerujesz, ma na pewnym poziomie sens: dlaczego mielibyśmy tylko szyfrować nasze dane? Ukryjmy też metodę szyfrowania i bądźmy wyjątkowo bezpieczni! Jednak w praktyce ukrycie większej liczby elementów daje większe pole do popełniania błędów i daje poczucie fałszywego bezpieczeństwa. Znacznie lepiej jest użyć skutecznej metody szyfrowania, która maksymalnie upraszcza zachowanie tajemnicy - ukryj klucz, a wiadomość będzie bezpieczna.

Christoph Burschka
2019-01-31 22:32:01 UTC
view on stackexchange narkive permalink

Podsumowując, gdyby istniały 2 ^ n schematów szyfrowania, które byłyby dokładnie tak samo trudne do złamania i miały taką samą przestrzeń możliwych kluczy, to z pewnością można zdefiniować nowy schemat szyfrowania jako „losowo wybierz jeden z tych 2 ^ n schematy ”i efektywnie rozważ te n bitów, które mają zostać dodane do klucza.

Ale w praktyce, nawet gdyby było to możliwe, jest to duża niepotrzebna złożoność, gdy zamiast tego możesz po prostu wybrać pojedynczy algorytm i nieco dłużej.

drjpizzle
2019-02-01 05:56:31 UTC
view on stackexchange narkive permalink

Myślę, że pytanie PO pokazuje wnikliwość, a odpowiedź brzmi, przynajmniej w teorii, tak. Coś tu jest. Myślę, że to pierwszy punkt, na który należy zwrócić uwagę. Podane odpowiedzi dotyczą głównie poglądu: w praktyce tak nie działa. Nie są one błędne, ale myślę, że brakuje im ważności / interesu punktu OP.

Sposób, w jaki to rozumiem: z teoretycznego punktu widzenia czarnej skrzynki wybór między dwoma systemami szyfrowania jest analogiczny do wyboru pierwszego bitu klucza. W rzeczywistości są to to samo (jeśli dodasz trochę z powrotem). W czarnej skrzynce naprawdę nie ma nic specjalnego w kluczu. Są po prostu dobrym sposobem na wyliczenie opcji, których transformacji szyfrowania chcesz użyć.

Aby to zobaczyć:

Powiedzmy, że tworzę nowy wariant AES128, nazwijmy go JES_0_128. Działa to następująco: dodaję kodowanie binarne 0 (w tym przypadku 128 zer) na początku dostarczonego klucza i używam tego w (standardowym) AES256. Następnie tworzę kolejny, o nazwie JES_1_128: kodowanie 1 itd. Aż do JES_ (cokolwiek 2 ^ 128 jest w bazie 10) _128. Wszystko to są doskonale poprawnymi algorytmami szyfrowania klucza 128-bitowego. Ale jeśli nie wiesz, który z nich ... to algorytm szyfrowania 256-bitowego klucza. AES256, aby być precyzyjnym. Co jest rzeczywiście dużo większą entropią.

Różnice, na które wskazują inne odpowiedzi, polegają na tym, że w praktyce klucz jest naprawdę dobrym sposobem wyboru, który z algorytmów szyfrowania 2 ^ 256 AES-256 ma być używany. elastyczny, dobrze zrozumiany i pozostawia generowanie i zaufanie do wspólnego sekretu użytkownikom. Po co używać czegoś innego?

Z drugiej strony wybranie jednej z niewielu rodzin 256-bitowych algorytmów szyfrowania do użycia i zakodowanie jej na stałe nie jest dobrym sposobem. Nawet w przypadku bardzo małego wzrostu rozmiaru klucza. Albo w ogóle. Równie dobrze możesz po prostu powiedzieć wszystkim. Z praktycznego punktu widzenia / pisania oprogramowania / typu oprogramowania nie jest wcale bezpieczne poleganie na tym, że jest to chronione przed intruzem. Jest wiele powodów. Nie tylko dlatego, że gdyby atakujący miał kopię, którą wybrałeś, łatwo byłoby ją przetestować. Ale to „tylko” względy praktyczne ...

Damon
2019-01-31 19:38:26 UTC
view on stackexchange narkive permalink

Jeśli po prostu zaszyfrujesz coś jednym algorytmem i udasz, że został użyty inny, zasada Kerckhoffa ma zastosowanie, jak wskazano w innych odpowiedziach, więc jest to trochę bezużyteczne, przynajmniej w przypadku atakującego z wiedzą o naszej implementacji. Nadal będzie „działać” przeciwko napastnikowi, który np. kradnie zaszyfrowany plik z OneDrive lub innego sklepu w chmurze, nie wiedząc nic o tym.

Jeśli potrzebujesz wyboru algorytmu szyfrowania, który ma być uwzględniony w procesie odszyfrowywania (tj. Twoje narzędzie wybiera jeden z kilku algorytmów, w zależności od tego, co wprowadzisz), efektywnie dodajesz bity do długości klucza. Zasada Kerckhoffa nie ma tutaj zastosowania. Trudno jest jednak dodać znaczną liczbę bitów - do wyboru byłoby wiele algorytmów - i nie ma to żadnego sensu (patrz ostatni akapit).

W każdym przypadku, cokolwiek co chcesz zrobić, jest praktycznie bezcelowe. Założenie, że czyjeś praprawnuki mogą mieć twoje dane, jeśli zainwestują kilka miliardów w sprzęt i rachunek za energię elektryczną, jest prawdopodobnie prawdziwe dla kluczy w zakresie 90-100 bitów. Chociaż realistycznie nikt (nawet NSA) by tego nie zrobił. Tego nie zdradza stosunek kosztów do korzyści. Inżynieria społeczna lub tortury, po których następuje morderstwo, to znacznie tańsze, szybsze i praktyczne podejście.

W przypadku czegokolwiek zauważalnie większego niż 110 bitów atak brutalnej siły nie jest realistyczny, nawet jeśli zaniedbujesz stosunek kosztów do korzyści. Powinieneś bardziej martwić się backdoorami wbudowanymi w AES, co jest bardziej prawdopodobne, niż widzisz jeden pojedynczy klucz 128-bitowy złamany przez brutalną siłę w ciągu twojego życia.

Teraz, Sam pomysł złamania 256-bitowego klucza za pomocą brutalnej siły jest po prostu śmieszny, a pomysł dodania do tego bitów jest bezsensowny, robi dokładnie zero różnicy. Niemożliwe nie ma nic lepszego niż „niemożliwe”.

Naprawdę nie rozumiem, co to dodaje do innych odpowiedzi, które zostały już udzielone.Czy mógłbyś to rozwinąć?
@TomK: Jeśli nic więcej, to nawet myślenie o brutalnym forsowaniu klucza 256-bitowego lub hipotetycznych konsekwencjach tego jest absurdalne (lub dodawanie do klucza 256-bitowego).Którego nikt inny w ogóle nie bierze pod uwagę.Myślenie o możliwości brutalnego forsowania 128-bitowego klucza jest już wystarczająco absurdalne, chociaż może być fizycznie możliwe.
benrg
2019-02-04 00:31:25 UTC
view on stackexchange narkive permalink

Myślę, że to dobry sposób, aby się temu przyjrzeć:

Masz sekret, który może być 256-bitowym kluczem lub hasłem, na podstawie którego uzyskasz ten klucz, lub jedno z tych plus inne informacje, takie jak użyty algorytm szyfrowania.

Osoba atakująca chce odgadnąć Twój sekret. Robią to, wypróbowując różne możliwości, aż znajdą tę właściwą lub zabraknie im czasu, pieniędzy lub motywacji.

Nie masz pojęcia, jakich możliwości próbują . W swoim pytaniu mówisz "co by było, gdyby przez wszystkie lata używał złego algorytmu?" a jedyną odpowiedzią na to jest "a co, jeśli nie był?" Nie masz nad tym żadnej kontroli. Gdybyś wiedział, jakie możliwości spróbuje atakujący, możesz po prostu wybrać jako swój sekret cokolwiek, czego nie ma na ich liście, a problem z bezpieczeństwem zostanie rozwiązany w trywialny sposób.

Jednak możesz z grubsza zrobić oszacuj, ile możliwości mogą wypróbować, zanim zabraknie im czasu i / lub pieniędzy, w oparciu o stan technologii komputerowej. Zakłada się, że nie mają potajemnie dostępu do technologii, której nie ma reszta świata, takich jak obliczenia kwantowe lub backdoor w AES - co jest prawdopodobnie bezpiecznym założeniem, ponieważ w takim przypadku mieliby lepsze rzeczy do zrobienia niż spróbuj złamać swoje hasło. (Por. Cut Lex Luthor a Check, chociaż zobacz także to obalenie.)

Możesz także udowodnić następujący wynik : jeśli wybierzesz swój sekret jednolicie i losowo (używając wysokiej jakości RNG) z n możliwości, a atakujący spróbuje k możliwości, bez względu na to, jakie to są , szansa, że ​​odgadną Twój sekret, jest co najwyżej k/n.

Fajne jest to, że n rośnie wykładniczo wraz z ilością informacji, które musisz przechowywać / zapamiętywać, podczas gdy k rośnie tylko liniowo wraz z ilością czasu / pieniędzy, które spędzają, więc nie jest trudno zarobić k / n bardzo małe.

Dlatego powinieneś wybrać swój sekret jednolicie, losowo, z szerokiego zestawu możliwości. Losowy 256-bitowy klucz symetryczny jest wybierany równomiernie z zestawu o rozmiarze 2 256 , który jest (znacznie większy niż) wystarczająco duży.

Możesz wybrać losowo z paczki (algorytm, klucz) również, ale jest to bezcelowe, ponieważ każdy pojedynczy algorytm oferuje już wiele opcji.

Możesz wybrać niejasny algorytm i mieć nadzieję, że atakujący go nie spróbuje, ale to nie jest wybór już losowo i dlatego nie możesz udowodnić , że to w ogóle pomaga. Gdyby nie było innych opcji, byłoby to lepsze niż nic, ale są inne opcje.

Jest to podstawowy powód, dla którego kryptolodzy radzą, aby traktować tylko klucz jako swój sekret: jest mnóstwo kluczy i klucze są najłatwiejszą rzeczą do wybrania na chybił trafił. Nie potrzebujesz niczego więcej.



ⓘ
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 4.0, w ramach której jest rozpowszechniana.
Loading...