Nowe standardy szyfrowania po erze komputerów kwantowych: co planuje branża bezpieczeństwa

Dlaczego komputery kwantowe zmieniają zasady gry w szyfrowaniu

Hype kontra realne możliwości komputerów kwantowych

Komputery kwantowe od lat są na pierwszych stronach mediów technologicznych – raz jako przełom, raz jako zagrożenie dla całej współczesnej kryptografii. W praktyce sytuacja jest bardziej przyziemna. Dzisiejsze urządzenia kwantowe to głównie prototypy: mają ograniczoną liczbę kubitów, wysoki poziom błędów i krótkie czasy koherencji. Do złamania standardów typu RSA-2048 czy popularnych krzywych eliptycznych w SSL/TLS jeszcze daleko.

Jednocześnie nikt poważny w branży bezpieczeństwa nie liczy na to, że „jakoś to będzie”. Tempo rozwoju technologii kwantowych jest trudne do przewidzenia, ale trend jest jednoznaczny: liczba efektywnych kubitów rośnie, techniki korekcji błędów dojrzewają, a duże firmy (IBM, Google, Microsoft) oraz rządy pompują w badania ogromne środki. Nawet jeśli pełnoskalowy komputer zdolny złamać RSA powstanie za 10–20 lat, to dla danych, które muszą pozostać tajne przez dekadę lub dłużej, ten horyzont jest bardzo niebezpiecznie blisko.

Różnica między marketingiem a realnym zagrożeniem jest więc następująca: nikt nie zdejmuje dzisiaj z internetu certyfikatów, bo „już jutro RSA padnie”. Natomiast branża bezpieczeństwa zakłada, że komputer kwantowy zdolny łamać kluczowe algorytmy pojawi się w czasie życia wielu obecnych systemów. Planowanie migracji na kryptografię postkwantową jest więc inwestycją, nie reakcją w panice.

Na czym polega przewaga kwantowa dla ataków kryptograficznych

W kontekście szyfrowania kluczowe są dwa algorytmy kwantowe: Shora i Grovera. Nie trzeba tu wchodzić w szczegóły mechaniki kwantowej – wystarczy zrozumieć, co zmieniają z punktu widzenia atakującego.

Algorytm Shora rozwiązuje efektywnie dwa problemy matematyczne, na których opiera się większość dzisiejszej kryptografii asymetrycznej:

• faktoryzację dużych liczb (podstawa bezpieczeństwa RSA),
• logarytm dyskretny (podstawa bezpieczeństwa Diffie–Hellmana i kryptografii opartej na krzywych eliptycznych – ECC).

Na klasycznym komputerze rozkład dużej liczby na czynniki pierwsze jest praktycznie niewykonalny w sensownym czasie. Algorytm Shora pokazuje, że wydajny komputer kwantowy mógłby to zrobić w czasie wielomianowym. Teoretycznie więc klucze RSA, ECDH i standardowe podpisy cyfrowe oparte na tych problemach przestają być bezpieczne, gdy tylko pojawi się odpowiednio duży komputer kwantowy.

Algorytm Grovera dotyczy głównie kryptografii symetrycznej i funkcji hashujących. Przyspiesza on przeszukiwanie przestrzeni kluczy mniej więcej do pierwiastka z liczby możliwych kluczy. W praktyce oznacza to, że bezpieczeństwo symetrycznej długości klucza 128 bitów spada do poziomu mniej więcej 64 bitów. Nie jest to katastrofa, bo można skompensować efekt Grovera, przechodząc na dłuższe klucze (np. 256-bitowe).

Konsekwencja jest jasna: komputery kwantowe są egzystencjalnym problemem dla kryptografii asymetrycznej w dzisiejszym wydaniu, natomiast dla szyfrowania symetrycznego są raczej bardzo głośnym ostrzeżeniem, by przestać oszczędzać na długości kluczy.

Zagrożone standardy: RSA, ECC i podpisy cyfrowe

Większość infrastruktury bezpieczeństwa internetu opiera się obecnie na RSA lub ECC. Dotyczy to przede wszystkim:

• certyfikatów TLS/HTTPS (czyli całego bezpiecznego ruchu w przeglądarkach),
• VPN-ów (IPsec, TLS VPN),
• podpisów kodu (signing binarek, pakietów, firmware’u),
• infrastruktury PKI w firmach i administracji publicznej,
• komunikacji e-mail (S/MIME, PGP w wariantach RSA/ECC).

W każdym z tych scenariuszy pojawia się ten sam schemat: klucz publiczny chroniony jest matematycznym problemem faktoryzacji lub logarytmu dyskretnego. W momencie pojawienia się wydajnego komputera kwantowego atakujący może z klucza publicznego wyliczyć klucz prywatny. To oznacza możliwość podszycia się pod serwer, osobę lub organizację, a także masowe łamanie historycznych nagrań ruchu, jeśli zostały zarchiwizowane.

Szacunki co do momentu „Q-day” – chwili, gdy komputery kwantowe staną się realnym zagrożeniem dla tych standardów – są rozbieżne, ale zakres 10–30 lat pojawia się najczęściej w raportach. Nawet jeśli ktoś jest sceptyczny, że stanie się to tak szybko, organizacje, które przechowują dane o długim okresie życia (np. dokumentacja medyczna pacjentów) nie mogą zakładać optymistycznego scenariusza.

Harvest now, decrypt later – ciche zbieranie danych na przyszłość

Najbardziej niedocenianą koncepcją związaną z komputerami kwantowymi jest atak typu harvest now, decrypt later. Scenariusz jest prosty:

• dziś ruch szyfrowany HTTPS, VPN czy e-mail jest przechwytywany i archiwizowany przez zaawansowanych przeciwników (wywiady, duże grupy przestępcze, podmioty prowadzące masową inwigilację);
• atakujący nie może go teraz odszyfrować, ale zakłada, że za 10–15 lat będzie dysponował komputerem kwantowym wystarczająco mocnym, by złamać użyte algorytmy asymetryczne;
• wtedy odszyfrowuje zarchiwizowane dane i uzyskuje dostęp do informacji, które wciąż mogą mieć wysoką wartość.

Ten model ataku sprawia, że pytanie „czy komputery kwantowe złamią szyfry za mojego życia” jest źle postawione. Znacznie ważniejsze brzmi: jak długo dane, które chronię, muszą pozostać poufne. Jeśli to okres krótszy niż potencjalny czas dojścia technologii kwantowej do dojrzałości – zagrożenie jest, delikatnie mówiąc, istotne.

Dla branży bezpieczeństwa oznacza to konieczność działania z wyprzedzeniem. Migracja do szyfrowania postkwantowego nie może zacząć się dopiero, gdy pojawi się pierwszy ogólnodostępny komputer kwantowy. Ruch jest zbierany już dziś, więc okno na spokojną migrację stopniowo się zamyka.

Słabe punkty dzisiejszej kryptografii w obliczu kwantów

Dlaczego klucz publiczny staje się piętą achillesową

Model klucza publicznego zrewolucjonizował bezpieczeństwo – umożliwił bezpieczną wymianę kluczy bez wcześniejszego dzielenia się tajemnicą. W erze kwantowej dokładnie ten sam model staje się głównym wektorem ataku.

W RSA, Diffie–Hellmanie i ECC zakłada się, że mając klucz publiczny, atakujący praktycznie nie jest w stanie odzyskać klucza prywatnego w sensownym czasie. Algorytm Shora łamie to założenie. W przypadku RSA sprowadza się to do faktoryzacji liczby będącej iloczynem dwóch dużych liczb pierwszych. W przypadku ECC – do obliczenia logarytmu dyskretnego na krzywej eliptycznej.

