Udostępnienie dowolnej części klucza prywatnego sprawia, że ​​jest on mniej bezpieczny, przynajmniej w minimalnym stopniu, po prostu dlatego, że zapewnia atakującemu mniejszą potencjalną przestrzeń na klucz do zbadania.

Nie udaje mi się aby zrozumieć, co chcesz osiągnąć. Jedyną rzeczą, jaką dwie osoby muszą zrobić, aby sprawdzić, czy posiadają te same informacje, jest wymiana hasha.

Jeśli projektujesz protokół i obawiasz się ataków typu replay, możesz się przed nim chronić, wykonując odpowiedź na wezwanie za pomocą HMAC.

Edytuj :

Jak sugerowano w komentarzach i wyjaśniono w wnikliwej odpowiedzi DW, muszę podkreślić, że wpływ na bezpieczeństwo twojego klucza prywatnego będzie zależeć DUŻO od tego, jakiego dokładnie algorytmu używają. W najgorszym przypadku ujawnienie tylko niewielkiej części klucza prywatnego całkowicie naruszy bezpieczeństwo tego klucza.

Ujawnienie części klucza prywatnego może być katastrofalne w przypadku niektórych asymetrycznych (klucza publicznego) kryptosystemów. Dokładny poziom ryzyka zależy od tego, jakiego dokładnie kryptosystemu używasz. Kilka przykładów:

• Jeśli używasz RSA z e = 3 dla klucza publicznego, to ujawnienie 1/4 klucza prywatnego (niskie 1/4 bitu d) jest wystarczy, aby osoba atakująca zrekonstruowała cały klucz prywatny. Na przykład, jeśli używasz 2048-bitowego RSA i ujawnisz 512 najmniej znaczących bitów klucza prywatnego, osoba atakująca może odzyskać resztę twojego klucza prywatnego. Ten wynik jest wynikiem Boneh, Durfee i Frankel. Istnieją inne podobne wyniki w literaturze (np. Dotyczące najbardziej znaczących bitów, losowego podzbioru bitów itp.).

• W przypadku DSA, jeśli kilka bitów jest wyciekły z nonce używanego w każdym podpisie (dla różnych podpisów), to wystarczy, aby odzyskać klucz prywatny. Na przykład, jeśli możesz zaobserwować 5 bitów tajnego numeru jednorazowego, który został użyty w każdym z 4000 sygnatur, wystarczy to do odzyskania 384-bitowego klucza prywatnego ECDSA. Nie jest to dokładnie ujawnienie klucza prywatnego (to ujawnienie innej tajnej wartości wygenerowanej podczas podpisywania), ale jest podobnie.

Zdaję sobie sprawę, że inne odpowiedzi mówią, że to żaden problem. Te odpowiedzi mogą zakładać, że używasz kryptosystemu z kluczem symetrycznym. W przypadku większości systemów kryptograficznych z kluczem symetrycznym, jeśli ujawnisz część klucza, ale jego wystarczająca część pozostanie nieujawniona, prawdopodobnie nadal będą bezpieczne. Jeśli chodzi o asymetryczne kryptosystemy, jest inaczej. Inne odpowiedzi wydają się zakładać, że brutalna siła (wyczerpujące wypróbowanie wszystkich możliwych kluczy prywatnych) jest najlepszym możliwym atakiem na kryptosystem. W przypadku wielu asymetrycznych kryptosystemów to założenie nie jest dokładne.

O ile szybciej osoba atakująca może złamać klucz przy tych 8 znakach?

Trudno odpowiedzieć, nie wiedząc, o jakim kluczu mówimy i jakiego algorytmu używa z.

W przypadku szyfrowania symetrycznego, w którym klucz jest całkowicie losowy (zrozum, że każdy bit ma równy udział w globalnej niepewności klucza), zależy to głównie od tego, co "1 znak" reprezentuje w kategoriach danych binarnych. Ogólnie rzecz biorąc, ujawniając n bitów , skutecznie redukujesz liczbę możliwych kluczy o współczynnik co najmniej 2 ^ n .

• W przypadku binarnej reprezentacji tekstowej, w której 1 znak = (0 lub 1) = 1 bit : 8 znaków oznacza współczynnik redukcji 2 ^ 8 = 256 .
• W przypadku reprezentacji szesnastkowej, gdzie 1 znak = 4 bity : 8 znaków oznacza współczynnik redukcji 2 ^ 32 = 4294967296 .
• W przypadku reprezentacji base64, gdzie 1 znak = 6 bitów : 8 znaków oznacza współczynnik redukcji 2 ^ 48 = 281474976710656 .

Które - w zależności od ilości ujawnionych informacji - mogą (lub nie) być wykorzystane jako dźwignia do złamania klucza w zależności od możliwych (obecnych lub przyszłych) słabości twojego algorytm szyfrowania.

