Kryptografia postkwantowa

Komputer kwantowy to maszyna, która liczy na kubitach: kubit może przechowywać jednocześnie kombinację 0 i 1, a kubity można powiązać tak, że ich stany od siebie zależą. W większości zadań nie jest szybszy od zwykłego komputera. W kilku problemach o odpowiedniej strukturze matematycznej algorytm kwantowy sprawia, że błędne odpowiedzi się znoszą, a właściwa się wyróżnia, co daje ogromne przyspieszenie. Dzisiejsze maszyny mają za mało kubitów i za dużo błędów, by zagrozić szyfrowaniu. Do jego złamania potrzebna byłaby duża maszyna odporna na błędy, która sama je koryguje, a takiej nikt jeszcze nie zbudował. Dla Twojej firmy praktyczny wniosek jest wąski: taka maszyna złamałaby kryptografię klucza publicznego, która chroni niemal każde Twoje połączenie, więc jej zastąpienie trzeba zaplanować, zanim maszyna powstanie.

Ponieważ duży komputer kwantowy odporny na błędy, uruchamiający algorytm Shora, mógłby złamać metody klucza publicznego używane dziś do uzgadniania kluczy i podpisywania danych: RSA i kryptografię krzywych eliptycznych (ECC). Te dwie metody chronią wymianę kluczy niemal każdego połączenia HTTPS, VPN i SSH oraz podpisy na certyfikatach, aktualizacjach oprogramowania i dokumentach. Napastnik z taką maszyną mógłby odczytać wcześniej nagrany ruch i fałszować podpisy. Szyfrowanie symetryczne, takie jak AES, które szyfruje dane po uzgodnieniu klucza, algorytm Grovera osłabia tylko umiarkowanie; z kluczami 256-bitowymi pozostaje użyteczne. Taki komputer dziś nie istnieje i nikt nie potrafi wskazać roku, w którym powstanie. Ryzyko jest realne dla danych, które muszą pozostać tajne przez wiele lat, i trzeba je zaplanować, a nie traktować jak stan alarmowy. Rozwiązaniem jest oprogramowanie, nie sprzęt: nowe algorytmy, ustandaryzowane przez NIST w 2024 r., wdrażane przez aktualizacje.

Zamienia trudne problemy, na których się opierają, w łatwe. RSA jest bezpieczne, bo nikt nie potrafi w rozsądnym czasie rozłożyć bardzo dużej liczby na dwa czynniki pierwsze; kryptografia krzywych eliptycznych jest bezpieczna, bo nikt nie potrafi odtworzyć tajnej liczby stojącej za publicznym punktem na krzywej. Peter Shor pokazał w 1994 r., że komputer kwantowy potrafi znaleźć w obu problemach ukryty powtarzający się wzór, okres, a z tego okresu szybko wynika sekret. Na dostatecznie dużej maszynie atak zajmuje praktyczny czas zamiast niewykonalnego. Dłuższe klucze nie ratują RSA ani ECC: jedynie nieco spowalniają atak kwantowy. Dlatego odpowiedzią jest nowa matematyka, na przykład problemy kratowe, na których opierają się ML-KEM i ML-DSA, a dla których nie jest znany wydajny algorytm kwantowy. Opublikowane szacunki potrzebnej maszyny wciąż znacznie wykraczają poza wszystko, co dotąd zbudowano.

Znacznie mniej niż algorytm Shora dla RSA: osłabia szyfrowanie symetryczne i funkcje skrótu, ale ich nie łamie. Lov Grover pokazał w 1996 r., że komputer kwantowy potrafi przeszukać możliwości w liczbie kroków równej mniej więcej pierwiastkowi z liczby zwykłej. W zgadywaniu klucza oznacza to w przybliżeniu połowę długości klucza w bitach: teoretycznie 128-bitowy klucz AES zachowuje się raczej jak 64-bitowy. W praktyce atak to jeden bardzo długi łańcuch kroków, którego nie da się sensownie rozdzielić na wiele maszyn, więc nawet AES-128 pozostaje daleki od łatwego złamania. Typowa rada jest prosta: AES-256 dla danych, które mają długo pozostać tajne, i SHA-256 lub silniejsze do skrótów. Większość nowoczesnych systemów obsługuje już oba, więc ta część zmiany to zwykle kwestia konfiguracji, a nie projekt migracji. Prawdziwa praca dotyczy metod klucza publicznego.

