Entropia: dwa krańce, których pożądamy

Jajecznica i porządek

Rano rozbijasz jajko na patelnię i mieszasz. Po minucie masz jajecznicę. Cofnąć tego się nie da: nikt jeszcze nie rozdzielił jajecznicy z powrotem na białko i żółtko. Fizycy mają na to słowo. Miarę nieporządku, który sam z siebie rośnie i którego nie da się cofnąć, nazywają entropią. Ściśle biorąc, fizyka mówi o całym układzie razem z otoczeniem, ale jako obraz codzienności ta myśl sprawdza się znakomicie.

Z tym rosnącym nieporządkiem zmagamy się każdego dnia. Sprzątamy mieszkanie, układamy kalendarz, ustalamy rozkłady jazdy i regulaminy. Lubimy, gdy świat jest przewidywalny: gdy pociąg odjeżdża o czasie, a przelew dochodzi tam, dokąd go wysłaliśmy. Duża część cywilizacji to właśnie sposoby na okiełznanie entropii.

A jednak ta sama cywilizacja potrzebuje też czegoś odwrotnego. Hasło do banku, klucz, który chroni połączenie z bankiem, wynik losowania na loterii: tu chcemy, żeby nikt niczego nie mógł przewidzieć. Im więcej nieporządku, tym lepiej. W tym artykule opowiadamy o tych dwóch krańcach i o dwóch głośnych wpadkach z 2026 roku, w których jeden kraniec po cichu zamienił się w drugi.

Entropia w informatyce

W informatyce słowo „entropia” znaczy coś trochę innego niż w fizyce, choć oba znaczenia są ze sobą spokrewnione. W 1948 roku amerykański matematyk Claude Shannon użył go jako miary niewiedzy, czyli tego, jak dużo nie wiemy o wyniku, zanim go poznamy. Tę niewiedzę mierzy się w bitach. Rzut monetą to jeden bit entropii, bo są dwie równie możliwe odpowiedzi. Dwa rzuty to dwa bity i cztery możliwości. Każdy kolejny bit, wylosowany niezależnie od poprzednich, podwaja liczbę możliwości.

Klucz, który chroni połączenie z bankiem, ma zwykle kilkaset bitów. Jeśli każdy z nich jest naprawdę losowy, liczba możliwości jest gigantyczna: przy 256 bitach ma 78 cyfr, a przy 384 bitach 116. Takiego klucza nie da się odgadnąć, nawet gdyby sprawdzać miliardy możliwości na sekundę przez cały dotychczasowy wiek Wszechświata.

Dwa krańce, których pożądamy

Na jednym krańcu jest entropia zerowa. Chcemy jej wszędzie tam, gdzie ten sam początek ma zawsze dawać ten sam wynik, a samo obliczenie nie może dokładać przypadku. Kalkulator, który raz na sto razy myli się w dodawaniu, byłby bezużyteczny. Funkcja skrótu SHA-256, która tworzy cyfrowy odcisk palca pliku albo tekstu, dla tych samych danych zawsze zwraca ten sam wynik. Podobnie z dowodem uczciwego losowania: każdy, kto go sprawdzi, musi otrzymać ten sam rezultat.

Na drugim krańcu jest entropia pełna. Chcemy jej tam, gdzie nikt nie może niczego przewidzieć: w kluczach, hasłach, frazach do portfeli kryptowalut i w wyniku losowania, zanim zostanie ogłoszony. Tu każdy bit ma być niewiadomą.

W dobrze zaprojektowanym systemie każdy z krańców ma swoje miejsce. Weźmy weryfikowalne losowanie na naszej stronie. Punktem wyjścia jest liczba losowa, którą co kilka sekund ogłasza drand, sieć serwerów prowadzonych przez wiele niezależnych instytucji. Dopóki większość uczestników sieci działa uczciwie, przed ogłoszeniem nie zna jej nikt: to kraniec pełnej entropii. Gdy liczba zostanie ogłoszona, droga od niej do wyniku jest już ściśle określona i każdy może ją powtórzyć: to kraniec zerowy. Kłopot zaczyna się wtedy, gdy tam, gdzie miała być pełna entropia, po cichu zostaje prawie zero. Zobaczmy, jak to wygląda w praktyce.