Należy również zauważyć, że w przypadku szyfrowania asymetrycznego, w którym klucz nie jest całkowicie losowy (np. moduł czynnika pierwszego i wykładnik w RSA), ujawnienie n bitów może faktycznie ujawnić dużo bardziej użytecznych informacji i może prowadzić do katastrofalnej utraty bezpieczeństwa.

Ale prawdziwe pytanie brzmi:

Dlaczego ktokolwiek miałby kiedykolwiek to robić?

Nie tylko ta metoda stwarza potencjalne bezpieczeństwo wada, wydaje się, że niezawodność nie pasuje do twojego celu, a co z pozostałymi 248 bitami?

Metoda, którą opisujesz, to po prostu bardzo trywialna funkcja skrótu, która jest całkowicie ciągła (bardzo zła dla sprawdzania integralności) i częściowo odwracalna (bardzo zła ze względów bezpieczeństwa).

Jeśli naprawdę musisz to zrobić, użyj bezpiecznej i powszechnie dostępnej kryptograficznej funkcji skrótu, takiej jak SHA-256 , która wygeneruje znacznie bardziej bezpieczny skrót (praktycznie nieodwracalne i wymagające dużej mocy obliczeniowej) i znacznie bardziej odporne na kolizje niż „pierwsze 8 znaków”.

Jeśli używasz szyfrowania asymetrycznego, nigdy nie powinieneś potrzebować aby udostępnić jakąkolwiek część (nawet skrót) klucza prywatnego, użyj zamiast tego klucza publicznego .

Powiedziałbym, że waha się od „nie krytyczne, ale trochę głupie” do „katastrofalne”, w zależności od tego, co oznacza „8 znaków” i w zależności od używanych algorytmów.

Jeśli ktoś czyta „ 8 znaków "tak, jak to jest dosłownie, 64 bity, następnie zmniejszasz rozmiar klucza o 64 bity (jest nieco mniej drastyczny, jeśli przyjmie się" char "jako znak zakodowany w base-64, wtedy będzie to tylko 48 bitów).

Zakładając, że „klucz prywatny” w rzeczywistości odnosi się do algorytmu symetrycznego (mało prawdopodobne?), jest to prawdopodobnie tolerowane, ponieważ 192 bity są daleko poza możliwościami brutalnej siły. Ale z drugiej strony, po co w ogóle używać 256-bitowego klucza?

Przy założeniu, że „klucz prywatny, 256 bitów” oznacza, że ​​używasz pewnego rodzaju kryptografii krzywej eliptycznej (w przypadku szyfrów symetrycznych określenie „prywatny” niewiele sens, ponieważ wszystkie klucze są prywatne, a dla RSA i innych. 256 bitów jest zdecydowanie za małe, aby były użyteczne), obniżasz poziom bezpieczeństwa z nieco poniżej 128 bitów (co jest obecnie niewykonalne) do nieco mniej niż 96 bitów. Co jest ... no cóż, nie do końca możliwe, ale prawie. Biorąc pod uwagę, że obliczenia kwantowe jeszcze nie istnieją, ale są w drodze, „nie całkiem, ale prawie” jest troche katastrofalne.
W końcu to, co się planuje, to najgorszy przypadek, a nie najlepszy przypadek .

Jest to katastrofalne tym bardziej, że robienie tego jest absolutnie, w 100% niepotrzebne.

Jeśli dwie strony mają wspólny tajny klucz, jedna bardzo oczywista metoda upewnienia się, że jest to ten sam klucz polegałoby na zaszyfrowaniu wystarczająco długiego (dłuższego niż wyjście hash) losowego wzorca bitowego, pozwoleniu drugiej stronie odszyfrować wzorzec bitowy i odesłaniu bezpiecznego skrótu (powiedzmy SHA-256, SHA3, cokolwiek) wzorca bitowego.
Które pierwsza partia może trywialnie porównać z wynikiem obliczenia skrótu na oryginalnym losowym wzorze.

W żadnym momencie nie jest przesyłany klucz prywatny (ani jego część), ani nawet skrót tego klucza (co może być bardzo mało prawdopodobne, ale możliwe, że zostanie odwrócone lub stanowić wskazówkę co do jego części), a ponieważ tam mają więcej losowych bitów wejściowych niż wyjściowych, niemożliwe jest określenie oryginalnego wzorca bitowego, który został zaszyfrowany z wartości skrótu i ​​użycie go do uzyskania kąta w szyfrowaniu.

Atakujący widzi tylko losowy wzorzec bitowy, dla którego musi znać (nieznany) klucz, aby uzyskać oryginał, oraz skrót innego nieznanego wzorca bitowego, który może być jednym z wielu wzorców bitowych (bez możliwości ustalenia, który).

Inni już odpowiedzieli, ile informacji wyciekło, a co za tym idzie, o ile entropia jest obniżona dla atakującego; a główny punkt, który należy porównać (publicznie) został również odnotowany.