Problem nie dotyczy jedynie nowych połączeń. Jeżeli atakujący zarchiwizował certyfikaty i ruch, to w momencie uzyskania kluczy prywatnych może cofnąć się w czasie i odszyfrować dawne sesje, o ile nie użyto mechanizmów zapewniających silne forward secrecy. Z perspektywy architektów systemów oznacza to konieczność przeglądu całego łańcucha zaufania, a nie tylko wymianę pojedynczego algorytmu.

Narażone protokoły i usługi: od TLS po PKI

Lista systemów opartych na kryptografii asymetrycznej jest długa, ale kilka obszarów wymaga szczególnej uwagi:

• TLS/HTTPS – praktycznie każdy serwis internetowy wykorzystuje certyfikaty oparte na RSA lub ECC. Nawet jeśli dane z sesji mają krótką wartość, loginy, hasła, tokeny czy cookies często pozwalają rekonstruować dostęp do kont.
• VPN (IPsec, TLS, SSL VPN) – szyfrowanie tuneli między oddziałami, środowiskami chmurowymi czy zdalnymi pracownikami. Przechwycony ruch VPN często zawiera „esencję” życia firmy.
• Podpisy kodu i firmware’u – złamanie klucza prywatnego dostawcy oprogramowania pozwala fałszować aktualizacje, co jest idealną drogą do łańcuchowych ataków (supply chain).
• PKI korporacyjne – wewnętrzne certyfikaty dla serwerów, urządzeń, użytkowników, podpisywanie dokumentów. Skala i rozproszenie PKI sprawiają, że migracja będzie tu szczególnie bolesna.
• E-mail – S/MIME i PGP oparte na RSA/ECC. Dla wielu organizacji korespondencja mailowa jest archiwizowana latami, co doskonale wpisuje się w model „harvest now, decrypt later”.

Migracja w tych obszarach nie jest prosta: w grę wchodzą różne implementacje, starsze urządzenia, ograniczenia sprzętowe i zależności biznesowe. Brak spójnej strategii kryptograficznej na poziomie organizacji kończy się tym, że jedne zespoły wdrażają już hybrydowe TLS, a inne wciąż generują nowe klucze RSA-1024, bo „tak zawsze było”.

Szyfrowanie symetryczne a asymetryczne – odporność na kwanty

Kryptografia symetryczna (AES, ChaCha20, itp.) jest w znacznie lepszej sytuacji. Algorytm Grovera przyspiesza atak brute force, ale nie czyni go magicznie łatwym. Podwójna długość klucza kompensuje efekt: AES-256 jest postrzegany jako wystarczająco bezpieczny nawet w założeniu istnienia silnych komputerów kwantowych.

W praktyce oznacza to, że:

• nie trzeba porzucać AES – wystarczy upewnić się, że stosowane są odpowiednio długie klucze (128 bitów to obecne minimum, ale wiele organizacji już przechodzi na 256);
• funkcje hashujące (SHA-256, SHA-3) również zachowują użyteczność, choć przy bardzo silnych wymaganiach pojawiają się rekomendacje przejścia na dłuższe wyjścia (np. SHA-512);
• główny wysiłek migracyjny dotyczy mechanizmów wymiany kluczy i podpisów, a nie samego szyfrowania danych.

W architekturach systemów często oznacza to korzystną asymetrię: można zachować istniejące moduły szyfrujące dane, podmieniając jedynie „otoczkę” – czyli sposób negocjacji kluczy sesyjnych i weryfikacji tożsamości za pomocą podpisów cyfrowych.

Zmiana „okna bezpieczeństwa” danych w perspektywie lat

Nie wszystkie dane są równie wrażliwe na zagrożenia kwantowe. Kluczowym parametrem jest okres, przez jaki poufność musi być zachowana. Można wyróżnić kilka typowych kategorii:

• krótkoterminowe – dane transakcyjne, jednorazowe tokeny, komunikacja operacyjna; ich wartość spada po godzinach lub dniach. Dla nich głównym problemem jest bezpieczeństwo „tu i teraz”, mniej – przyszły komputer kwantowy.
• średnioterminowe – np. dane klienta, dokumenty finansowe, poufne umowy; ich wartość zwykle mieści się w przedziale 3–10 lat, czasem dłużej.
• długoterminowe – dokumentacja medyczna, patenty, własność intelektualna, dane wywiadowcze, dokumenty państwowe; tu horyzont wynosi nawet kilkadziesiąt lat.

Dla trzeciej grupy model „harvest now, decrypt later” jest szczególnie niebezpieczny. Jeśli dziś używany jest TLS oparty na RSA, a dane medyczne są przesyłane w ten sposób i dodatkowo archiwizowane w innych systemach chronionych tymi samymi algorytmami, to bez migracji na odporne na komputery kwantowe mechanizmy istnieje spora szansa, że zostaną odszyfrowane w trakcie życia tych danych.

Dobrą praktyką jest przeprowadzenie w organizacji mapowania kategorii danych na wymagany okres poufności oraz na tej podstawie ustalanie priorytetów migracji. Nie każdy system jest równie pilny. Krytyczne są te, w których długowieczne dane przechodzą przez protokoły oparte na RSA/ECC lub są w ten sposób chronione w spoczynku.

Kryptografia postkwantowa – co to jest i czego nie obiecuje

Definicja i założenia kryptografii postkwantowej

Kryptografia postkwantowa (PQC) to zbiór algorytmów kryptograficznych projektowanych specjalnie tak, aby były odporne na znane dziś ataki z użyciem komputerów kwantowych, w tym algorytmy Shora i Grovera. Kluczowa cecha: są to algorytmy działające na klasycznym sprzęcie – nie wymagają posiadania komputera kwantowego ani specjalnych urządzeń fizycznych.

PQC obejmuje zarówno mechanizmy:

• wymiany kluczy / szyfrowania kluczy (Key Encapsulation Mechanisms – KEM),
• podpisów cyfrowych,
• inne, bardziej specjalistyczne konstrukcje (np. schematy szyfrowania z określonymi właściwościami, choć w praktyce standardyzacja skupia się dziś na KEM i podpisach).

Algorytmy postkwantowe zakładają przeciwnika dysponującego zarówno klasycznymi, jak i kwantowymi zasobami obliczeniowymi. Projektuje się je tak, by znane obecnie techniki (klasyczne i kwantowe) nie pozwalały na efektywny atak. Nie ma tu jednak gwarancji „na wieczność” – nauka się nie kończy, a w kryptografii nie istnieje magiczny certyfikat „niezłamalne”.

Realistyczne podejście do PQC oznacza zaakceptowanie, że mówimy o najlepszej znanej dziś odpowiedzi na przyszłe zagrożenia, a nie o złotym graalu. Algorytmy te są projektowane przeciwko aktualnemu stanowi wiedzy matematycznej. Jeśli za pięć czy dziesięć lat ktoś znajdzie zupełnie nową klasę ataków na kratowe problemy czy kody, trzeba będzie ponownie uruchomić maszynę migracyjną. Dobrze zaprojektowana infrastruktura kryptograficzna musi więc zakładać rotację prymitywów jako normalny element życia systemu, a nie jednorazowy „projekt kwantowy”.