Nikt tego nie wie, a każdy, kto podaje rok, zgaduje. Maszyna dość duża i stabilna, by uruchomić algorytm Shora przeciw dzisiejszym długościom kluczy, wymaga postępów w jakości kubitów, korekcji błędów i skali, których jeszcze nie zademonstrowano. Ankiety wśród ekspertów i mapy drogowe producentów podają przedziały, nie daty, i te przedziały się przesuwają. Twoje planowanie nie zależy jednak od tej daty. Regulatorzy wyznaczyli własne terminy: skoordynowana mapa drogowa UE z 23 czerwca 2025 r. oczekuje przeniesienia zastosowań wysokiego ryzyka do końca 2030 r., a wytyczne NIST dotyczące przejścia (NIST IR 8547, projekt z listopada 2024 r., wersja ostateczna z października 2026 r.) przewidują wycofanie podatnych na komputery kwantowe metod klucza publicznego, takich jak RSA i kryptografia krzywych eliptycznych, po 2030 r. i ich zakaz w standardach NIST po 2035 r. Klienci, audytorzy i przetargi zapytają o te daty na długo przed powstaniem jakiegokolwiek komputera kwantowego. Dla danych, które muszą pozostać tajne przez dekadę lub dłużej, nierówność Moski pokazuje, dlaczego czekanie na tę datę to zła strategia.

Kryptografia postkwantowa (PQC) to kryptografia klucza publicznego zaprojektowana tak, by pozostała bezpieczna wobec dużego komputera kwantowego, a przy tym działała na zwykłych komputerach. NIST opublikował pierwsze standardy 13 sierpnia 2024 r.: FIPS 203 (ML-KEM) do ustalania kluczy oraz FIPS 204 (ML-DSA) i FIPS 205 (SLH-DSA) do podpisów cyfrowych. Opierają się na problemach matematycznych, takich jak szukanie krótkich wektorów w wielowymiarowych kratach, albo na bezpieczeństwie funkcji skrótu, dla których nie jest znany wydajny atak kwantowy. Migracja oznacza aktualizację oprogramowania, bibliotek, protokołów i certyfikatów, a nie zakup sprzętu kwantowego. To też nie to samo co kwantowa dystrybucja klucza, która wymaga specjalnego sprzętu optycznego. Ceną zmiany jest rozmiar: klucze i podpisy postkwantowe są większe niż dzisiejsze, więc handshake'i rosną, a część starszych urządzeń sobie z tym nie radzi. Większość organizacji styka się z PQC najpierw przez aktualizacje przeglądarek, systemów operacyjnych i oprogramowania VPN, a potem musi zająć się własnymi serwerami i aplikacjami.

To pierwsze trzy standardy postkwantowe amerykańskiego Narodowego Instytutu Standaryzacji i Technologii (NIST), opublikowane 13 sierpnia 2024 r. po otwartym, międzynarodowym konkursie rozpoczętym w 2016 r. FIPS 203 opisuje ML-KEM, mechanizm enkapsulacji klucza, dzięki któremu dwie strony uzgadniają wspólny tajny klucz; przejmuje rolę, jaką dziś w wymianie kluczy pełnią RSA i Diffie-Hellman na krzywych eliptycznych. FIPS 204 opisuje ML-DSA, główny schemat podpisu cyfrowego. FIPS 205 opisuje SLH-DSA, wolniejszy schemat podpisu z większymi podpisami, oparty wyłącznie na funkcjach skrótu i utrzymywany jako konserwatywna alternatywa. Choć to amerykańskie standardy federalne, są punktem odniesienia na całym świecie: europejskie agencje, takie jak niemieckie BSI i francuskie ANSSI, zalecają między innymi te algorytmy, zwykle w połączeniu z klasycznym. Dla Ciebie to nazwy, których warto szukać w dokumentacji dostawców, ich planach rozwoju i odpowiedziach przetargowych.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) to postkwantowa metoda uzgadniania tajnego klucza przez otwartą sieć i ta, z którą zetkniesz się najpierw. Wywodzi się ze zgłoszenia CRYSTALS-Kyber. Jedna strona publikuje klucz publiczny; druga używa go, by opakować świeży losowy sekret, który rozpakować może tylko posiadacz klucza prywatnego. Ten sekret staje się kluczem do szybkiego szyfrowania symetrycznego, na przykład AES. Występuje w trzech rozmiarach: ML-KEM-512, ML-KEM-768 i ML-KEM-1024, przy czym typowym wyborem jest 768. Jest szybki, często porównywalny z krzywymi eliptycznymi, ale jego klucz publiczny i szyfrogram mają po około kilobajcie, wobec 32 bajtów w X25519. Z powodu tego rozmiaru część starszych zapór i urządzeń pośredniczących ma problemy z postkwantowymi handshake'ami. W TLS ML-KEM występuje zwykle w połączeniu z X25519 jako grupa hybrydowa X25519MLKEM768, którą większość przeglądarek już oferuje.

