Kryptografowie toczą wojnę słów wokół raportów błędów RustSec i następującej blokady

W świecie bezpieczeństwa oprogramowania konflikty między badaczami a opiekunami projektów to norma, ale rzadko przybierają tak dramatyczne formy jak spór, który rozgorzał między kryptografem Nadimem Kobeissim a zespołem RustSec. Od lutego 2026 roku kryptograf próbuje opublikować raporty o krytycznych lukach bezpieczeństwa w bibliotekach kryptograficznych Rusta, ale zamiast wsparcia napotyka zamknięte drzwi, ignorowanie i ostatecznie ban z kanałów bezpieczeństwa projektu. To nie jest zwykły spór o semantykę podatności – to przypadek, który obnażył fundamentalne problemy w sposobie, w jaki społeczność open source zarządza bezpieczeństwem i konfliktami.

Historia zaczęła się niewinnie, z raportu o błędzie w bibliotece libcrux-ml-dsa. Jednak to, co mogło być zwykłą procedurą naprawy luki bezpieczeństwa, zamieniło się w wojnę słów między doświadczonym kryptografem a zespołem utrzymującym bazę doradztwa bezpieczeństwa. Kobeissi twierdzi, że odkrył trzynaście podatności w bibliotekach kryptograficznych, z których dwie są na tyle krytyczne, że wymagają natychmiastowego powiadomienia publiczności. Tymczasem utrzymujący RustSec twierdzą, że jego raporty są przesadzone, a jego podejście do problemu – agresywne i nieproporcjonalne.

To, co dzieje się w Rust, ma znaczenie dla całego ekosystemu bezpieczeństwa oprogramowania. Język Rust zdobył sobie reputację dzięki gwarancjom bezpieczeństwa pamięci i rosnącej adopcji w krytycznych projektach, od Linuksa po Signal. Jeśli system obsługi podatności w jego ekosystemie zawodzi, konsekwencje mogą być poważne dla milionów użytkowników.

Nonce-reuse i pełne odszyfrowanie – o co właściwie chodzi

Aby zrozumieć skalę sporu, trzeba najpierw przeanalizować, o jakie podatności tu chodzi. Kobeissi twierdzi, że odkrył lukę związaną z ponownym użyciem nonce'a w bibliotece HPKE-rs (Hybrid Public Key Encryption). To nie jest abstrakcyjny błąd teoretyczny – to podatność, która w praktyce umożliwia pełne odzyskanie tekstu jawnego i fałszowanie wiadomości.

Jak to działa? W szyfrowaniu AES-GCM nonce (liczba używana tylko raz) jest kluczowy. Jeśli ten sam nonce zostanie użyty dwukrotnie z tym samym kluczem, całe bezpieczeństwo szyfrowania się wali. Atakujący może nie tylko odczytać zaszyfrowane wiadomości, ale także stworzyć fałszywe wiadomości, które będą wyglądać na autentyczne. To nie jest teoretyczna słabość – to praktyczna ścieżka ataku.

Druga podatność, którą Kobeissi wskazuje, to atak typu denial of service polegający na pełnym odzyskaniu klucza po 2^32 szyfrowaniach. Dla wielu aplikacji to może brzmieć jak wystarczająco dużo, aby uniknąć problemu. Ale Kobeissi słusznie zwraca uwagę, że Signal, OpenMLS, Google i Linux kernel to właśnie aplikacje, które mogą potencjalnie osiągnąć tę liczbę operacji.

Filippo Valsorda, znany kryptograf, który sam zgłosił pierwotny błąd w libcrux-ml-dsa, ma jednak inną perspektywę. Twierdzi, że podatność nonce-reuse nie jest wcale tak krytyczna, jak ją przedstawia Kobeissi. Według Valsorda, luka wpływa tylko na aplikacje, które wykonują więcej niż cztery miliardy szyfrowania z tym samym ustawieniem HPKE – a przeciętna aplikacja robi jedno. To istotne rozróżnienie, ale Kobeissi słusznie argumentuje, że Signal i inne aplikacje mogą rzeczywiście osiągnąć te progi.

Cryspen, formalna weryfikacja i obietnice, które się nie sprawdziły