Klucz urzędu certyfikacji równy 4

Kiedy łączysz się z bankiem, przeglądarka sprawdza certyfikat strony. Wystawia go urząd certyfikacji, czyli firma, której przeglądarki ufają, że nie podpisze certyfikatu dla cudzej domeny. Całe to zaufanie opiera się na tajnym kluczu prywatnym urzędu. Kto go zdobędzie, może podpisać certyfikat dla dowolnej strony.

Indyjska firma eMudhra to urząd certyfikacji, któremu ufały Firefox, Chrome, Safari i Windows. W kwietniu 2025 roku utworzyła osiem nowych certyfikatów pośrednich, czyli takich, którymi na co dzień podpisuje się certyfikaty stron i programów. Do ich kluczy wybrano krzywą eliptyczną P-384, popularną metodę kryptograficzną, w której klucz prywatny to liczba mająca około 116 cyfr.

17 października 2026 roku jeden z badaczy zgłosił, że te klucze są słabe. Jak bardzo, pokazał potem autor jednej z analiz, sprawdzając je w najprostszy możliwy sposób. Każdy certyfikat zawiera jawny klucz publiczny, wyliczony z tajnego klucza prywatnego. Wyliczenie w tę stronę jest łatwe, w przeciwną praktycznie niemożliwe, ale tylko wtedy, gdy klucz prywatny jest wielką, losową liczbą. Autor analizy wziął więc klucze publiczne z certyfikatów i sprawdził, czy któryś nie powstał z klucza prywatnego równego 1, 2, 3 i tak dalej. Wszystkie osiem znalazł, zanim doszedł do 256, w mniej niż sekundę. Jeden z kluczy prywatnych był równy 4. Klucze sześciu z tych certyfikatów pozwalały wystawiać certyfikaty dla dowolnej strony, a dwóch pozostałych podpisywać programy.

Sprawdź to sam. Poniżej są prawdziwe klucze publiczne tych ośmiu certyfikatów.

Jak to możliwe? Wstępne wyjaśnienia firma opublikowała w systemie zgłoszeń Mozilli, twórcy Firefoksa. Według nich podczas zatwierdzonego odstępstwa od zwykłej procedury „błąd w kodzie” skryptu sprawił, że w urządzeniu chroniącym klucze obok właściwego powstał drugi, słaby zestaw. Słabe klucze miały podobne nazwy jak właściwe i przez pomyłkę trafiły do wniosków o certyfikaty. Pełny raport firma zapowiada na później. Uczestnicy dyskusji wątpią jednak, by certyfikowane urządzenie tego typu samo wygenerowało tak mały klucz.

Ostrzeżenie było wcześniej. Już w czerwcu 2025 roku ktoś zauważył, że nie zgadzają się podpisy na listach unieważnionych certyfikatów, które publikowała eMudhra. Takie listy wymieniają certyfikaty wycofane przed terminem. Dziś wiadomo, dlaczego podpisy nie pasowały: listy podpisywano właściwymi kluczami, a w certyfikatach były już słabe. Firma wyjaśniła to wtedy „niewłaściwą konfiguracją klucza”, podpisała listy ponownie, tym razem słabymi kluczami, i zamknęła sprawę. Słabość czekała na odkrycie jeszcze szesnaście miesięcy.