To dwa postkwantowe standardy podpisu: ML-DSA (FIPS 204, z CRYSTALS-Dilithium) i SLH-DSA (FIPS 205, z SPHINCS+). Podpis cyfrowy dowodzi, kto wytworzył dane i że nikt ich nie zmienił; chroni certyfikaty, aktualizacje oprogramowania, firmware, dokumenty i kod. ML-DSA to wybór ogólnego przeznaczenia: szybki, z podpisami liczącymi kilka kilobajtów zamiast 64 bajtów typowego podpisu ECDSA. SLH-DSA opiera się wyłącznie na bezpieczeństwie funkcji skrótu, co czyni go bardzo konserwatywnym, kosztem większych podpisów i wolniejszego podpisywania; pasuje do długowiecznych kotwic zaufania i podpisywania firmware'u. Podpisy mają mniejsze znaczenie dla „harvest now, decrypt later”, bo sfałszowany podpis pomaga napastnikowi dopiero wtedy, gdy komputer kwantowy istnieje. Dlatego większość organizacji zmienia najpierw wymianę kluczy, a podpisy później. Ekosystem certyfikatów z podpisami postkwantowymi dopiero powstaje, więc pytaj dostawców o ich plany, zamiast oczekiwać certyfikatów postkwantowych już dziś.

To kolejne algorytmy postkwantowe na ścieżce NIST, jeszcze niebędące ostatecznymi standardami. HQC (Hamming Quasi-Cyclic) to metoda enkapsulacji klucza, którą NIST wybrał w marcu 2025 r. jako zapasową dla ML-KEM. Opiera się na kodach korekcyjnych, a nie na kratach, więc gdyby kiedyś znaleziono słabość w problemach kratowych, gotowy byłby algorytm z innej rodziny matematycznej. NIST zapowiedział wtedy projekt standardu mniej więcej rok później i standard ostateczny w 2027 r. FN-DSA, oparty na zgłoszeniu FALCON, to schemat podpisu planowany jako FIPS 206; jego podpisy są znacznie mniejsze niż w ML-DSA, co pomaga tam, gdzie brakuje miejsca, ale trudniej go bezpiecznie zaimplementować. Wniosek dla Twojego planowania: nie stawiaj na jeden algorytm na zawsze. Wybieraj produkty, które potrafią wymienić algorytm przez konfigurację lub aktualizację. Ta zdolność, nazywana kryptozwinnością (crypto-agility), chroni Cię, gdy zmieni się standard albo wyjdzie na jaw błąd implementacji.

Hybrydowa wymiana kluczy łączy w jednym handshake'u TLS metodę klasyczną (X25519, wymianę na krzywych eliptycznych) z postkwantową (ML-KEM-768) i wyprowadza klucz sesji z obu. Klucz pozostaje tajny, dopóki trzyma się którakolwiek z nich: gdyby w wciąż młodym ML-KEM znaleziono błąd, X25519 nadal zatrzyma dzisiejszych napastników; wobec przyszłego komputera kwantowego zrobi to ML-KEM. Dlatego większość wytycznych, także europejskich agencji takich jak BSI i ANSSI, zaleca na czas przejścia rozwiązania hybrydowe. X25519MLKEM768 to nazwa tego połączenia w TLS. Główne przeglądarki oferują je już domyślnie, a duże sieci CDN i wiele usług chmurowych je akceptuje, więc część Twojego ruchu webowego może już z niego korzystać, choć niczego nie zmieniałeś. Połączenie, które go używa, sprawia, że nagrany ruch jest znacznie trudniejszy do późniejszego odszyfrowania. Zaplanować trzeba połączenia, które nadal używają wyłącznie klasycznej wymiany kluczy: starsze serwery, urządzenia, VPN i aplikacje wewnętrzne.

Dla niemal każdej firmy nie. Kwantowa dystrybucja klucza (QKD) wykorzystuje fizykę pojedynczych fotonów, przesyłanych dedykowanym światłowodem lub łączem w wolnej przestrzeni, by uzgodnić klucz w sposób ujawniający podsłuch. Wymaga specjalnego sprzętu po obu stronach, działa na ograniczonych odległościach, o ile nie doda się zaufanych stacji pośrednich, i sama nie uwierzytelnia stron, więc nadal potrzebuje klasycznych lub postkwantowych podpisów. Kryptografia postkwantowa to natomiast oprogramowanie działające w sieciach i na urządzeniach, które już masz. Europejskie agencje bezpieczeństwa, w tym niemieckie BSI, francuskie ANSSI i holenderskie NLNCSA, opublikowały wspólne stanowisko, w którym kryptografia postkwantowa jest główną drogą, a QKD nadaje się co najwyżej do zastosowań niszowych. Unijna infrastruktura komunikacji kwantowej EuroQCI służy określonym potrzebom administracji i to inna sprawa niż to, co powinna kupić średnia firma. Jeśli dostawca oferuje QKD jako odpowiedź na „harvest now, decrypt later” w zwykłej sieci biurowej, zapytaj, co daje ponad hybrydową konfigurację TLS lub VPN.