PQC nie rozwiązuje też klasycznych problemów bezpieczeństwa: słabych implementacji, błędów w protokołach, wycieków z endpointów czy kompromitacji kluczy przez phishing i malware. Przejście na postkwantowe KEM-y i podpisy nic nie da, jeśli prywatny klucz administratora nadal leży w pliku „keys_old_backup_final2.pem” na desktopie. PQC wzmacnia fundamenty matematyczne, ale nie zastąpi higieny operacyjnej, segmentacji sieci ani zdrowego procesu zarządzania tożsamością.

Dla wielu organizacji zaskoczeniem bywa również „cena” praktyczna: większe klucze i podpisy, inne profile wydajnościowe, nowe zależności w bibliotekach kryptograficznych. To przekłada się na pojemność baz certyfikatów, obciążenie serwerów TLS, rozmiar wiadomości w protokołach IoT czy czas weryfikacji podpisów w inteligentnych kartach. Zanim ktokolwiek przełączy przełącznik „PQC=on” w produkcji, powinien mieć za sobą przynajmniej pilotaż na krytycznych ścieżkach biznesowych i profilowanie wydajności pod rzeczywiste scenariusze ruchu.

W praktyce rozsądna strategia wygląda mniej efektownie niż marketingowe hasła o „pełnej odporności na kwanty”: inwentaryzacja kryptografii w organizacji, priorytetyzacja systemów pod kątem długowieczności danych, wprowadzenie hybrydowych mechanizmów (PQC + klasyczne algorytmy), stopniowe unowocześnianie PKI i regularne przeglądy polityk. To żmudna praca, ale dzięki niej dzień, w którym pierwszy użyteczny komputer kwantowy trafi do centrum danych kogoś „po drugiej stronie”, będzie tylko ciekawą wiadomością, a nie początkiem kryzysowego weekendu bez snu.

Standardyzacja PQC: co robi NIST, ETSI, IETF i reszta świata

Program NIST – maraton, nie sprint

Najbardziej znany proces standardyzacji kryptografii postkwantowej prowadzi amerykański NIST. To wieloletni „konkurs piękności” dla algorytmów, w którym oceniane są zarówno bezpieczeństwo matematyczne, jak i praktyczne aspekty: wydajność, rozmiary kluczy, podatność na błędy implementacyjne czy ataki bocznokanałowe.

Proces podzielono na rundy. W każdej z nich część kandydatów odpadała po analizie kryptograficznej lub z powodów praktycznych. Na końcowej prostej (tzw. „trzecia runda”) NIST ogłosił pierwszą falę algorytmów przeznaczonych do standaryzacji:

• CRYSTALS-Kyber – KEM do wymiany kluczy;
• CRYSTALS-Dilithium – schemat podpisu cyfrowego;
• FALCON – schemat podpisu cyfrowego o innych parametrach i profilu wydajnościowym;
• SPHINCS+ – schemat podpisu oparty na funkcjach skrótu, traktowany jako bardzo konserwatywna opcja „awaryjna”.

NIST publikuje już szkice standardów (FIPS) dla Kyber i Dilithium, co w praktyce oznacza, że duzi dostawcy (systemy operacyjne, przeglądarki, sprzęt kryptograficzny) planują je jak domyślne elementy przyszłej infrastruktury. Kolejna fala algorytmów – m.in. opartych na innych problemach matematycznych (np. kodowych) – jest analizowana w ramach dalszych etapów programu.

Warto zwrócić uwagę na jedną rzecz: NIST dopuszcza możliwość późniejszej wymiany algorytmów. Standardy nie są traktowane jako „wykute w kamieniu na 30 lat”, lecz jako baza pod przyszłe rotacje. W praktyce oznacza to konieczność projektowania systemów tak, by wymiana algorytmu KEM czy podpisu była w miarę bezbolesna i nie wymagała przepisywania połowy stosu komunikacyjnego.

ETSI, ENISA i perspektywa europejska

W Europie istotną rolę odgrywa ETSI (European Telecommunications Standards Institute), który od lat prowadzi grupę roboczą Quantum-Safe Cryptography. To tam powstają raporty i specyfikacje dotyczące praktycznych aspektów wdrożeń: od sieci operatorskich, przez 5G, po przemysłowe IoT.

ETSI nie konkuruje z NIST w sensie „własnego konkursu”, raczej:

• analizuje kandydatów wyłaniających się w procesie NIST,
• przekłada je na wymagania sektorowe (telekom, energetyka, transport),
• przygotowuje wytyczne wdrożeniowe dla operatorów i regulatorów.

Równolegle ENISA (Europejska Agencja ds. Cyberbezpieczeństwa) publikuje opracowania dotyczące ryzyka związanego z komputerami kwantowymi i rekomendacji migracyjnych. W wielu krajach UE dokumenty ENISA stają się punktem odniesienia dla sektorowych regulacji – od finansów, przez służbę zdrowia, po administrację.

Z perspektywy organizacji działających globalnie oznacza to jedno: trzeba umieć żyć równocześnie w „świecie NIST” i „świecie ETSI/ENISA”. W praktyce sprowadza się to do projektowania polityk kryptograficznych tak, by można było spełnić zarówno wymagania amerykańskich regulatorów i partnerów, jak i europejskich wytycznych dla infrastruktury krytycznej.

IETF, TLS i Internet „po kwantach”

O ile NIST odpowiada głównie za „gołe prymitywy” kryptograficzne, o tyle IETF (Internet Engineering Task Force) zajmuje się tym, jak wpleść je w protokoły sieciowe. Tutaj rozgrywa się bitwa o to, jak będzie wyglądało TLS 1.3+, IPsec czy SSH w erze postkwantowej.

W IETF powstają m.in.:

• specyfikacje hybrydowych zestawów szyfrów TLS (łączących np. X25519 + Kyber),
• rozszerzenia do X.509 opisujące sposób umieszczania kluczy PQC w certyfikatach,
• propozycje nowych identyfikatorów algorytmów dla KEM-ów i podpisów postkwantowych.

Implementatorzy bibliotek typu OpenSSL, BoringSSL czy wolfSSL śledzą te prace dość nerwowo, bo jedno dodatkowe pole w strukturze certyfikatu może oznaczać tygodnie pracy nad kompatybilnością z egzotycznymi klientami „sprzed dekady”. To też dobry powód, by trzymać się aktualnych wersji stosu TLS, zamiast pielęgnować wewnętrznego forka OpenSSL 1.0.2 z 2015 roku.

Reszta ekosystemu: ISO, branże regulowane i producenci sprzętu

Poza wymienionymi instytucjami działają jeszcze:

• ISO/IEC – tworzy normy obejmujące zarządzanie kluczami, moduły kryptograficzne (np. odpowiedniki FIPS 140), bezpieczeństwo kart i tokenów;
• branżowe ciało standaryzacyjne typu PCI SSC (płatności kartowe), które muszą uwzględnić PQC w kolejnych wersjach wymagań;
• producenci HSM-ów, TPM-ów, kart inteligentnych, którzy definiują własne interfejsy API dla nowych algorytmów (często z lekkim wyprzedzeniem wobec formalnych norm).

W konsekwencji organizacje nie mogą polegać wyłącznie na jednym źródle rekomendacji. Strategia postkwantowa powinna wynikać z przecięcia: wymogów regulatora, możliwości sprzętu, dojrzałości bibliotek kryptograficznych i realnych potrzeb biznesu. Dokument przebiegający myszką po tabelce „algorytmy według NIST” nie załatwi migracji.

Konkretne algorytmy postkwantowe – co już jest „na stole”

Algorytmy kratowe – Kyber, Dilithium, FALCON i spółka