Centrum konfliktu jest Cryspen, paryska firma zajmująca się oprogramowaniem kryptograficznym, która utrzymuje bibliotekę libcrux. Firma ta specjalizuje się w formalnej weryfikacji – matematycznym dowodem, że kod działa dokładnie tak, jak powinien. To brzmi imponująco, ale praktyka pokazuje, że nawet formalnie zweryfikowany kod może zawierać błędy, jeśli specyfikacja samych wymogów jest nieprawidłowa.

Kobeissi w swoim poście z 5 lutego oskarżył Cryspen o cichy fix błędu bez publicznego ujawnienia czy oświadczenia o bezpieczeństwie. Dla firmy, która buduje swoją reputację na gwarancjach formalnej weryfikacji, to było szczególnie bolesne. Jak można twierdzić, że kod jest formalnie zweryfikowany, jeśli zawiera krytyczne błędy kryptograficzne?

Karthikeyan Bhargavan, współzałożyciel Cryspen i główny naukowiec, pod którym Kobeissi studiował jako doktorant, przyznał: "nie radziliśmy sobie dobrze z tymi doradcami". To jest ważne przyznanie – pokazuje, że nawet firmy zajmujące się bezpieczeństwem mogą zawodzić w podstawowych procesach komunikacji i transparentności.

Jednak Cryspen w swoim oficjalnym oświadczeniu twierdzi, że błędy znalezione przez Kobeissiego były w oprogramowaniu pre-release i zostały naprawione w ciągu tygodnia. To rozróżnienie ma znaczenie – błędy w wersji roboczej nie są tym samym co błędy w kodzie produkcyjnym. Ale jeśli kod pre-release był wystarczająco zaawansowany, aby być testowanym i integrowanym z innymi projektami, to czy naprawdę można go nazwać "pre-release"?

RustSec, brak przejrzystości i zamknięte drzwi

Tutaj sprawa staje się jeszcze bardziej skomplikowana. Kobeissi twierdzi, że zespół RustSec – baza danych doradztwa bezpieczeństwa dla ekosystemu Rusta – zamknął jego pull requesty bez uzasadnienia technicznego, cicho go zablokował w organizacji GitHub, a następnie zamknął jego oczekujący pull request po odkryciu, że został zablokowany.

W świecie open source takie działania są nie do zaakceptowania. Jeśli utrzymujący projekt zamyka raporty o podatnościach bez wyjaśnienia, to nie tylko szkodzi bezpieczeństwu – to również podważa zaufanie do całego systemu. Jak inni badacze mają zgłaszać podatności, jeśli nie mogą liczyć na uczciwy przegląd ich raportu?

Kobeissi był ostatecznie zbanowany z kanałów Zulip Rust Project – zaledwie pięć godzin po złożeniu formalnej skargi do zespołu moderacyjnego Rusta i rady przywództwa. Oficjalnym powodem była "molestowanie". Ale Kobeissi słusznie wskazuje, że ci sami ludzie, którzy go banowali, to również osoby, które odrzuciły jego raporty o podatnościach. Jaki jest tutaj konflikt interesów? Czy osoba, która odrzuca raport o bezpieczeństwie, powinna być tą, która go bani za "molestowanie" za próbę eskalacji sprawy?

Agresywna komunikacja czy uzasadniona frustracja?

Valsorda i inni krytycy Kobeissiego skupiają się na tonie jego komunikacji. Argumentują, że jego blog post z 5 lutego był agresywny, oskarżycielski, hiperboliczny i "na granicy nieuczciwości". Słowa te są ważne – sugerują, że problem nie jest treścią, ale sposobem, w jaki Kobeisski ją przedstawił.

Ale tutaj pojawia się pytanie: czy frustracja wynikająca z miesiąca ignorowania i odrzucania uzasadnionych raportów o bezpieczeństwie nie jest... uzasadniona? Kobeisski twierdzi, że próbował "w dobrej wierze" opublikować doradztwa bezpieczeństwa przez ponad miesiąc. Jeśli prawidłowe kanały zawodzą, czy zwracanie się do mediów i społeczności jest "molestowaniem", czy jest to uzasadniona eskalacja?