To sytuacja, w której napastnik nagrywa dziś szyfrowany ruch i przechowuje go, by odszyfrować, gdy powstanie odpowiednio silny komputer kwantowy. Nagrywanie jest tanie i dla Ciebie niewidoczne: może odbywać się w punkcie wymiany ruchu internetowego, na przejętym routerze albo u operatora, daleko od Twojej sieci. Zagrożony jest tylko ruch, którego wymiana kluczy jest podatna na komputery kwantowe, i tylko dane, które będą miały znaczenie w chwili odszyfrowania. Typowe przykłady to dokumentacja medyczna, projekty, kod źródłowy, długoterminowe umowy, akta prawne i dane osobowe przechowywane przez wiele lat; tygodniowy harmonogram dostaw nie. Często ocenia się to nierównością Moski: jeśli liczba lat, przez które dane muszą pozostać tajne, plus liczba lat migracji przekracza liczbę lat do powstania takiego komputera, trzeba zacząć teraz. Praktyczna odpowiedź to przeniesienie najpierw wymiany kluczy chroniącej długowieczne dane na hybrydowe metody postkwantowe, bo właśnie tam dzisiejsze nagrania stałyby się jutrzejszymi wyciekami. Podpisy mogą poczekać.

Dane, które dziś przechodzą przez sieć i muszą pozostać poufne także po pojawieniu się dużego komputera kwantowego. Zadaj dwa pytania o każdy zbiór danych: czy podróżuje połączeniem z wymianą kluczy podatną na komputery kwantowe i przez ile lat jego ujawnienie nadal by szkodziło? Typowe długowieczne przykłady to dokumentacja pacjentów i kadrowa, projekty produktów i kod źródłowy, akta fuzji i sprawy prawne, umowy z sektorem publicznym, dane biometryczne i nigdy niezmieniane dane logowania. Dane krótkotrwałe, takie jak jednorazowy kod czy ceny z tego miesiąca, nie są warte zmartwień. Dane przechowywane to inna kwestia: zwykle chroni je szyfrowanie symetryczne, takie jak AES, którego komputer kwantowy nie łamie, chyba że ich klucze są wymieniane lub opakowywane przy użyciu RSA. Spisz listę z właścicielem i okresem przechowywania dla każdej pozycji: stanie się kolejnością priorytetów migracji i podstawą obliczenia według Moski. Czujnik sieciowy nie sklasyfikuje Twoich danych; ta lista musi wyjść od biznesu.

Zestaw obok siebie trzy liczby dla każdego ważnego zbioru danych lub systemu. X to liczba lat, przez które dane muszą pozostać tajne. Y to liczba lat potrzebna na przeniesienie tego systemu na kryptografię postkwantową, łącznie z dostawcami, testami i cyklami budżetowymi. Z to liczba lat, które zostały do powstania komputera kwantowego zdolnego złamać dzisiejszą kryptografię klucza publicznego. Jeśli X plus Y jest większe od Z, dane wysłane dziś są już narażone na „harvest now, decrypt later”. Michele Mosca opisał tę nierówność w 2015 r. w pracy opublikowanej jako IACR ePrint 2015/1075. Z jest nieznane, więc nie udawaj, że je znasz: przyjmij wartość ostrożną i swobodną i sprawdź, które systemy nie przechodzą nawet przy tej drugiej. Na przykład umowy, które muszą pozostać poufne przez 10 lat, w systemie wymagającym 5 lat migracji, nie przechodzą przy każdym Z poniżej 15 lat. Wynikiem jest lista priorytetów, a nie prognoza, i to rozumowanie, za którym nadąży audytor i zarząd.

Zagrożenie nie jest szumem, ale spora część otaczającego je marketingu tak. Fakty są twarde: NIST opublikował ostateczne standardy w sierpniu 2024 r., przeglądarki i duzi dostawcy chmury już używają hybrydowej postkwantowej wymiany kluczy, a UE ma skoordynowaną mapę drogową z datami. Niepewne jest to, kiedy powstanie zdolny komputer kwantowy, i właśnie dlatego planowanie wygrywa z czekaniem: zmiana kryptografii w całej firmie trwa latami. Szumem są produkty obiecujące odporność na ataki kwantowe, zegary odliczające czas i presja na zakup sprzętu, którego nie potrzebujesz. Trzeźwe stanowisko dla większości średnich firm: bez wydatków awaryjnych, ale z inwentaryzacją w tym roku, pytaniami o PQC przy każdym nowym zakupie, aktualizacjami włączającymi hybrydową wymianę kluczy tam, gdzie dostawcy ją oferują, i priorytetem dla danych, które muszą długo pozostać tajne. To kosztuje niewiele i chroni przed pospieszną, drogą migracją w przyszłości.

Tak, jako kwestia planowania i ryzyka, a nie kryzys. Należy do agendy zarządu z trzech powodów. To długa zmiana w całej firmie, która przez kilka lat dotyka dostawców, produktów i budżetów, a ułożyć jej kolejność może tylko kierownictwo. Dotyczy danych, które firma obiecała chronić przez wiele lat, takich jak dane klientów, pacjentów czy projekty. A klienci, ubezpieczyciele i przetargi publiczne zaczynają o nią pytać, więc odpowiedź staje się sprawą handlową. W ramach NIS2 organy zarządzające podmiotów objętych dyrektywą muszą zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa i nadzorować ich wdrażanie, a polityka kryptograficzna jest jednym z nich. Zarząd potrzebuje niewiele: inwentarza miejsc, w których używana jest kryptografia podatna na komputery kwantowe, listy priorytetów opartej na tym, jak długo dane muszą pozostać tajne, wskazanego właściciela i harmonogramu zgodnego z unijnymi kamieniami milowymi 2030 i 2035. Nie potrzebuje technicznego wykładu o kubitach.