Najważniejszą rodziną w obecnej generacji PQC są schematy oparte na problemach kratowych (lattices). Ich siła leży w odporności na znane ataki kwantowe oraz stosunkowo dobrym kompromisie między bezpieczeństwem a wydajnością.

Najczęściej pojawiają się trzy nazwy:

• CRYSTALS-Kyber (KEM)
  Opiera się na problemie tzw. Module-LWE. Oferuje różne poziomy bezpieczeństwa (Kyber512, Kyber768, Kyber1024), które można dopasować do profilu systemu. Cechuje się dobrą wydajnością zarówno po stronie serwera, jak i klienta. Długości kluczy i ciphertextów są istotnie większe niż przy klasycznej wymianie ECDH, ale dla większości zastosowań webowych mieszczą się w akceptowalnych granicach.
• CRYSTALS-Dilithium (podpis)
  Także konstrukcja kratowa, projektowana jako ogólnotrudny koń roboczy do podpisów w protokołach, PKI i aplikacjach biznesowych. Zaletą jest prostsza implementacja niż w FALCON-ie, kosztem nieco większych podpisów. Dla serwerów, kontenerów, aplikacji mobilnych – zwykle bardzo dobry kompromis.
• FALCON (podpis)
  Bardziej złożony matematycznie, o mniejszych podpisach niż Dilithium i z dobrą wydajnością w weryfikacji. Jednocześnie trudniejszy w poprawnej implementacji i wrażliwszy na błędy numeryczne. Dobry kandydat tam, gdzie rozmiar podpisu ma krytyczne znaczenie (np. niektóre zastosowania w IoT czy masowo podpisywane obiekty), ale wymaga większej dyscypliny inżynierskiej.

Z praktycznego punktu widzenia wiele organizacji będzie używało Kyber + Dilithium jako domyślnego zestawu. FALCON ma szansę pojawić się tam, gdzie presja na rozmiar i wydajność jest najwyższa, ale na początkowym etapie migracji często wywołuje lekkie uniesienie brwi działu audytu kryptograficznego.

Podpisy oparte na funkcjach haszujących – SPHINCS+

SPHINCS+ to ciekawy wyjątek na tle „kratowego mainstreamu”. Nie opiera się na nowych, skomplikowanych problemach algebraicznych, lecz na dobrze znanych funkcjach skrótu. Jego główne zalety to:

• bardzo konserwatywna baza kryptograficzna (hash-e są dobrze rozumiane),
• brak bezpośredniego powiązania z jedną rodziną trudnych problemów matematycznych,
• możliwość traktowania jako „ostatnia linia obrony”, gdyby np. schematy kratowe doczekały się istotnego osłabienia.

Minusy są równie wyraziste: duże rozmiary podpisów i kluczy oraz relatywnie wysoka cena wydajnościowa. SPHINCS+ ma sens tam, gdzie liczba podpisów jest ograniczona, rozmiar nie stanowi głównego problemu, a wymagana jest możliwie największa niezależność od konkretnych problemów matematycznych. Przykładem mogą być: podpisy aktualizacji firmware’u w urządzeniach infrastruktury krytycznej czy dokumenty o wyjątkowo długim okresie ważności.

Algorytmy kodowe, opartych na isometriiach i inne egzotyki

Standardyzacja nie kończy się na kratkach i hash-ach. W dalszych etapach procesu NIST oraz w środowisku akademickim analizowane są także:

• schematy kodowe (np. oparte na kodach Goppa czy LDPC), które kiedyś były poważnym kandydatem do standaryzacji, ale często przegrywają przez ogromne klucze publiczne,
• schematy oparte na izometrii kodów czy innych, bardziej egzotycznych problemach,
• różne warianty konstrukcji hybrydowych oraz adaptacji istniejących protokołów do nowych prymitywów.

Dla przeciętnego zespołu bezpieczeństwa kluczowe jest, by nie przywiązywać się emocjonalnie do jednej rodziny algorytmów. Dziś kratki wydają się dominujące, ale historia kryptografii pokazuje, że modne kierunki potrafią się zmieniać. Architektura systemów powinna zakładać możliwość włączenia kolejnego „dziwnego” algorytmu za pięć–dziesięć lat bez paraliżowania całej organizacji.

Kryteria wyboru algorytmów do konkretnych zastosowań

W praktyce wybór nie polega na zadaniu „który algorytm jest najlepszy?”, tylko „który algorytm jest wystarczająco bezpieczny i znośny w naszych realiach?”. Przy projektowaniu warto zestawić kilka kryteriów:

• Model przeciwnika i horyzont czasowy – czy zakładamy silnego przeciwnika państwowego? Na ile lat dane muszą pozostać poufne?
• Profil wydajnościowy – liczba operacji na sekundę, opóźnienia dopuszczalne w protokole, możliwości CPU/GPU/akceleratorów.
• Rozmiary kluczy i podpisów – istotne szczególnie przy PKI (bazy certyfikatów, CRL/OCSP) i w protokołach z ciasnymi limitami MTU.
• Dojrzałość implementacji – dostępność stabilnych bibliotek, wsparcie w HSM-ach, certyfikacje (FIPS, Common Criteria).
• Zgodność regulacyjna – czy algorytm jest wskazany (lub chociaż nieodradzany) przez lokalnych regulatorów i instytucje branżowe.

Przykład z życia: bank planuje wymianę infrastruktury podpisu kodu dla aplikacji mobilnych. Wybiera Dilithium dla procesów związanych z publikacją aplikacji w sklepach (bo podpisy są sprawdzane rzadko), a dla wewnętrznych mikrousług pozostaje chwilowo przy ECDSA, czekając na stabilne profile hybrydowe zalecane przez regulatora. Dla firmware’u bankomatów rozważa z kolei SPHINCS+, bo aktualizacje są rzadkie, a kluczowy jest długi horyzont bezpieczeństwa.

Hybrydowe szyfrowanie: pomost między światem klasycznym a postkwantowym

Na czym polega podejście hybrydowe

Hybrydowe mechanizmy kryptograficzne łączą w jednym protokole:

• klasyczny algorytm, np. ECDH czy RSA/ECDSA,
• algorytm postkwantowy, np. Kyber czy Dilithium.

Chodzi o to, aby uzyskać bezpieczeństwo „co najmniej tak dobre, jak silniejszy ze składników”. Jeśli PQC okazałby się osłabiony, nadal chroni nas warstwa klasyczna; jeśli pojawi się użyteczny komputer kwantowy, klasyczny komponent przestanie być wiarygodny, ale postkwantowy pozostanie trudny do złamania.

W wymianie kluczy oznacza to typowo, że obie strony:

• wykonują standardową wymianę ECDH (np. X25519),
• równolegle wykonują kapsułkowanie klucza przy użyciu KEM PQC (np. Kyber),
• łączą (np. konkatenacja + KDF) oba sekrety w jeden klucz sesyjny.

Analogicznie dla podpisów: komunikat może być podpisany zarówno klasycznym algorytmem (ECDSA), jak i postkwantowym (Dilithium), a protokół definiuje zasady weryfikacji i interpretacji wyniku (np. wymagany sukces obu weryfikacji albo dopuszczalny sukces co najmniej jednego).

Zalety i problemy podejścia hybrydowego

Z perspektywy bezpieczeństwa hybryda wygląda jak rozsądny pas bezpieczeństwa i poduszka powietrzna w jednym aucie. Przynosi jednak kilka praktycznych wyzwań.

Korzyści:

• redukcja ryzyka kryptograficznego – awaria jednej rodziny algorytmów nie oznacza automatycznego kompromitowania wszystkich kanałów;
• płynna migracja – można stopniowo włączać i wyłączać kolejne komponenty, testując zachowanie systemów i klientów;

• łatwiejsza komunikacja z interesariuszami – dział ryzyka, regulator czy audytorzy widzą, że organizacja nie „stawia wszystkiego na jedną kartę”, lecz stosuje dwa niezależne filary bezpieczeństwa.

Problemy:

• złożoność implementacyjna – dwa stosy kryptograficzne to dwa razy więcej kodu, ścieżek błędów i potencjalnych luk (zwłaszcza w warstwie integracji),
• wzrost narzutu – większe handshake, dodatkowe obliczenia, bardziej rozbudowane certyfikaty i struktury kluczy,
• skomplikowane scenariusze awaryjne – trzeba jasno zdefiniować, co się dzieje, gdy weryfikacja jednego z podpisów się nie powiedzie albo jedna część wymiany klucza zawiedzie.

Przykładowy problem z życia: organizacja wdrożyła hybrydowe TLS w oparciu o eksperymentalne rozszerzenie, ale część starszych urządzeń sieciowych „wykłada się” na większych komunikatach ClientHello. Zespół bezpieczeństwa jest zadowolony, zespół sieciowy – znacznie mniej. Bez dokładnego testowania i pilotażu w reprezentatywnym środowisku produkcyjnym łatwo o taki zgrzyt.

Jak projektować i wdrażać hybrydy w realnych systemach

Projektując hybrydę, dobrze jest zacząć nie od katalogu algorytmów, tylko od mapy systemów. Które kanały są krytyczne pod względem poufności i długiego horyzontu bezpieczeństwa? Gdzie margines wydajności jest na tyle duży, że dodatkowy narzut nie zaboli? Odpowiedzi na te pytania zwykle pokazują, że hybryda ma sens najpierw w:

• kanałach administracyjnych i zarządczych (VPN-y, panele administracyjne, dostęp do systemów kluczowych),
• infrastrukturze PKI i podpisu kodu,
• integracjach B2B z partnerami o podwyższonych wymaganiach regulacyjnych.

Kolejny krok to wybór konkretnych kombinacji. Pragmatyczne pary na dziś to chociażby X25519 + Kyber dla wymiany kluczy oraz ECDSA + Dilithium dla podpisów. Warto ustandaryzować kilka „profilów kryptograficznych” na poziomie organizacji (np. profil konserwatywny, profil wysokowydajny) i przypisać je do klas systemów. Dzięki temu uniknie się sytuacji, w której każdy projekt wdraża własną, niepowtarzalną hybrydę, trudną potem w utrzymaniu.

Niezależnie od wyboru algorytmów, kluczowa jest obserwowalność. Systemy monitoringu powinny rejestrować, jakie zestawy kryptograficzne są faktycznie używane, jak często klient „spada” do wariantu bez komponentu PQC oraz jakie są opóźnienia i odsetek błędów w handshake. Te dane pozwalają z czasem podnosić poprzeczkę – np. wymusić hybrydę dla wszystkich nowych klientów, a klasykę pozostawić wyłącznie jako tryb kompatybilności.

Na końcu cała „postkwantowa rewolucja” sprowadza się do solidnego rzemiosła: inwentaryzacji, planowania, pilotaży i spokojnej migracji krok po kroku. Komputery kwantowe mogą odmienić krajobraz kryptografii, ale dla większości organizacji największym wyzwaniem nie będzie sama matematyka, tylko logistyka zmiany – i to na nią dobrze przeznaczyć większość energii już dziś.

Migracja do szyfrowania postkwantowego w istniejących organizacjach

Mapa kryptografii – bez inwentaryzacji ani rusz

Przejście na algorytmy postkwantowe przypomina remont w starym domu: jeśli nie wiesz, gdzie idą kable, prędzej czy później coś wyłączysz nie tam, gdzie trzeba. Pierwszym etapem jest więc szczegółowa inwentaryzacja miejsc użycia kryptografii. W praktyce to połączenie pracy analitycznej, skanów i „archeologii systemowej”.

Lista obszarów, które zwykle wychodzą w takiej mapie:

• warstwa transportowa – TLS/DTLS w usługach webowych, API, brokerach wiadomości, kanałach mobilnych,
• VPN i tunelowanie – IPsec, SSL VPN, SSH w kanałach administracyjnych,
• PKI i zarządzanie tożsamością – CA, OCSP, CRL, certyfikaty dla urządzeń i użytkowników, S/MIME,
• szyfrowanie danych w spoczynku – dyski, bazy danych, backupy, archiwa,
• podpisy kodu i kontenery – łańcuch dostaw oprogramowania, repozytoria pakietów i obrazów,
• urządzenia brzegowe i IoT – routery, sensory, sterowniki, kasy, bankomaty, drukarki (tak, one też potrafią mieć TLS z 2009 roku).

Po samej liście miejsc przychodzi czas na katalog prymitywów kryptograficznych. Dobrą praktyką jest udokumentowanie, gdzie dokładnie występuje:

• jakiego typu protokoły (np. TLS 1.2 vs 1.3, SSHv2),
• które algorytmy asymetryczne (RSA-2048, P-256, X25519),
• jakie algorytmy symetryczne i HMAC (AES-GCM, ChaCha20-Poly1305, SHA-256/384),
• jakie są czas życia kluczy i certyfikatów (rotacja dzienna, roczna, „na zawsze”).

Na tej bazie da się już oznaczyć systemy „kwantowo wrażliwe”, czyli takie, w których przechwycenie ruchu dziś może się przełożyć na odczytanie treści za kilkanaście lat. Typowo to systemy kadrowo-płacowe, medyczne, finansowe, R&D oraz kanały administracyjne.

Priorytetyzacja: gdzie włączyć PQC jako pierwsze

Przy samej inwentaryzacji łatwo ugrzęznąć. Potrzebny jest więc prosty model priorytetów, który pomoże zdecydować, gdzie i kiedy włączać komponenty postkwantowe. Sprawdza się trójkąt:

• długość wymaganej poufności (np. dane muszą być tajne 15+ lat),
• wrażliwość danych (czy naruszenie grozi karami, szantażem, utratą przewagi konkurencyjnej),
• dostępność komponentów PQC dla danego stosu/protokołu.

Nierzadko okazuje się, że kanały administracyjne oraz podpisy kodu wskakują do koszyka „pilne”, natomiast część kanałów B2C – dopiero później. Przykładowo: publiczny portal informacyjny z treściami marketingowymi raczej nie potrzebuje PQC w pierwszej fali, ale serwer aktualizacji aplikacji mobilnych banku – już tak.

Przy ustalaniu priorytetów bardzo pomaga tabela z kolumnami: system, typ danych, horyzont poufności, aktualny stos kryptograficzny, gotowe opcje PQC/hybrydy, planowana data migracji. Brzmi biurokratycznie, ale bez takiej „księgowości” szybko robi się chaos.

Harmonogram migracji – myślenie w cyklach, nie w „big bangach”

Kryptografia lubi ewolucję, nie rewolucję. Znacznie rozsądniej zbudować cykliczny plan niż jednorazowy „projekt migracja postkwantowa 2027–2028”. Praktyczny model to trzy równoległe strumienie:

1. Eksperymenty i pilotaże – testowe wdrożenia PQC/hybryd w wybranych, kontrolowanych systemach.
2. Migracja głównych kanałów – zastosowanie sprawdzonych wcześniej profili kryptograficznych do systemów o najwyższej ważności.
3. Sprzątanie i wyłączanie starych opcji – usuwanie nieużywanych algorytmów, starych wersji protokołów, niepotrzebnych fallbacków.