Valsorda sama ma ponad dziesięcioletni konflikt z Kobeissim. To historyczne napięcie musi być brane pod uwagę przy ocenie jej komentarzy. Czy Valsorda jest bezstronnym obserwatorem, czy ma osobisty interes w tym, aby przedstawić Kobeissiego w negatywnym świetle?

Konflikt interesów w strukturze Rusta

Kobeisski w swojej skardze do Rust Foundation wskazuje na bezpośredni konflikt interesów. Przedstawiciel zespołu moderacyjnego Rusta w Radzie Przywództwa to ta sama osoba, która wydała publiczne ostrzeżenie moderacyjne przeciwko Kobeiskiemu w dyskusji o doradztwie bezpieczeństwa. Innymi słowy, osoba, która jest uczestnicy sporu, jest również członkiem ciała odpowiedzialnego za przegląd tego sporu.

To nie jest drobna proceduralna niedogodność – to jest fundamentalny problem w zarządzaniu. Każdy system sprawiedliwości, czy to sądowy czy korporacyjny, wymaga separacji między stronami sporu a arbitrami. Kiedy te role się mieszają, wynik jest z góry przesądzony.

Rust Foundation w piątek przyznała otrzymanie skargi Kobeissiego, stwierdzając: "Bierzemy wszystkie raporty bardzo poważnie". Ale to jest tylko początek. Rzeczywisty test będzie w tym, jak fundacja rzeczywiście rozpatrzy sprawę i czy będzie w stanie działać niezależnie od osób zaangażowanych w oryginalny konflikt.

Słoneczna strona formalnej weryfikacji – mit czy rzeczywistość?

Jeden z aspektów tego sporu, który jest często ignorowany, to fundamentalny spór o wartość formalnej weryfikacji w kryptografii. Cryspen buduje swoją reputację na idei, że matematycznie dowodnięty kod jest bezpieczniejszy niż kod testowany tradycyjnymi metodami.

Ale historia biblioteki libcrux pokazuje coś innego. Nawet formalnie zweryfikowany kod może zawierać błędy, jeśli specyfikacja jest nieprawidłowa lub jeśli implementacja nie w pełni odpowiada specyfikacji. Valsorda w swoim komentarzu do postu Kobeissiego przyznał, że testowanie i praktyki inżynierskie mogą dostarczać lepsze rezultaty niż formalna weryfikacja dla oprogramowania o wysokiej niezawodności.

To jest ważna lekcja dla całego ekosystemu. Formalna weryfikacja jest potężnym narzędziem, ale nie jest magiczną kulą. Projekty, które opierają się wyłącznie na formalnej weryfikacji bez tradycyjnego testowania bezpieczeństwa, mogą się okazać mniej bezpieczne niż projekty, które łączą oba podejścia. Cryspen powinna była to wiedzieć – i być może wiedziała, ale nie wdrożyła tego w praktyce.

Fundamentalny problem open source – ludzie, nie kod

Na koniec, artykuł The Register zawiera przywołaną obserwację, która uderza w sedno: "Gdy zapalę jednej osoby jest agresywnym orędownictwem dla drugiej, krytyczną luką w open source mogą być po prostu ludzie".

To jest słuszna obserwacja. Bezpieczeństwo oprogramowania jest ważne, ale sposób, w jaki społeczności zarządzają konfliktami, jest równie ważny. Rust ma świetne narzędzia, świetną technologię i świetnych ludzi. Ale system zarządzania bezpieczeństwem i konfliktami wydaje się być słaby.

Pytania, które muszą zostać rozstrzygnięte, to: Jak Rust Foundation powinna oddzielić przegląd skargi od osób zaangażowanych w oryginalny konflikt? Jak projekty open source powinny obsługiwać raporty o podatnościach od badaczy, którzy mają agresywny styl komunikacji? Czy istnieje sposób na wymuszenie przejrzystości w procesach bezpieczeństwa bez konieczności eskalacji do mediów?

Te pytania są ważne nie tylko dla Rusta, ale dla całego ekosystemu open source. Bezpieczeństwo zależy od tego, aby badacze mieli kanały do raportowania podatności i aby te kanały były uczciwe, przejrzyste i wolne od konfliktów interesów. Bez tego, nawet najlepsze technologicznie projekty mogą stać się słabą ogniwem w łańcuchu bezpieczeństwa.