Zalecenie Komisji (UE) 2024/1101 z 11 kwietnia 2024 r. wezwało państwa członkowskie do koordynacji przejścia, a Grupa Współpracy NIS opublikowała 23 czerwca 2025 r. skoordynowaną mapę drogową: rozpocząć przejście, zabezpieczyć zastosowania wysokiego ryzyka do końca 2030 r. i przenieść jak najwięcej systemów do 2035 r. To mapa drogowa dla państw członkowskich, a nie prawo, które bezpośrednio wiąże Twoją firmę; organy krajowe mogą przełożyć ją na wytyczne lub przepisy. Pierwszy praktyczny krok to wiedza, gdzie używasz kryptografii.

Tego, by przejście rozpoczęło się wszędzie. Skoordynowana mapa drogowa opublikowana przez Grupę Współpracy NIS 23 czerwca 2025 r., w ślad za zaleceniem Komisji (UE) 2024/1101, wyznacza trzy etapy: pierwsze kroki do końca 2026 r., przeniesienie zastosowań wysokiego ryzyka do końca 2030 r. i jak najwięcej systemów do 2035 r. Pierwszy etap dotyczy przygotowań: państwa członkowskie przedstawiają krajowe plany przejścia, organizacje zaczynają inwentaryzować miejsca, w których używają kryptografii podatnej na komputery kwantowe, a ryzyko każdego zastosowania jest oceniane, by przypadki wysokiego ryzyka można było wcześnie pilotować. Mapa jest skierowana do państw członkowskich oraz ich sektora publicznego i krytycznego, a nie bezpośrednio do Twojej firmy, i organy krajowe przełożą ją na własne wytyczne. Jej logika pasuje jednak do każdej organizacji: do końca 2026 r. wiedz, gdzie jest Twoja kryptografia, kto odpowiada za każdy system i które muszą przejść jako pierwsze. Sprawdzaj, co publikuje Twój krajowy organ ds. cyberbezpieczeństwa.

Nie z nazwy, ale obie wskazują ten kierunek. NIS2, dyrektywa (UE) 2022/2555, wymaga od podmiotów objętych jej zakresem polityk i procedur stosowania kryptografii oraz, w stosownych przypadkach, szyfrowania, jako części środków zarządzania ryzykiem cyberbezpieczeństwa z art. 21. Akt o cyberodporności (CRA), rozporządzenie (UE) 2024/2847, wymaga, by produkty z elementami cyfrowymi chroniły poufność danych mechanizmami zgodnymi z aktualnym stanem wiedzy, w ramach zasadniczych wymagań z załącznika I. Żadna z nich nie wskazuje algorytmu. Stan wiedzy się jednak zmienia: gdy standardy NIST, wytyczne europejskich agencji i mapa drogowa UE uznają hybrydową postkwantową wymianę kluczy za normę, produkt lub polityka, które ją pomijają, coraz trudniej obronić w audycie czy przetargu. Sama mapa drogowa UE przedstawia przejście na PQC jako krok bez ryzyka żalu, wspierający NIS2 i CRA. Sprawdź krajową transpozycję NIS2 i wytyczne Twojego organu krajowego, bo szczegóły mogą się różnić między państwami.

Głównie tanie, zwyczajne rzeczy. Po pierwsze, aktualizuj przeglądarki, systemy operacyjne, klienty VPN, serwery i biblioteki: duża część zmiany postkwantowej przychodzi z aktualizacjami, a nowoczesne przeglądarki domyślnie używają już hybrydowej wymiany kluczy. Po drugie, spisz, gdzie używasz kryptografii, którą sam kontrolujesz: strona internetowa i jej hosting, zdalny dostęp, poczta, wymiana plików z klientami i każde urządzenie z własnymi certyfikatami. Po trzecie, oznacz dane, które muszą pozostać tajne przez wiele lat. Po czwarte, dodaj jedno pytanie do każdego nowego zakupu lub odnowienia umowy: czy produkt obsługuje hybrydową postkwantową wymianę kluczy, a jeśli nie, to kiedy? Po piąte, wybieraj dostawców, którzy potrafią zmieniać algorytmy przez aktualizacje. Zakupu specjalnych produktów kwantowych nie ma na liście. NetSenX może pomóc w drugim kroku: NQCI w wersji preview jest widoczny w każdym planie i aktywny od planu Pro, a wymaga czujnika przechwytywania pakietów, domyślnie wyłączonego, włączonego dla agenta na Linuksie lub czujnika SPAN/TAP; tryb podstawowy na macOS nie widzi handshake'ów.