Przed skutkami uchroniła jawność. Przeglądarki przyjmują dziś tylko certyfikaty zapisane w publicznych rejestrach, nazywanych Certificate Transparency, a nie trafił tam ani jeden certyfikat strony podpisany którymś ze słabych kluczy. Kto chciałby użyć podrobionego certyfikatu, musiałby go więc najpierw zapisać w rejestrze, na oczach całego świata. Twórcy Chrome’a i Firefoksa zablokowali te klucze w ciągu kilku godzin od zgłoszenia. Google usuwa też z listy zaufanych certyfikat główny eMudhry, od którego pochodziły certyfikaty pośrednie.

Literówka, która zostawiła osiem sekretów

Druga historia dotyczy GoAhead, małego serwera WWW wbudowanego w routery, drukarki, kamery i sterowniki przemysłowe. To dzięki niemu ustawiasz router czy drukarkę, wpisując ich adres w przeglądarce. Według firmy FoxIO, która znalazła w nim opisany niżej błąd, GoAhead działa w setkach milionów urządzeń.

Kiedy przeglądarka łączy się z takim urządzeniem, obie strony muszą uzgodnić wspólny tajny klucz, choć ktoś może je podsłuchiwać. Służy do tego sprytna metoda, nazwana od nazwisk jej twórców metodą Diffiego-Hellmana. Każda strona losuje dużą tajną liczbę, wysyła drugiej wynik pewnego rachunku, a potem obie liczą ten sam wspólny sekret. Podsłuchujący widzi przesłane liczby, ale z nich sekretu nie odtworzy. Pod warunkiem, że wspólne parametry rachunku są dobrze dobrane. Najważniejszy z nich to jawna i bardzo duża liczba: obie strony dzielą przez nią każdy wynik i zachowują tylko resztę z dzielenia. Zwykle ma ona 2048 bitów.

W kodzie GoAhead, w wersji dla biblioteki szyfrującej Mbed TLS, ktoś przy przekazywaniu tej dużej liczby podał zły rozmiar. Liczba z 2048 bitów zajmuje 256 bajtów, bo bajt to 8 bitów, a w kodzie wpisano jeden bajt. Do obliczeń trafiał więc tylko pierwszy bajt tej liczby. Standardowa liczba zaczyna się od samych jedynek, więc ten bajt to 255. Błąd siedział w kodzie od 2018 roku. Wykryła go firma FoxIO i zgłosiła w kwietniu 2026 roku, a poprawka trafiła do wersji 6.1.1.

Przy liczbie 255 obie strony nadal losowały duże tajne liczby, a jednak wspólny sekret mógł mieć tylko osiem wartości. W rachunku podnosi się dwójkę do kolejnych potęg i bierze resztę z dzielenia przez 255. Już ósma potęga dwójki, 256, daje resztę 1, więc wyniki krążą w kółko po ośmiu wartościach. Badacze odszyfrowali nagrane połączenie po pięciu próbach. Zobacz, dlaczego.

Skala była mniejsza, niż sugerowały nagłówki. Błąd dotyczył tylko jednego sposobu uzgadniania klucza, w starszej wersji protokołu TLS 1.2, i tylko z biblioteką Mbed TLS. Programy korzystające z popularnej biblioteki OpenSSL od razu odrzucały takie połączenie, bo biblioteka ma blokadę zbyt małych liczb. Mimo to lekcja jest podobna jak przy eMudhrze, gdzie według wstępnych wyjaśnień firmy właściwe klucze też istniały: porządna losowość była pod ręką, a zginęła po drodze, przez błąd w jednym przeoczonym miejscu.

Takie historie nie są nowe. W 2008 roku okazało się, że OpenSSL w systemie Debian przez ponad półtora roku tworzył klucze, których było tylko około 32 tysięcy dla każdego rodzaju i długości klucza oraz typu procesora. Podobnie zawodziły portfele kryptowalut, o czym piszemy w artykule o słabych kluczach w portfelach.

Przeprowadzka z jednego krańca na drugi