Każdy z tych strumieni ma własne tempo i nie ma przeszkód, by biegły przez lata. Istotne jest tylko, aby regularnie (np. co kwartał) weryfikować, czy nowe rekomendacje NIST/ETSI/IETF nie zmieniają kolejności działań, ani nie podważają wybranych profili.

Wymagania regulacyjne i oczekiwania klientów

Regulatorzy, standardy branżowe i „miękkie” wytyczne

Postkwantowa kryptografia zaczyna coraz wyraźniej przewijać się w dokumentach regulatorów. Na początku pojawia się zwykle w formie zachęty w stylu „prosimy mieć plan”, ale z czasem przechodzi w konkretne wymagania audytowe. Przykłady trendów:

• sektor finansowy – wytyczne nadzorców dotyczące odporności na ataki z opóźnioną dekrpycją („store now, decrypt later”),
• administracja publiczna – rekomendacje dotyczące stosowania PQC w kanałach wymiany danych między urzędami oraz w kraju–chmura,
• sektor medyczny – rosnące naciski na „długowieczne” szyfrowanie dokumentacji pacjentów i wyników badań.

Do tego dochodzą dokumenty typu ENISA, EBA, ISO, PCI, które rzadko wprost narzucają nazwę algorytmu, ale opisują wymogi co do procesu: analiza ryzyka, plan migracji, okresowe przeglądy stosowanych prymitywów, testowanie odporności na nowe klasy ataków. PQC staje się w nich naturalnym elementem „dobrych praktyk” – i trudno będzie się wytłumaczyć, że „słyszeliśmy, ale nic nie zrobiliśmy”.

Kontrakty B2B i klienci instytucjonalni

Nawet jeśli lokalny regulator jeszcze śpi, kontrahenci raczej nie. Coraz częściej w RFP i kontraktach B2B pojawiają się pytania wprost:

• czy Państwa systemy są przygotowane na włączenie algorytmów postkwantowych?
• jakie są planowane daty migracji dla krytycznych kanałów komunikacji?
• czy macie Państwo proces przeglądu stosowanych algorytmów?

Stąd realna korzyść biznesowa z posiadania jawnej strategii PQC – nawet, jeśli faktyczne wdrożenia są jeszcze na wczesnym etapie. Z punktu widzenia klienta instytucjonalnego różnica między „pracujemy nad tym, tu jest roadmapa” a „jeszcze o tym nie myśleliśmy” jest dość zasadnicza.

Dokumentacja jako element „dowodu dbałości”

Mało kto lubi pisać polityki bezpieczeństwa, ale w obszarze PQC da się wyciągnąć z tego konkretną wartość. Dobrze przygotowane dokumenty, takie jak:

• polityka doboru algorytmów kryptograficznych,
• standard profili kryptograficznych (np. „profil PQC-hybrydowy”, „profil przejściowy”),
• procedury aktualizacji i testów,

pozwalają w razie audytu lub incydentu pokazać, że organizacja nie ignorowała problemu. To nie jest „biurokracja dla compliance”, ale istotny element zarządzania ryzykiem – szczególnie tam, gdzie decyzje kryją się po latach, a osoby decyzyjne dawno zmieniły pracodawcę.

Wyzwania techniczne: implementacja, sprzęt i wydajność

Biblioteki kryptograficzne i łańcuchy zależności

Na poziomie kodu migracja sprowadza się często do pytania: czy nasza biblioteka już wspiera PQC? „Duże” stosy kryptograficzne dodają wsparcie stopniowo, najpierw w formie eksperymentalnych rozszerzeń. Do typowych problemów należą:

• różnice API – nowe algorytmy mogą mieć inne modele (np. KEM zamiast „gołego” RSA), co komplikuje integrację,
• brak wsparcia w starszych wersjach – upgrade OpenSSL czy BoringSSL pociąga za sobą kaskadę zmian w aplikacjach i systemach operacyjnych,
• wielość implementacji – dla tego samego algorytmu istnieje kilka bibliotek (referencyjna, zoptymalizowana, sprzętowo przyspieszona) o różnych interfejsach i gwarancjach bezpieczeństwa.

Rozsądnym kompromisem jest wybranie jednej–dwóch „kanonicznych” bibliotek na organizację, z jasnym procesem oceny bezpieczeństwa i aktualizacji. Lepiej mieć jeden, dobrze rozumiany stos PQC niż pięć różnych opartych na stackoverflow-driven development.

HSM-y, moduły sprzętowe i „zimny prysznic” rzeczywistości

Świat PQC w HSM-ach i innych modułach sprzętowych rozwija się wolniej niż w oprogramowaniu. Powody są proste: dłuższe cykle certyfikacji (FIPS, CC), mniejsza elastyczność układów oraz ryzyko, że algorytm wypadnie z łask tuż po wypaleniu go w krzemie.

Typowy scenariusz w dużej organizacji:

• HSM-y wspierają RSA, ECDSA, ECDH, ewentualnie EdDSA,
• nowe algorytmy postkwantowe są implementowane „poza” HSM, a HSM służy tylko do kotwiczenia tożsamości (np. podpisuje certyfikaty z kluczami PQC),
• w dłuższej perspektywie planowana jest modernizacja sprzętu, ale pod warunkiem stabilizacji standardów i profili regulatorów.

To wymusza konstrukcje, w których klucze PQC żyją częściowo w świecie software’owym, a klasyczne klucze – w HSM. Dobrze jest wtedy jasno określić, jakie mechanizmy ochrony kluczy PQC są stosowane (separacja procesów, ograniczone uprawnienia, monitorowanie dostępu, hardening OS), aby uniknąć sytuacji, w której nowy algorytm staje się „słabym ogniwem” tylko dlatego, że mieszka poza bezpiecznym modułem.

Profilowanie wydajności i budżet na narzut

Jednym z najczęstszych pytań biznesu jest: „ile to będzie wolniejsze?”. Odpowiedź niestety brzmi: to zależy. Inne profile ma PGSQL z TLS i mutual auth, inne – serwer API w chmurze obsługujący krótkie połączenia. Zanim pojawi się panika, warto przeprowadzić realne pomiary:

• porównanie czasów handshake i liczby obsłużonych połączeń przy klasyce vs hybrydzie (np. X25519+Kyber),
• testy wielkości komunikatów (ClientHello, certyfikaty, wymiana kluczy) w typowych scenariuszach,
• wpływ na zużycie pamięci i CPU w backendach o dużej liczbie równoległych sesji.

Doświadczenie pokazuje, że w większości zastosowań biznesowych narzut jest akceptowalny, a problemem okazują się raczej stare urządzenia po drodze, dziwne limity MTU albo archaiczne load balancery, które nie radzą sobie z większymi nagłówkami. Profilowanie pozwala wyłapać te przypadki zanim klienci zgłoszą, że „aplikacja działa wolniej, ale nie wiemy czemu”.

Aspekty organizacyjne: ludzie, procesy i edukacja

Zespół bezpieczeństwa jako „tłumacz” między matematyką a biznesem

Mało który zarząd będzie chciał słuchać o kratkach, kodach i izometrach. Zespół bezpieczeństwa musi więc pełnić rolę tłumacza: przekuć zagrożenie kwantowe na język ryzyk, kosztów i planów. Kilka praktycznych zasad:

• pokazywać horyzont czasowy zamiast straszyć „jutro nas złamią”,
• opisywać konkretne scenariusze („przechwycona dziś korespondencja R&D może być czytelna za 15 lat”),
• przedstawiać etapowy plan działań z budżetem i miernikami sukcesu (np. % ruchu zabezpieczonego hybrydowo).

Do tego przydaje się umiejętność powiedzenia „nie wiemy jeszcze” w sposób akceptowalny biznesowo: z opisem warunków, kiedy decyzje zostaną podjęte (np. po finalizacji standardów NIST, po pilotażu w danej linii biznesowej).

Szkolenia i podnoszenie kompetencji

Kryptografia postkwantowa nie powinna być „czarną magią” dostępną tylko dla jednej osoby w organizacji. Nawet podstawowe szkolenia dla developerów i architektów potrafią zmniejszyć ryzyko spektakularnych wpadek. Warto w nich omówić:

• czym różnią się KEM-y od klasycznego RSA w kontekście API,
• dlaczego hybryda to nie po prostu „dwa razy to samo tylko obok”,
• jak testować poprawność i wydajność nowych profili kryptograficznych,
• jak reagować na nowe informacje o podatnościach w algorytmach PQC.

Przy bardziej technicznych zespołach sprawdza się model „wewnętrznej społeczności kryptografii”: regularne sesje typu brown bag, krótkie notatki techniczne po większych konferencjach (RSA, Real World Crypto, standardyzacja NIST), a czasem wewnętrzny kanał na komunikatorze, gdzie inżynierowie mogą wrzucać pytania i linki. To dużo skuteczniejsze niż jednorazowe, odhaczone w LMS „szkolenie o kwantach”, po którym wszyscy pamiętają tylko, że nazwy algorytmów brzmią jak postaci z gier.

Zmiana procesów i „wpięcie” PQC w codzienną pracę

Sam entuzjazm nie wystarczy, jeśli procesy pozostaną w trybie „robimy tak od 10 lat”. Elementy związane z PQC dobrze jest dołożyć do istniejących mechanizmów, a nie tworzyć osobne, równoległe światy. Przy przeglądach architektury pojawia się więc proste pytanie: czy ten system ma zdefiniowaną ścieżkę migracji do profilu postkwantowego lub hybrydowego? W backlogach zespołów deweloperskich można utrzymywać dedykowane epiki na dostosowanie do nowych bibliotek i protokołów, zamiast liczyć, że „jakoś się to zmieści przy okazji innego projektu”.

Analogicznie w procesach change managementu łatwo dodać kilka pól w ticketach: jaki profil kryptograficzny stosuje dana zmiana, czy wymaga nowych ustawień po stronie HSM, czy wpływa na zgodność z wewnętrzną polityką PQC. Dzięki temu ryzyko „cichego” wdrożenia niekompatybilnego komponentu spada, a zespół bezpieczeństwa widzi, co się dzieje, zanim trafi to na produkcję.

Relacja z dostawcami i podwykonawcami

W wielu firmach prawdziwe ryzyko leży poza murami organizacji – w produktach i usługach dostawców. Dobrą praktyką jest włączenie wymagań związanych z PQC do umów, RFP i checklist zakupowych. Zamiast ogólnego „spełniacie najlepsze praktyki kryptograficzne”, lepiej zadać kilka konkretnych pytań: czy produkt ma roadmapę wsparcia PQC, jakie algorytmy są planowane, jak wygląda polityka aktualizacji, czy istnieją publiczne raporty z audytów kryptograficznych.

W relacjach z mniejszymi vendorami przydaje się odrobina elastyczności: czasem akceptowalne jest tymczasowe użycie klasycznych algorytmów, jeśli dostawca ma realistyczny harmonogram wdrożenia hybrydy i nie próbuje chować głowy w piasek. Brak dialogu zwykle kończy się gorzej niż wspólnie ustalony kompromis z jasną datą graniczną.

Monitorowanie, przegląd i „żywa” strategia

Strategia postkwantowa szybko się dezaktualizuje, jeśli nikt do niej nie zagląda. Kilka prostych mechanizmów utrzymuje ją przy życiu: kwartalne lub półroczne przeglądy profili kryptograficznych, monitorowanie rekomendacji NIST, ETSI, IETF i krajowych regulatorów, a także progi decyzyjne typu „jeśli dany algorytm trafi na listę odradzanych – w ciągu X miesięcy przygotowujemy plan migracji”.

Dobrze działa powiązanie stanu przygotowania do PQC z istniejącymi miernikami bezpieczeństwa: obok procentu systemów z aktualnymi łatami można śledzić odsetek krytycznych kanałów, które obsługują profil hybrydowy, albo liczbę systemów zidentyfikowanych jako „niezdolne do migracji bez wymiany komponentów”. To pomaga traktować temat kwantów nie jak ciekawostkę z konferencji, lecz normalny element inżynierskiego długu technicznego – do spłacenia, zanim zacznie rosnąć z odsetkami.

Komputery kwantowe nie wyłączą z dnia na dzień dzisiejszego internetu, ale już dziś wymuszają trzeźwe spojrzenie na to, jak długo chcemy ufać obecnym fundamentom kryptografii. Organizacje, które zaczną układać strategię, porządkować profile i testować hybrydy, potraktują przyszły „przeskok” raczej jako kontrolowaną migrację infrastruktury niż nerwową akcję ratunkową pod presją czasu i nagłówków w mediach.

Najczęściej zadawane pytania (FAQ)

Czy komputery kwantowe naprawdę złamią RSA i obecne szyfrowanie?

Tak, przy wystarczająco dużym i stabilnym komputerze kwantowym algorytmy takie jak RSA, klasyczny Diffie–Hellman i większość rozwiązań opartych na krzywych eliptycznych (ECC) przestaną być bezpieczne. Wynika to z algorytmu Shora, który pozwala efektywnie rozwiązywać problemy matematyczne będące fundamentem tych systemów.

Nie oznacza to jednak, że „jutro wszystko padnie”. Dzisiejsze komputery kwantowe są zbyt słabe: mają mało kubitów i wysoki poziom błędów. Branża bezpieczeństwa zakłada jednak, że w horyzoncie 10–30 lat może pojawić się sprzęt, który realnie zagrozi tym standardom – dlatego przygotowania zaczynają się już teraz.

Co to znaczy „harvest now, decrypt later” i czy powinienem się tego bać?

„Harvest now, decrypt later” to model ataku, w którym ktoś już dziś masowo przechwytuje i archiwizuje ruch szyfrowany (HTTPS, VPN, e-mail), nie potrafi go od razu odszyfrować, ale zakłada, że zrobi to za kilkanaście lat, gdy pojawią się mocne komputery kwantowe. Wtedy „odkorkowuje” zebrane dane i czyta je jak otwartą książkę.

Problem jest szczególnie istotny dla danych, które muszą pozostać tajne przez długi czas: dokumentacja medyczna, dane wywiadowcze, tajemnice handlowe, długoterminowe umowy. Jeżeli ochraniasz coś, co ma wartość dłużej niż 10–15 lat, to ten scenariusz nie jest science fiction, tylko punkt na liście ryzyk.

Jakie algorytmy i standardy szyfrowania są najbardziej zagrożone przez komputery kwantowe?

Najbardziej zagrożona jest kryptografia asymetryczna oparta na faktoryzacji i logarytmie dyskretnym, czyli przede wszystkim:

• RSA (używany w certyfikatach TLS, podpisach kodu, PGP, S/MIME),
• klasyczny Diffie–Hellman,
• kryptografia oparta na krzywych eliptycznych (ECC), np. ECDH, ECDSA.

To właśnie te mechanizmy stoją za certyfikatami TLS/HTTPS, większością VPN-ów, podpisami kodu, infrastrukturą PKI w firmach czy bezpieczną pocztą. Kryptografia symetryczna (np. AES) jest w dużo lepszej sytuacji – algorytm Grovera „osłabia” ją, ale można się obronić, przechodząc na dłuższe klucze (np. 256-bitowe).

Czy muszę już teraz wymieniać wszystkie certyfikaty i systemy na postkwantowe?

Na dzisiaj nie ma potrzeby nerwowego wyrzucania RSA i ECC do kosza, ale odkładanie planowania migracji „na później” to proszenie się o kłopoty. Sensowne podejście to:

• zrobienie inwentaryzacji – gdzie i jak używasz kryptografii asymetrycznej (TLS, VPN, PKI, podpisy kodu),
• ocena, które dane muszą pozostać poufne >10–15 lat,
• śledzenie standardów kryptografii postkwantowej (PQC) – np. zaleceń NIST i producentów sprzętu/oprogramowania.

Prawdziwe „przekręcanie przełącznika” na algorytmy postkwantowe to proces na lata: testy, pilotaże, wdrożenia hybrydowe (stare + nowe algorytmy). Kto zacznie dopiero wtedy, gdy kwanty będą już gotowe, obudzi się z bardzo długą listą rzeczy do poprawy.

Na czym polega różnica między wpływem komputerów kwantowych na RSA a na AES?

RSA (i podobne algorytmy asymetryczne) dostają od komputerów kwantowych „cios nokautujący”: algorytm Shora teoretycznie pozwala całkowicie złamać bezpieczeństwo przy wystarczającej mocy obliczeniowej. Mając klucz publiczny, atakujący może odtworzyć klucz prywatny.

W przypadku szyfrowania symetrycznego, jak AES, sytuacja jest łagodniejsza. Algorytm Grovera przyspiesza atak brute force do pierwiastka z liczby możliwych kluczy. W praktyce oznacza to, że bezpieczeństwo AES-128 spada do poziomu mniej więcej 64 bitów. Rozsądne rozwiązanie jest proste: używać dłuższych kluczy (AES-256), które pozostają odporne nawet przy uwzględnieniu przyspieszenia kwantowego.

Jak firmy mogą przygotować się na „Q-day”, czyli moment zagrożenia ze strony komputerów kwantowych?

Przygotowanie to głównie praca organizacyjna i architektoniczna, a nie zakup „magicznego pudełka PQC”. Sensowny plan zwykle obejmuje:

• mapę użycia kryptografii w organizacji (TLS, VPN, PKI, IoT, podpisy kodu, backupy),
• klasyfikację danych pod kątem czasu, przez jaki muszą pozostać poufne,
• wdrażanie silnego forward secrecy tam, gdzie to możliwe,
• pilotażowe wdrażanie rozwiązań hybrydowych (klasyczne + postkwantowe algorytmy) zgodnie z rekomendacjami standardów.

Dobrym nawykiem jest też wybieranie dostawców, którzy już teraz mają plan na kryptografię postkwantową. „Kupimy coś, jak będzie trzeba” to strategia, która w bezpieczeństwie zwykle kończy się telefonem o trzeciej w nocy.

Czy zwykły użytkownik internetu powinien się przejmować kryptografią postkwantową?

Na poziomie indywidualnego użytkownika główne działania są pośrednie: aktualne przeglądarki, systemy operacyjne, korzystanie z HTTPS, VPN z aktualnym oprogramowaniem. Migracją na postkwantowe standardy zajmą się głównie dostawcy usług, banki, administracja publiczna czy duże firmy.

Jeśli jednak przechowujesz bardzo wrażliwe dane przez długie lata (np. dokumentacja zdrowotna, dane klientów kancelarii, projekty badawcze), sensowne jest pytanie dostawców usług o ich plany dotyczące szyfrowania postkwantowego. Delikatne dopytywanie o PQC potrafi zdziałać cuda w priorytetach działów IT.

Najważniejsze punkty

• Dzisiejsze komputery kwantowe są jeszcze prototypowe i nie łamią RSA ani ECC, ale tempo rozwoju jest na tyle wysokie, że zakładanie „to nas nie dotyczy” jest zwyczajnie ryzykowne.
• Algorytm Shora zagraża całej współczesnej kryptografii asymetrycznej (RSA, Diffie–Hellman, ECC, standardowe podpisy cyfrowe), bo pozwala z klucza publicznego skutecznie wyliczyć klucz prywatny na wydajnym komputerze kwantowym.
• Algorytm Grovera osłabia kryptografię symetryczną i funkcje hashujące, ale problem można w praktyce zminimalizować, zwiększając długość kluczy (np. przechodząc z 128 na 256 bitów).
• Infrastruktura internetu – TLS/HTTPS, VPN-y, PKI, podpisy kodu i część szyfrowania e-mail – stoi dziś na RSA i ECC, więc pojawienie się wystarczająco mocnego komputera kwantowego umożliwi podszywanie się pod serwery i ludzi oraz łamanie historycznych nagrań ruchu.
• Atak „harvest now, decrypt later” oznacza, że istotny szyfrowany ruch jest już teraz masowo przechwytywany i archiwizowany z myślą o przyszłym odszyfrowaniu, gdy komputery kwantowe dojrzeją.
• Kluczowe pytanie nie brzmi „kiedy dokładnie pojawi się Q-day”, tylko jak długo konkretne dane muszą pozostać poufne – jeśli mówimy o latach lub dekadach (np. dokumentacja medyczna), zagrożenie kwantowe jest bardzo realne.
• Migracja do kryptografii postkwantowej powinna być planowana już teraz jako świadoma inwestycja w przyszłe bezpieczeństwo, a nie nerwowa reakcja, gdy „pierwszy kwantowy potworek” pojawi się publicznie.

Źródła

• Report on Post-Quantum Cryptography. National Institute of Standards and Technology (2016) – Przegląd zagrożeń kwantowych i kierunków standaryzacji PQC
• Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process. National Institute of Standards and Technology (2022) – Aktualny stan prac nad standardami kryptografii postkwantowej
• Communications Security Establishment – Quantum‑safe cryptography. Communications Security Establishment – Przegląd wpływu komputerów kwantowych na kryptografię i migrację do PQC
• ENISA Post‑Quantum Cryptography: Current state and quantum mitigation. European Union Agency for Cybersecurity (2021) – Raport ENISA o zagrożeniach kwantowych i strategiach łagodzenia
• Quantum Computing and Post‑Quantum Cryptography. National Security Agency (2022) – Stanowisko NSA w sprawie zagrożeń kwantowych i planów przejścia na PQC
• Quantum Threat Timeline Report. Global Risk Institute (2020) – Szacunki ekspertów dotyczące horyzontu czasowego „Q‑day”
• Shor’s Algorithm for Quantum Factorization. Reviews of Modern Physics (1997) – Oryginalny opis algorytmu Shora i jego znaczenia dla RSA i logarytmu dyskretnego
• A fast quantum mechanical algorithm for database search. Proceedings of the 28th Annual ACM Symposium on Theory of Computing (1996) – Praca Grovera opisująca algorytm przyspieszający przeszukiwanie kluczy
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. Internet Engineering Task Force (2018) – Specyfikacja TLS 1.3, forward secrecy i użycie RSA/ECDHE w praktyce