W większości organizacji lata i dlatego wczesny start jest ważniejszy niż dokładny termin. Zmiana dotyczy każdego miejsca, w którym uzgadnia się klucze lub podpisuje dane: stron internetowych, VPN, SSH, poczty, aplikacji wewnętrznych, certyfikatów, sprzętowych modułów bezpieczeństwa (HSM), kart inteligentnych, maszyn i ich firmware'u. Wiele zależy od tego, kiedy dostawcy dostarczą obsługę PQC, i od Twoich własnych cykli wymiany: zapora kupiona w tym roku może działać jeszcze w następnej dekadzie, a sterownik przemysłowy znacznie dłużej. Skalę pokazują wcześniejsze zmiany: wycofanie SHA-1 i starych wersji TLS zajęło branży wiele lat od pierwszych ostrzeżeń do ostatecznego wyłączenia. Mała firma, która korzysta głównie z usług chmurowych i aktualnego oprogramowania, może przejść dużą część drogi zwykłymi aktualizacjami, w normalnym cyklu odnowy. Firma z własnym oprogramowaniem, długowiecznymi urządzeniami lub własnym urzędem certyfikacji powinna spodziewać się programu rozłożonego na kilka lat. Y w nierówności Moski to Twoje własne oszacowanie, więc zapisz je wraz z uzasadnieniem.

Chronisz dzisiejszy ruch przed jutrzejszym odszyfrowaniem i zyskujesz kilka korzyści, które w ogóle nie zależą od komputerów kwantowych. Dane o długim okresie ważności przestają być narażone na „harvest now, decrypt later”, gdy tylko ich wymiana kluczy przejdzie na metodę hybrydową. Inwentaryzacja wykonana po drodze ujawnia stare wersje TLS, słabe szyfry, wygasłe lub zapomniane certyfikaty i niezarządzane serwery, czyli ryzyka już dziś. Budowa kryptozwinności, czyli zdolności zmiany algorytmów przez konfigurację, sprawia, że kolejna wymuszona zmiana będzie tańsza, cokolwiek ją wywoła. Handlowo możesz odpowiadać na pytania przetargowe i klientów faktami i datami zamiast pustym polem, a gdy organy krajowe przełożą mapę drogową UE na wytyczne, będziesz gotowy. Migracja w ramach zwykłych cykli wymiany kosztuje znacznie mniej niż prowadzona pod presją czasu. Nie zyskujesz natomiast odporności na wszystko: kryptografia postkwantowa chroni wymianę kluczy i podpisy, a nie skradzione hasła, phishing czy niezałatane systemy.

Głównie zgodność i wydajność, rzadko matematyka. Klucze postkwantowe są większe, więc ClientHello TLS z X25519MLKEM768 nie mieści się już w jednym pakiecie sieciowym; część starszych zapór, load balancerów i urządzeń IPS źle to obsługuje i odrzuca lub resetuje połączenie. Sprzętowe moduły bezpieczeństwa (HSM), karty inteligentne i urządzenia wbudowane mogą nie mieć pamięci ani firmware'u dla nowych algorytmów. Podpisy liczące kilka kilobajtów powiększają łańcuchy certyfikatów i spowalniają ograniczone łącza. Młode implementacje mogą zawierać błędy, co jest jednym z powodów, by stosować metody hybrydowe i dobrze utrzymywane biblioteki. Proxy przechwytujące, które deszyfrują TLS, mogą nie obsługiwać nowych grup i po cichu cofać połączenia do klasycznej wymiany kluczy. Zaplanuj to: testuj na prawdziwym ruchu w segmencie testowym, zachowaj klasyczny tryb awaryjny na czas przejścia, sprawdź aktualizacje urządzeń pośredniczących i zmierz potem, które połączenia faktycznie używają wymiany hybrydowej. Widok handshake'ów w sieci pokazuje regresje, których nie widać w plikach konfiguracyjnych.

Kryptozwinność to zdolność zmiany algorytmów kryptograficznych używanych przez system bez przepisywania go lub wymiany. W praktyce oznacza to, że algorytmy wybiera się konfiguracją, a nie wpisuje na sztywno w kod; oprogramowanie korzysta z utrzymywanych bibliotek, które dostają nowe algorytmy w aktualizacjach; certyfikaty i klucze są zarządzane centralnie, ze znanymi właścicielami i datami ważności; a Ty wiesz, gdzie używany jest każdy algorytm. Ma to znaczenie teraz, bo przejście na PQC nie będzie ostatnie: HQC i FN-DSA dopiero nadchodzą, parametry mogą zostać zmienione, a w młodej implementacji może pojawić się błąd. Organizacja, która przejdzie jedną bolesną, ręczną migrację, przy następnej przeżyje to samo; ta, która zbuduje zwinność, zamieni następną zmianę w wydanie konfiguracji. Pytaj o to przy każdym zakupie: czy produkt potrafi zmienić algorytmy wymiany kluczy i podpisu przez aktualizację lub ustawienie i czy dostawca się do tego zobowiązuje? Produkt, który tego nie potrafi, to problem migracyjny, który kupujesz już dziś.