Czasem najlepiej przenieść coś z krańca na kraniec. Przy podpisie cyfrowym w bitcoinie i wielu innych systemach trzeba było kiedyś za każdym razem wylosować świeżą, jednorazową liczbę, nazywaną nonce. Gdy wadliwy generator wylosował tę samą liczbę przy dwóch różnych transakcjach, z tych dwóch podpisów dało się wyliczyć klucz prywatny. Tak w 2013 roku tracili pieniądze użytkownicy portfeli na telefonach z Androidem.

Rozwiązanie opisuje standard RFC 6979. Nonce nie jest już losowany, tylko wyliczany z tajnego klucza i podpisywanej wiadomości. Trafił więc na kraniec zerowy: dla tych samych danych zawsze wychodzi ten sam. Dla kogoś, kto nie zna klucza, pozostaje jednak tak samo nieprzewidywalny jak liczba losowa. Wadliwy generator przestaje mieć w tym miejscu cokolwiek do zepsucia. Sam klucz prywatny trzeba oczywiście nadal wylosować porządnie.

Jak pilnować obu krańców

Z tych historii wynika kilka prostych zasad dla twórców systemów:

• Długość nie jest siłą. Klucz z 384 bitów może mieć tylko 8 bitów entropii, a liczba z 2048 bitów może się skurczyć do jednego bajtu. Liczy się to, ile możliwości naprawdę zostało.
• Lepiej przerwać, niż działać dalej. OpenSSL odrzucił zbyt małą liczbę, a dzięki temu jego użytkownicy byli bezpieczni. GoAhead przepuszczał zbyt małą liczbę bez słowa.
• Trzeba sprawdzać, co naprawdę trafiło na miejsce. Gdyby ktoś w 2025 roku porównał klucz w certyfikacie z kluczem, który miał tam trafić, niezgodność, a za nią słabość, mogła wyjść na jaw szesnaście miesięcy wcześniej.
• Nie wolno lekceważyć dziwnych sygnałów. Niezgodne podpisy to nie usterka konfiguracji do szybkiego załatania, tylko znak, że coś jest głębiej nie tak.
• Przejrzystość chroni. Publiczne rejestry certyfikatów sprawiły, że nawet zepsuty urząd certyfikacji nie mógł niepostrzeżenie podrobić strony.

Co to znaczy dla Ciebie

Na błędy w kodzie serwisów i urządzeń nie masz wpływu. Możesz jednak zadbać o swój kraniec pełnej entropii i ograniczyć skutki cudzych pomyłek. Używaj losowego hasła, innego w każdym serwisie, i tam, gdzie się da, włącz logowanie dwuetapowe, na przykład z kodem z aplikacji. Frazę do portfela kryptowalut wylosuj na własnym urządzeniu i nie używaj takiej, którą ktoś przygotował za Ciebie. Instaluj aktualizacje routerów i drukarek, bo tylko w ten sposób trafiają do nich poprawki takie jak ta w GoAhead.

Nasz generator haseł stara się pilnować obu krańców. Hasło losuje z kryptograficznego generatora przeglądarki i przed każdym losowaniem sprawdza, czy funkcja losująca nie wygląda na podmienioną przez skrypt albo rozszerzenie i czy daje sensowne wyniki. Dobrze ukrytej podmiany żadna strona nie wykryje, ale prostą i niedbałą tak. Pokazaną siłę hasła liczy z tego, jak hasło zostało wylosowane, a nie z tego, jak wygląda. A droga od losowości do hasła jest ściśle określona, więc da się ją sprawdzić w kodzie i testach.

Źródła: Mozilla, zgłoszenie 2083449 (eMudhra), fenko.nz, „eMudhra’s CA Private Keys Were Single Bytes”, FoxIO, „Three TLS Bugs in GoAhead”, GoAhead 6.1.1, Debian DSA-1571-1 (2008), RFC 6979, bitcoin.org, alert z 11.08.2013, C. E. Shannon, „A Mathematical Theory of Communication” (1948). Klucze publiczne eMudhry pochodzą z certyfikatów w rejestrze crt.sh.