Jednak zakłada się, że dwie osoby, które chcą porównać klucze, ufają sobie. Jeśli nie ufają sobie nawzajem, problem polega na tym, że jeśli A wysyła hash (K) do B, B może wiedzieć, że A ma takie samo lub inne K niż B, ale może oszukiwać i odesłać ten sam hash, błędne myślenie A, że B jest również w posiadaniu tego samego klucza.

Rozwiązaniem tego problemu jest to, że A wysyła hash (K) do B i oczekuje, że B wyśle ​​hash (nie K) do A , gdzie nie K jest odwróconą bitowo wartością K. B może wysłać ten hash do A tylko wtedy, gdy naprawdę posiada K.

UWAGA Poniższe zakłada liniowe przyspieszenie (takie, jakie można uzyskać w ataku brutalnej siły) - przyspieszenie może być DOSKONAŁE WIĘCEJ, w zależności od algorytmu.

Bardzo trudno zrozumieć duże liczby - nawet ja byłem zaskoczony, gdy nadeszła odpowiedź. Oto sposób myślenia o tym:

Jeśli bez żadnych informacji złamanie klucza zajęłoby 13,8 miliarda lat (dotychczasowy wiek Wszechświata), przy pomocy 8 znaków binarnych, zajęłoby to tylko 0,023 sekundy.

To jest: 13,8 miliarda lat / 2 ^{(bits_per_symbol * number_of_symbols)} .

Ty powiedział, że liczba symboli to „8 znaków”, a ja zakładam binarny, który ma 8 bitów na symbol. więc: 13,8 miliarda lat / 2 ^{(8 * 8)}

Jeśli są zakodowane uuencod lub base64, będą miały 6 bitów na symbol, więc zajęłoby im to 25 minut na przepracowanie pozostałych kombinacji.

Te proporcje dotyczą tylko liczby ujawnionych bitów i są niezależne od długości klucza (tylko że złamanie klucza zajęłoby 13,8 miliarda lat ).

Cały sens kryptografii klucza publicznego polega na tym, że NIGDY NIGDY nie musisz udostępniać klucza prywatnego. Każdy klucz prywatny powinien istnieć tylko w jednym miejscu i nigdy nie przechodzić przez sieć. Wysyłanie kluczy jest sprzeczne z samą zasadą kryptografii klucza publicznego. NIGDY nie ma potrzeby wysyłania kluczy prywatnych, częściowo lub w inny sposób.

Jeśli chcesz, aby dwa (lub więcej) różne urządzenia mogły zdekodować tę samą wiadomość, poproś każde z nich o utworzenie własnego klucza prywatnego, wyślij klucz publiczny (bezpiecznie !!), a następnie zaszyfruj wiadomość oboma kluczami. Zwykle w przypadku PKC długie wiadomości są szyfrowane przy użyciu szyfrowania symetrycznego z losowym kluczem, a następnie klucz jest szyfrowany za pomocą PKC i wysyłany wraz z wiadomością; możesz łatwo zaszyfrować losowy klucz wieloma kluczami publicznymi i wysłać je wszystkie z tą samą wiadomością.

Jeśli chcesz tylko pokazać, że masz klucz prywatny, możesz wykonać następujące czynności:

Poproś osobę, której chcesz to udowodnić, o podanie losowej wartości („nonce”) . Dodaj własną wartość losową, zaszyfruj ją i podpisz skrót. Odeślij swoją losową wartość i podpis z powrotem.

Twój odpowiednik weźmie następnie wysłaną przez siebie wartość jednorazową oraz losową wartość, zaszyfruje ją i sprawdzi podpis z Twoim kluczem publicznym.

Dołączenie losowej wartości od nadawcy dowodzi, że nie wybrałeś tylko wartości, która została wcześniej podpisana przez prawdziwego właściciela.

W ŻADNYCH OKOLICZNOŚCIACH NIE WOLNO przyjmować czegoś wysłanego przez kogoś innego i podpisanie bez żadnych zmian. Mogą wysłać Ci odcisk palca pisanego przez siebie dokumentu, a Ty skutecznie go podpiszesz.

Jeśli Alicja i Bob podejrzewają, że mają ten sam klucz prywatny, to dlaczego nie:

1. Alicja generuje jednorazowy X.
2. Alicja szyfruje X dla siebie - Y.
3. Alicja wysyła X, Y do Boba.
4. Jeśli Alicja i Bob naprawdę mają ten sam klucz prywatny, to kiedy Bob odszyfruje Y, otrzyma X. Teraz Bob wie, że Alicja udostępnia jego klucz prywatny.
5. Bob robi to samo w odwrotnej kolejności. Teraz Alicja wie, że Bob udostępnia swój klucz prywatny.

Nie jestem ekspertem w dziedzinie kryptografii. Czy coś mi brakuje?

Myślę, że powyższe odpowiedzi zaspokoją ich pytanie bez ujawniania ich tajemnic. Ewa też nie będzie znała odpowiedzi na to pytanie.