Coraz częściej tak, ale trzeba sprawdzić każdy produkt. OpenSSH uczynił hybrydową postkwantową wymianę kluczy domyślną w wersji 9.0 w 2022 r., a wersja 10.0 z 2025 r. ustawiła jako domyślną hybrydę opartą na ML-KEM, mlkem768x25519-sha256; jeśli oba końce mają aktualne wydania, Twoje sesje SSH prawdopodobnie już jej używają. W VPN obraz jest różny. Wymiana kluczy IPsec, IKEv2, zyskała w RFC 9370 standardowy sposób dodania kolejnych wymian kluczy, takich jak ML-KEM; część dostawców i projektów open source to obsługuje, inni tylko zapowiadają. WireGuard może dodać współdzielony klucz symetryczny jako postkwantową warstwę zabezpieczenia, ale sam jego handshake jest klasyczny. Sprawdź informacje o wydaniach firmware'u zapory lub bramy VPN i wersje klientów faktycznie w użyciu, i pamiętaj, że stary serwer po jednej stronie utrzymuje całe połączenie w trybie klasycznym. VPN zdalnego dostępu i site-to-site przenoszą wiele długowiecznych danych, więc zasługują na wysokie miejsce w kolejności migracji.

Zacznij od inwentaryzacji: certyfikaty, VPN, TLS na serwerach, SSH, podpisywanie kodu i biblioteki używane przez aplikacje. Dużą część widać w ruchu sieciowym, bo wymiana kluczy w każdym połączeniu TLS jest widoczna bez deszyfrowania. NQCI, inwentarz kryptografii NetSenX (w wersji preview), jest widoczny w każdym planie i aktywny od planu Pro: pokazuje, które połączenia używają wymiany kluczy podatnej na komputery kwantowe, a które hybrydowej wymiany postkwantowej. Wymaga czujnika przechwytywania pakietów, domyślnie wyłączonego: włączonego dla agenta na Linuksie albo czujnika na porcie SPAN lub TAP. Tryb podstawowy agenta, używany na macOS, nie widzi handshake'ów TLS. Daje widoczność; sama migracja pozostaje po stronie Twojej i Twoich dostawców.

Dużą jego część tak, ale nie całość. Każde połączenie TLS, zanim zacznie się szyfrowanie, ogłasza, jakie grupy wymiany kluczy oferuje klient i którą wybiera serwer, a także wersję TLS; SSH działa podobnie. Czujnik, który widzi te handshake'i, może wypisać dla każdego serwera i klienta, gdzie wciąż używana jest wymiana kluczy podatna na komputery kwantowe, a gdzie już hybrydowa postkwantowa, dla każdego urządzenia w segmencie, także drukarek, urządzeń sieciowych i maszyn, na których nie da się uruchomić agenta. Czego nie widzi: kryptografii wewnątrz aplikacji i baz danych, kluczy i certyfikatów zapisanych na dysku, podpisywania kodu, szyfrowanych kopii zapasowych, niemonitorowanych segmentów i połączeń, których handshake nie przechodzi przez czujnik. NQCI, inwentarz kryptografii NetSenX (w wersji preview), jest widoczny w każdym planie i aktywny od planu Pro; wymaga czujnika przechwytywania pakietów, domyślnie wyłączonego, włączonego dla agenta na Linuksie albo czujnika na porcie SPAN lub TAP. Tryb podstawowy na macOS nie widzi handshake'ów. Połącz go z inwentarzem certyfikatów i ankietami dla dostawców.

Spójrz na grupę wymiany kluczy wybraną w każdym handshake'u TLS: X25519MLKEM768 oznacza hybrydową wymianę postkwantową; X25519, secp256r1 lub wymiana kluczy RSA oznaczają wyłącznie klasyczną. Pojedynczy serwer możesz przetestować z zewnątrz: OpenSSL 3.5 i nowsze oraz narzędzia na nim oparte, takie jak curl, potrafią zaoferować grupę hybrydową i pokazać, co wybiera serwer, a część internetowych testerów TLS to raportuje. Narzędzia deweloperskie przeglądarki też pokazują wynegocjowaną grupę dla odwiedzanej strony. Dla całej sieci jednorazowy test nie wystarczy, bo liczy się to, co naprawdę dzieje się każdego dnia między Twoimi klientami i serwerami: stare klienty, urządzenia i aplikacje wewnętrzne często wracają do grup klasycznych. NQCI w wersji preview pokazuje to dla każdego połączenia w monitorowanym ruchu. Jest widoczny w każdym planie i aktywny od planu Pro, z czujnikiem przechwytywania pakietów włączonym dla agenta na Linuksie lub czujnika SPAN albo TAP, bo tryb podstawowy na macOS nie widzi handshake'ów. Wynik pokazuje, gdzie aktualizacje już przeprowadziły migrację, a gdzie jeszcze trzeba ją wykonać.

Dla każdego miejsca, w którym kryptografia coś chroni, zapisz, co jest chronione, w jaki sposób i kto może to zmienić. Praktyczne pola: system lub usługa i jej właściciel; co chroni, z rodzajem danych i liczbą lat, przez które muszą pozostać tajne; protokół, na przykład TLS, SSH, IPsec, S/MIME, podpisywanie kodu albo szyfrowanie dysków i baz danych; algorytmy wymiany kluczy, podpisu i szyfrowania z długościami kluczy; certyfikaty, ich wystawca i data ważności; wersja biblioteki lub produktu i to, czy dostawca ma plan postkwantowy; oraz czy algorytm można zmienić konfiguracją. Dodaj priorytet wyprowadzony z nierówności Moski. Źródła różnią się w zależności od warstwy: obserwacja sieci dla tego, co przechodzi przez łącze, zarządzanie certyfikatami i skanery dla certyfikatów, analiza składu oprogramowania i ankiety dla dostawców dla tego, co siedzi w aplikacjach. Inwentarz zawierający tylko certyfikaty pomija wymianę kluczy, a zbudowany tylko z sieci pomija dane przechowywane. Utrzymuj go na bieżąco, bo każda aktualizacja może zmienić odpowiedź, i datuj każdy wpis: audytorzy i przetargi pytają, kiedy go ostatnio sprawdzono.

Nie, i żaden produkt do monitorowania sieci tego nie potrafi. Ochronę przed przyszłym komputerem kwantowym daje zmiana kryptografii we własnych systemach i u dostawców: najpierw hybrydowa wymiana kluczy, potem podpisy postkwantowe. NetSenX nie jest produktem szyfrującym i niczego nie zmienia, nie aktualizuje ani nie migruje. Daje widoczność, od której zaczyna się każda migracja. NQCI, inwentarz kryptografii NetSenX, jest w wersji preview: widoczny w każdym planie i aktywny od planu Pro. Pokazuje, które połączenia w monitorowanym ruchu wciąż używają wymiany kluczy podatnej na komputery kwantowe, a które już hybrydowej postkwantowej, więc widzisz, gdzie aktualizacje zrobiły już swoje, a gdzie nie, i później wychwytujesz regresje. Wymaga czujnika przechwytywania pakietów, domyślnie wyłączonego: włączonego dla agenta na Linuksie albo czujnika na porcie SPAN lub TAP; tryb podstawowy na macOS nie widzi handshake'ów. Nie widzi kryptografii wewnątrz aplikacji, na dyskach ani w segmentach, których nie obserwuje żaden czujnik.

Faktami o Twoim planie, nie hasłami. Oceniający zwykle szukają czterech rzeczy: że wiesz, gdzie używasz kryptografii podatnej na komputery kwantowe, że ustaliłeś priorytety, że masz harmonogram i że ktoś za to odpowiada. Mocna odpowiedź wymienia inwentarz i jego datę; metodę ustalania priorytetów, na przykład nierówność Moski zastosowaną do okresów przechowywania danych; kroki już wykonane, takie jak włączona hybrydowa wymiana kluczy w usługach publicznych i sprawdzone wersje VPN i SSH; zależności od dostawców wraz z ich zadeklarowanymi planami; oraz kamienie milowe zgodne ze skoordynowaną mapą drogową UE: pierwsze kroki do końca 2026 r., a zastosowania wysokiego ryzyka do końca 2030 r. Przywołaj z nazwy standardy NIST FIPS 203, 204 i 205. Nie twierdź, że Twoja usługa jest odporna na ataki kwantowe; poinformowany oceniający obniży za to ocenę. Jeśli inwentarz pochodzi częściowo z obserwacji sieci, napisz to i napisz, czego nie obejmuje. Uczciwa, częściowa odpowiedź z datami wypada lepiej niż pewna siebie pustka.

Zadawaj pytania, na które odpowiedzi da się sprawdzić. Które algorytmy postkwantowe lub hybrydowe produkt obsługuje dziś, z nazwy, na przykład X25519MLKEM768 dla TLS albo ML-DSA dla podpisów, i od której wersji? Jeśli jeszcze żadnych, to w którym wydaniu i kiedy? Czy algorytmy można zmienić konfiguracją lub aktualizacją, bez wymiany sprzętu? Z jakiej biblioteki kryptograficznej korzysta produkt i kto ją utrzymuje? Czy sprzęt, na przykład zapora, sprzętowy moduł bezpieczeństwa albo sterownik, ma zapas na większe klucze, czy trzeba będzie go wymienić? Jak dostawca będzie podpisywał własne aktualizacje, gdy zmienią się algorytmy podpisu? Czy w okresie przejściowym produkt będzie działał z klientami obsługującymi tylko algorytmy klasyczne? Proś o odpowiedzi na piśmie, z datami. Uważaj na odpowiedzi obiecujące odporność na ataki kwantowe albo mówiące tylko o szyfrowaniu symetrycznym: omijają właściwe pytanie. Dostawca, który nie potrafi odpowiedzieć, to zależność, którą trzeba uwzględnić w planie, a jego odpowiedź należy do Twojego inwentarza.