Post-quantum cryptography: jak przygotować systemy na erę kwantową

0
51
3.5/5 - (2 votes)

Nawigacja:

Po co w ogóle myśleć o kryptografii postkwantowej już teraz

Realne zagrożenie: co dokładnie zrobi komputer kwantowy z RSA i ECC

Kryptografia, na której stoi dzisiejszy Internet, bezpieczeństwo bankowości i podpisy elektroniczne, opiera się głównie na dwóch rodzinach algorytmów asymetrycznych: RSA oraz kryptografii krzywych eliptycznych (ECC). Ich bezpieczeństwo wynika z trudności dwóch problemów: faktoryzacji dużych liczb (RSA) oraz logarytmu dyskretnego (ECC). Na komputerach klasycznych te problemy są praktycznie nierozwiązywalne w rozsądnym czasie przy obecnych długościach kluczy.

Komputery kwantowe wprowadzają do gry zupełnie inny model obliczeń. Algorytm Shora potrafi rozkładać duże liczby na czynniki pierwsze i rozwiązywać logarytm dyskretny w czasie wielomianowym. W praktyce oznacza to, że wystarczająco duży i stabilny komputer kwantowy mógłby:

  • odtworzyć klucz prywatny z publicznego klucza RSA lub ECC,
  • podsłuchiwać i odszyfrowywać ruch TLS, VPN, SSH,
  • fałszować podpisy cyfrowe (kod, dokumenty, certyfikaty),
  • łamac zabezpieczenia wielu kryptowalut i rozwiązań blockchain.

Bezpośredni skutek: tracimy poufność oraz integralność. Hasła, tokeny, tajemnice handlowe czy dane zdrowotne mogą zostać wstecznie odszyfrowane, a podpisy uznane za niewiarygodne, jeśli nie będą odpowiednio „zakotwiczone” w czasie (np. przez zewnętrzne znaczniki czasu i regenerację podpisów).

„Harvest now, decrypt later”: dzisiejsze szyfrowanie jako magazyn przyszłych danych

Praktycy bezpieczeństwa coraz częściej mówią o modelu ataku „harvest now, decrypt later”. W skrócie: przeciwnik nie musi dziś łamać kryptografii. Wystarczy, że:

  • masowo zbiera i archiwizuje zaszyfrowane dane (ruch sieciowy, pliki, bazy danych),
  • gromadzi publiczne klucze, certyfikaty i podpisane dokumenty,
  • czeka, aż pojawi się praktyczny komputer kwantowy,
  • wtedy dopiero odszyfrowuje lub fałszuje to, co zebrał wcześniej.

To podejście jest szczególnie groźne dla danych o długim cyklu życia. Chodzi o informacje, które:

  • muszą pozostać poufne przez 10–30 lat lub dłużej,
  • po ujawnieniu za kilka–kilkanaście lat nadal mogą wyrządzić szkody.

Przykłady takich danych:

  • dane medyczne – historia chorób, wyniki badań, dane DNA,
  • dane wojskowe i wywiadowcze – plany operacji, dane o infrastrukturze krytycznej,
  • własność intelektualna – projekty technologiczne, kod źródłowy, receptury,
  • dane biometryczne – w przeciwieństwie do haseł, twarzy czy linii papilarnych nie da się „zmienić”.

Jeżeli dane o horyzoncie bezpieczeństwa 20 lat szyfruje się dziś RSA/ECC, a komputer kwantowy zdolny do ich złamania pojawi się za 10 lat, to są już dziś w strefie ryzyka. Właśnie dlatego migracja do kryptografii postkwantowej nie jest problemem roku, w którym „oficjalnie” ktoś ogłosi kwantowy atak, tylko procesem rozłożonym na dekadę.

Ryzyko dziś kontra „okno migracji”

Dla racjonalnej decyzji nie liczy się sam fakt, że „kiedyś” pojawi się duży komputer kwantowy, tylko relacja trzech czasów:

  • czas życia danych – jak długo poufność ma realnie znaczenie,
  • czas migracji – ile lat potrzeba, aby organizacja wymieniła algorytmy, biblioteki, urządzenia,
  • czas dojścia technologii kwantowej – kiedy komputery kwantowe osiągną parametry potrzebne do złamania RSA/ECC.

Jeśli:

  • dane muszą być chronione 15 lat,
  • migracja infrastruktury zajmie 5–7 lat (w dużych organizacjach to sensowny szacunek),
  • a zagrożenie kwantowe na poziomie „łamiemy RSA-2048” pojawi się za np. 10–15 lat,

to dziś organizacja w praktyce wchodzi w okno migracji. Brak decyzji oznacza, że część aktualnie tworzonych danych będzie możliwa do złamania w ich cyklu życia.

Prawdziwym przeciwnikiem nie jest więc sam komputer kwantowy, tylko inercja infrastruktury. Routery, moduły HSM, systemy wbudowane, aplikacje legacy, zależności od dostawców – wszystko to sprawia, że wymiana protokołów i algorytmów to projekt na lata, nie miesiące.

Kiedy „poczekajmy na masowe komputery kwantowe” ma sens, a kiedy szkodzi

Popularna rada brzmi: „nie ma jeszcze komputerów kwantowych łamiących RSA, więc poczekajmy, aż rynek dojrzeje”. To podejście bywa rozsądne, ale tylko w ściśle określonych scenariuszach.

Kiedy „poczekajmy” jest zrozumiałe:

  • krótkotrwałe projekty POC, pilotaże trwające 3–6 miesięcy,
  • małe systemy wewnętrzne, które szybko się wycofuje lub przepisać,
  • środowiska testowe, gdzie klucze i dane nie opuszczają bezpiecznego labu.

W takich przypadkach kombinacja krótkiego czasu życia danych i niskiej wartości informacji powoduje, że koszt wczesnej migracji przewyższa zysk. Można spokojnie skupić się na porządkowaniu architektury i przygotowaniu do skalowalnej zmiany w przyszłości.

Kiedy „poczekajmy” jest wręcz niebezpieczne:

  • długoterminowe systemy transakcyjne (banki, ubezpieczenia, administracja),
  • systemy gromadzące archiwa dokumentów, nagrania, logi prawnie istotne,
  • infrastruktura krytyczna i sieci przemysłowe,
  • firmy operujące na danych zdrowotnych, biometrycznych, IP.

W tych domenach „poczekajmy” oznacza tyle, co oddajmy w ciemno przyszłe dane przeciwnikowi. Paradoksalnie, brak komputerów kwantowych dzisiaj to właśnie powód, aby zacząć projektować migrację, gdy presja czasowa jeszcze nie zabija jakości decyzji.

Czynnik regulacyjny i reputacyjny: dlaczego zarządy pytają o post-quantum cryptography

Ryzyko kwantowe to nie tylko technika. Wchodzi tu wymiar regulacyjny, kontraktowy i reputacyjny. Coraz częściej w branżach regulowanych pojawiają się pytania:

  • czy organizacja ma plan migracji do kryptografii postkwantowej,
  • jakie dane o długim cyklu życia są dziś narażone na „harvest now, decrypt later”,
  • czy dostawcy chmury, systemów bezpieczeństwa i infrastruktury uwzględniają PQC w roadmapach.

Dla zarządów i rad nadzorczych PQC jest coraz częściej elementem zarządzania ryzykiem strategicznym, a nie „fanaberią działu IT”. Ryzykowna staje się nie tylko luka techniczna, ale i percepcja braku działania: w razie ujawnienia długoterminowych danych po ataku kwantowym bardzo trudno będzie obronić tezę, że „nikt nie mógł tego przewidzieć”.

Regulatorzy też przesuwają ciężar z reaktywności na due diligence: jeśli branża od lat dyskutuje o zagrożeniu, a organizacja przez ten czas nie zrobiła nic poza „śledzeniem tematu”, trudno liczyć na wyrozumiałość po incydencie. W wielu sektorach (finanse, telekom, energetyka) pytanie o gotowość kwantową będzie równie standardowe, jak dziś pytanie o kopie zapasowe.

Minimum teorii: jak działa kryptografia, którą komputery kwantowe potrafią złamać

Kryptografia symetryczna, asymetryczna i funkcje skrótu – praktyczne rozróżnienie

W świecie post-kwantowym przydaje się proste rozdzielenie trzech filarów kryptografii:

  • kryptografia symetryczna – ten sam klucz do szyfrowania i deszyfrowania (AES, ChaCha20). Szybka, używana do szyfrowania dużych wolumenów danych, backupów, dysków, ruchu sieciowego po ustanowieniu klucza,
  • kryptografia asymetryczna – inny klucz do szyfrowania, inny do odszyfrowania (RSA, ECC). Używana głównie do:
    • wymiany kluczy symetrycznych (np. w TLS, VPN),
    • podpisów cyfrowych (dokumenty, kod, certyfikaty),
    • autentykacji (logowanie, SSH, niektóre protokoły federacyjne).
  • funkcje skrótu (hash) – przekształcają dane w skrót o stałej długości (SHA-256, SHA-3). Używane do:
    • sprawdzania integralności danych,
    • budowy podpisów cyfrowych,
    • tworzenia struktur typu blockchain, logi nieodwracalne.

Komputery kwantowe nie uderzają równomiernie we wszystkie te mechanizmy. Najmocniejsze uderzenie kierują w kryptografię asymetryczną, którą opieramy na problemach algebraicznych wrażliwych na algorytm Shora. Symetryka i hash’e są „tylko” osłabiane przez algorytm Grovera.

Dlaczego Shor niszczy RSA i ECC, a Grover tylko przyspiesza ataki na szyfry symetryczne

Algorytm Shora jest kluczowy dla zrozumienia, dlaczego mówimy o końcu RSA/ECC w obecnej formie. W skrócie: problemy, na których opierają się te systemy (faktoryzacja, logarytm dyskretny), mają na komputerach klasycznych super-wielomianową złożoność, co powoduje, że przy dużych kluczach atak jest praktycznie nierealny.

Shor na komputerze kwantowym redukuje te problemy do czasu wielomianowego. W efekcie:

  • RSA-2048, uznawane dziś za bezpieczne, jest teoretycznie do złamania w czasie praktycznym na odpowiednio dużym komputerze kwantowym,
  • analogicznie – większość stosowanych dziś krzywych eliptycznych.

Algorytm Grovera dotyczy innego scenariusza: przyspiesza przeszukiwanie przestrzeni możliwych kluczy lub pre-obrazów funkcji hash. Dla szyfrów symetrycznych oznacza to w uproszczeniu, że efektywnie skraca długość klucza o połowę. Klucz 128-bitowy na komputerze klasycznym ma siłę 128 bitów, a w obliczu Grovera – jakby 64 bity. Dlatego pod kątem erze kwantowej zwykle:

  • zaleca się używanie AES-256 zamiast AES-128,
  • dobiera się funkcje skrótu z odpowiednią długością wyjścia (np. SHA-256 lub mocniejsze).

Kluczowa różnica: symetrykę i hash’e można „ratować” zwiększając długości kluczy/skrótów, natomiast dla RSA/ECC w znanym dziś kształcie nie istnieje prosty „bezpieczny wariant”. Stąd potrzeba zupełnie nowych rodzin algorytmów – kryptografii postkwantowej.

Gdzie dokładnie siedzą podatne algorytmy: mapa typowego ekosystemu IT

Atak kwantowy nie uderzy w pojedynczy „moduł szyfrujący”, ale w cały ekosystem wykorzystujący kryptografię asymetryczną. W wielu organizacjach nawet nie ma pełnej listy miejsc, gdzie używane jest RSA czy ECC. Kilka najważniejszych obszarów:

  • TLS/HTTPS – wymiana kluczy (ECDHE, RSA), uwierzytelnienie serwera (certyfikaty X.509),
  • VPN (IPsec, TLS VPN, WireGuard) – wymiana kluczy i autentykacja w tunelach,
  • e-mail – S/MIME, PGP/GPG, podpisy i szyfrowanie wiadomości,
  • podpisy kodu – podpisy binariów, pakietów, bibliotek (Windows, Linux, aplikacje mobilne),
  • podpisy dokumentów – kwalifikowane podpisy elektroniczne, podpisy wewnętrzne na umowach,
  • blockchain i kryptowaluty – mechanizmy podpisów transakcji, kluczy portfeli.

Dodatkowo kryptografia asymetryczna bywa głęboko wbudowana w komponenty, o których rzadko się myśli:

  • moduły HSM i karty kryptograficzne,
  • urządzenia sieciowe (routery, zapory, load balancery),
  • systemy IAM i federacji tożsamości (SAML, OIDC, OAuth),
  • Protokoły uwierzytelniania i aktualizacji – ciche miejsca zależne od RSA/ECC

    Jednym z bardziej podstępnych obszarów są mechanizmy, które „po prostu działają” w tle. Do czasu, aż nagle nie ma jak ich bezboleśnie wymienić.

  • Aktualizacje oprogramowania (OTA/firmware) – podpisy binariów urządzeń IoT, sterowników, systemów wbudowanych. Często zaszyte w ROM-ie lub bootloaderze, bez możliwości zmiany schematu podpisu bez fizycznej ingerencji.
  • Tokeny sprzętowe i klucze FIDO/U2F – wykorzystują krzywe eliptyczne do uwierzytelniania. Przejście na PQC wymaga nowego sprzętu lub co najmniej nowej generacji firmware’u certyfikowanego w bardziej rygorystycznym procesie.
  • Protokoły M2M (machine-to-machine) – szczególnie w przemyśle i energetyce. Wiele implementacji ma „zaszyte” profile kryptograficzne w standardach (np. IEC, OPC UA), których zmiana to proces wieloletni.

Slogan „podmieńmy bibliotekę kryptograficzną” nie obejmuje miejsc, w których algorytm jest częścią kontraktu lub standardu. To właśnie tam planów migracji najczęściej brakuje, a to one będą decydowały, czy przełączanie na PQC potrwa miesiące, czy dekadę.

Stare biurko z maszyną do pisania z napisem quantum computing
Źródło: Pexels | Autor: Markus Winkler

Przegląd podejść post-kwantowych: kratki, kody, hash’e i inne „potworki”

Kryteria oceny: co naprawdę odróżnia „kandydatów” PQC od produkcyjnych rozwiązań

Zanim zaczną się pojawiać nazwy typu CRYSTALS-Kyber czy Dilithium, przydaje się prosty filtr. Kandydaci algorytmów postkwantowych są oceniani nie tylko pod kątem bezpieczeństwa matematycznego. W praktyce liczy się także:

  • dojrzałość analizy kryptograficznej – jak długo i jak intensywnie społeczność próbowała je złamać,
  • koszt implementacji – rozmiary kluczy, podpisów, ciphertextów, zapotrzebowanie na pamięć i obliczenia,
  • odporność na ataki bocznokanałowe – timing, pobór mocy, cache, szczególnie w sprzęcie,
  • prostota konstrukcji – im mniej „magii” i subtelnych założeń, tym łatwiej bronić rozwiązania przed audytem i regulatorem.

Popularna rada „bierzmy po prostu to, co wybrał NIST” jest częściowo słuszna, ale nie zawsze wystarczająca. Na przykład w środowiskach najmocniej ograniczonych sprzętowo (sensory, karty, stare HSM-y) nawet standardowe algorytmy NIST mogą okazać się zbyt ciężkie lub trudne do wdrożenia bez naruszenia certyfikacji.

Kratki (lattice-based): główny koń pociągowy kryptografii postkwantowej

Kryptografia oparta na kratach jest dziś najbardziej perspektywicznym źródłem algorytmów KEM (wymiana kluczy) i podpisów cyfrowych. Bazuje na problemach typu LWE/MLWE (Learning With Errors) i ich wariantach strukturalnych.

Najważniejsze cechy tej rodziny:

  • elastyczność parametrów – można dostosowywać poziom bezpieczeństwa przez dobór rozmiarów macierzy, dystrybucji błędów itp.,
  • wydajność – dobre kompromisy prędkości i rozmiarów w typowych scenariuszach (TLS, VPN, podpisy kodu),
  • duża aktywność badawcza – równocześnie plus i minus: z jednej strony intensywny peer review, z drugiej – większa szansa na odkrycie subtelnych słabości.

Standardowe przykłady wyłonione w procesie NIST:

  • CRYSTALS-Kyber – KEM rekomendowany jako domyślny mechanizm wymiany kluczy postkwantowych,
  • CRYSTALS-Dilithium – podpis cyfrowy, często rozpatrywany jako „domyślny” PQC-signature,
  • Falcon – podpis z mniejszymi podpisami, ale bardziej wymagający implementacyjnie.

Kontrariańska uwaga: kratki są dziś „złotym dzieckiem” PQC. Entuzjazm bywa tak duży, że w projektach architektonicznych ignoruje się scenariusz, w którym za kilka lat pojawia się silny atak teoretyczny na dane klasy problemów LWE. Dlatego w projektach o bardzo długim horyzoncie (archiwa państwowe, dokumentacja medyczna przechowywana dziesiątki lat) sensownie jest rozważyć kombinacje: kratki plus druga, niezależna rodzina (np. hash-based signatures do podpisów kluczowych artefaktów).

Kody i kryptografia kodowa: weteran z dużym bagażem

Algorytmy oparte na kodach korekcyjnych (McEliece i pochodne) są jednymi z najstarszych propozycji kryptografii postkwantowej. Ich atutem jest to, że „leżą na stole” od dekad i wciąż nie doczekały się praktycznego ataku kwantowego.

Główne zalety:

  • długa historia analiz – to podoba się konserwatywnym regulatorom i branżom typu obronność,
  • prosty model bezpieczeństwa – trudność dekodowania losowych kodów liniowych.

I tu pojawia się haczyk. Klasyczne schematy kodowe mają <strongogromne klucze publiczne – rzędu setek kilobajtów, a nawet megabajtów. W zastosowaniach bazujących na certyfikatach X.509, protokołach mobilnych czy kartach płatniczych to realny problem projektowy, nie drobiazg.

Dlatego kodowe KEM-y rozpatruje się głównie w niszach:

  • specjalizowane łącza o stałej konfiguracji,
  • rozwiązania, gdzie jedno urządzenie ma dużo mocy i pamięci (serwer), a drugie jest prostsze (klient),
  • systemy, w których preferowana jest „stara szkoła” bezpieczeństwa nawet kosztem wydajności.

Podpisy oparte na funkcjach skrótu: proste, twarde, lecz nieporęczne

Hash-based signatures (HBS) to często niedoceniany filar kryptografii postkwantowej. Ich siła polega na tym, że opierają się wyłącznie na bezpieczeństwie funkcji hash – czyli obszarze relatywnie dobrze rozumianym, bez wyrafinowanej algebry.

Przykłady wyłonione przez NIST to m.in. SPHINCS+. Charakterystyka tej rodziny:

  • konserwatywne założenia – jeśli SHA-256 (lub analogiczna funkcja) jest odporna kryptograficznie, schemat podpisu ma duże szanse pozostać bezpieczny także w erze kwantowej (po uwzględnieniu Grovera),
  • brak potrzeby przechowywania dużych tajnych struktur – inaczej niż w części rozwiązań kratowych.

Cena tego konserwatyzmu to:

  • duże rozmiary podpisów – w porównaniu z RSA/ECC, a często także z podpisami kratowymi,
  • wysokie koszty obliczeniowe – generowanie i weryfikacja podpisów są cięższe, szczególnie na słabszym sprzęcie.

Są jednak scenariusze, w których HBS są wręcz naturalnym wyborem:

  • podpisywanie kluczowych artefaktów o niskiej częstotliwości – np. root CA, firmware krytycznych urządzeń, aktualizacje systemów bezpieczeństwa,
  • środowiska, gdzie regulator lub klient wymaga „najbardziej konserwatywnego” podejścia, nawet za cenę wydajności.

Multivariate, isogeny i inne egzotyki: kiedy trzymać je w laboratorium

Poza kratkami, kodami i hash-based signatures istnieje cały szereg mniej mainstreamowych rodzin: systemy multivariate (wielomiany nad ciałami skończonymi), isogeny krzywych eliptycznych i inne konstrukcje algebraiczne.

Przykład z ostatnich lat: algorytm SIKE (oparty na isogeniach supersingularnych) był długo uważany za mocnego kandydata, aż został spektakularnie złamany klasycznym atakiem. To pokazuje, jak szybko może się zmienić percepcja bezpieczeństwa w mniej poznanych rodzinach.

Popularne w kręgach badawczych hasło „dywersyfikujmy ryzyko, używając kilku różnych klas algorytmów” ma sens, ale:

  • nie warto przenosić eksperymentalnych schematów do produkcji masowej,
  • jeśli organizacja nie ma zespołu kryptografów badawczych, trudno będzie racjonalnie oceniać bieżące publikacje o bezpieczeństwie takich rozwiązań.

Rozsądna alternatywa: stosować dywersyfikację wewnątrz rodzin uznanych – np. kilka parametrów lub wariantów zatwierdzonych algorytmów kratowych i hash-based, zamiast skakać po egzotycznych konstrukcjach, które zmieniają status z „obiecujących” na „złamane” w jednym artykule naukowym.

Hybrid modes: łączenie klasycznej kryptografii z PQC – kiedy ma sens

Coraz częściej dostawcy proponują tryby hybrydowe: w jednym protokole używa się zarówno klasycznej kryptografii (RSA/ECDHE), jak i postkwantowej (np. Kyber). Klucz sesyjny jest wtedy pochodną obu tajemnic.

To podejście bywa przedstawiane jako „złoty środek”: jeśli klasyczny algorytm padnie ofiarą Shora, pozostaje bezpieczeństwo PQC; jeśli w PQC znajdzie się błąd konstrukcyjny, zostają filary klasyczne. W praktyce:

  • ma sens w okresie przejściowym, szczególnie w protokołach internetowych (TLS, IPsec),
  • pomaga w dialogu z ostrożnymi regulatorami: „nie rzucamy się na nowinkę, tylko stopniowo doklejamy PQC”.

Kiedy hybryda szkodzi:

  • w systemach o silnych ograniczeniach wydajnościowych – koszt dwóch mechanizmów na raz może być nieakceptowalny,
  • gdy zespół nie ma zasobów, by zrozumieć i testować bardziej złożone ścieżki błędów – hybryda potrafi skomplikować implementację i obsługę wyjątków.

Dlatego w małej lub średniej organizacji rozsądniejszą strategią bywa:

  1. wprowadzić PQC w nowych systemach (tam, gdzie można zaprojektować architekturę od zera),
  2. stosować hybrydy w krytycznym ruchu zewnętrznym (np. TLS do klientów),
  3. pozostawić systemy wewnętrzne na klasycznych algorytmach, ale z jasnym planem stopniowej wymiany.

Standardy i rekomendacje: na czym się opierać, żeby nie wymyślać koła na nowo

NIST PQC: co już jest wybrane, a co jeszcze się zmienia

Proces standaryzacji NIST dla kryptografii postkwantowej jest dziś głównym punktem odniesienia na świecie. W obszarze wymiany kluczy i podpisów można już mówić o wyraźnych „faworytach”, nawet jeśli dokumenty formalne są jeszcze w finalizacji.

Dla praktyków kluczowe jest odróżnienie dwóch poziomów:

  • status algorytmu – wybrany do standaryzacji (selected), kandydat rezerwowy (alternate), odrzucony,
  • status implementacyjny – czy istnieją stabilne, audytowane biblioteki, wsparcie w HSM, modułach TLS, VPN, narzędziach podpisu kodu.

Popularna porada „czekajmy, aż NIST opublikuje ostateczne standardy” brzmi dobrze, ale ma dwie pułapki:

  1. W momencie publikacji standardów dostawcy będą dopiero nadrabiać implementacje i certyfikacje. Pierwsze 2–3 lata to okres „doganiania papieru”.
  2. Jeśli organizacja nie przygotuje się wcześniej architektonicznie (abstrakcja warstwy kryptograficznej, inventory kluczy, polityki), to nawet świetne standardy NIST nie skrócą realnego czasu migracji.

Rozsądne podejście: już teraz projektować systemy z myślą o wtykowej warstwie kryptograficznej (crypto agility), ale parametry i konkretne algorytmy ustawiać zgodnie z bieżącymi rekomendacjami NIST i krajowych instytucji (np. NASK, ENISA, ANSSI – w zależności od jurysdykcji).

IETF, ETSI i branżowe profile: TLS, VPN, 5G, IoT

Nawet najlepszy algorytm pozostaje ciekawostką, dopóki nie ma profilu protokołu, który definiuje, jak go faktycznie używać. Tu na scenę wchodzi m.in. IETF i ETSI.

  • IETF – prace nad rozszerzeniami TLS (np. hybrydowe mechanizmy wymiany kluczy), IPsec, SSH. Dla dostawców chmurowych i sieciowych to de facto mapa drogowa.
  • ETSI – profiluje zastosowania w telekomunikacji, 5G, IoT i środowiskach operatorskich. Dla operatorów sieci i producentów sprzętu telekomunikacyjnego to często ważniejsze dokumenty niż same standardy NIST.

Z perspektywy organizacji użytkownika końcowego bardziej liczy się, czy:

Najczęściej zadawane pytania (FAQ)

Co to jest kryptografia postkwantowa i czym różni się od „tradycyjnej”?

Kryptografia postkwantowa (PQC) to rodzina algorytmów zaprojektowanych tak, aby pozostały bezpieczne nawet wtedy, gdy pojawią się duże, stabilne komputery kwantowe. Chodzi głównie o zamienniki dla dzisiejszych algorytmów asymetrycznych, takich jak RSA i kryptografia krzywych eliptycznych (ECC), które są podatne na algorytm Shora.

Klasyczna kryptografia asymetryczna opiera się na problemach faktoryzacji liczb i logarytmu dyskretnego – trudnych dla komputerów klasycznych, ale podatnych na przyspieszenie kwantowe. Algorytmy postkwantowe bazują na innych trudnościach matematycznych (np. kratowe, kodowe, opierające się na izogeniach), dla których jak dotąd nie znamy efektywnych algorytmów kwantowych.

Dlaczego trzeba myśleć o kryptografii postkwantowej już teraz, skoro nie ma jeszcze takich komputerów?

Kluczowe są trzy czasy: jak długo dane muszą pozostać tajne, ile lat zajmie Twojej organizacji wymiana algorytmów oraz kiedy realnie pojawi się komputer kwantowy zdolny złamać RSA/ECC. Jeśli czas życia danych plus czas migracji „wchodzą” w horyzont pojawienia się zagrożenia kwantowego, to zwlekanie oznacza, że część obecnie szyfrowanych informacji będzie możliwa do złamania w ich cyklu życia.

Dodatkowo istnieje model ataku „harvest now, decrypt later”: przeciwnik już dziś masowo zbiera zaszyfrowane dane i certyfikaty, żeby odszyfrować je za 10–15 lat. Dotyczy to szczególnie danych medycznych, wojskowych, własności intelektualnej czy biometrii – czyli wszystkiego, co nie „przeterminowuje się” po roku.

Na co konkretnie pozwoli duży komputer kwantowy – co jest zagrożone?

Duży, stabilny komputer kwantowy wyposażony w algorytm Shora mógłby odtworzyć klucze prywatne z kluczy publicznych RSA i ECC. Przekłada się to na możliwość podsłuchiwania i odszyfrowywania ruchu TLS, VPN czy SSH, fałszowania podpisów cyfrowych pod dokumentami, kodem i certyfikatami oraz łamania zabezpieczeń wielu kryptowalut i rozwiązań blockchain.

Skutek jest podwójny: tracimy poufność (treść komunikacji, tajemnice handlowe, dane zdrowotne) oraz integralność (nie wiemy, czy podpisy i certyfikaty faktycznie pochodzą od nadawcy i nie zostały podmienione). Jeśli dziś podpisujesz długoterminowe umowy elektronicznie, problem jest bardziej praktyczny niż teoretyczny.

Czy zagrożona jest także kryptografia symetryczna (np. AES) i funkcje skrótu (SHA-256)?

Kryptografia symetryczna i funkcje skrótu mają inny profil ryzyka. Algorytm Grovera przyspiesza ataki brute-force na klucze symetryczne i kolizje hashy, ale nie tak dramatycznie jak Shor na RSA/ECC. W praktyce oznacza to konieczność stosowania mocniejszych parametrów, a nie całkowitą wymianę paradygmatu.

Dobrym podejściem jest:

  • wydłużanie kluczy symetrycznych (np. AES-256 zamiast AES-128),
  • stosowanie nowoczesnych funkcji skrótu (SHA-256, SHA-3) z odpowiednimi długościami,
  • skupienie głównego wysiłku migracyjnego na wymianie algorytmów asymetrycznych (wymiana kluczy, podpisy).

Popularny strach „komputer kwantowy złamie wszystko” jest więc nadmiarowy – główny problem dotyczy RSA/ECC i infrastruktury klucza publicznego.

Na czym polega atak „harvest now, decrypt later” i kogo dotyczy najbardziej?

Atak „harvest now, decrypt later” polega na tym, że napastnik nie próbuje dzisiaj łamać szyfrowania. Zamiast tego masowo archiwizuje zaszyfrowany ruch, pliki, bazy danych oraz zbiera publiczne klucze i podpisy cyfrowe, licząc na to, że w przyszłości złamie RSA/ECC komputerem kwantowym i odszyfruje lub sfałszuje zgromadzony materiał.

Najbardziej zagrożone są podmioty pracujące z danymi:

  • o długim cyklu życia (10–30 lat),
  • których ujawnienie za wiele lat wciąż będzie szkodliwe – np. dane zdrowotne, wojskowe, projekty technologiczne, kod źródłowy, dane biometryczne.

Jeśli jesteś w branży medycznej, finansowej, obronnej lub R&D, to ryzyko dotyczy Twoich dzisiejszych decyzji projektowych, a nie abstrakcyjnej „przyszłości”.

Czy naprawdę muszę już wdrażać kryptografię postkwantową, czy mogę spokojnie poczekać?

„Poczekajmy, aż rynek dojrzeje” ma sens tylko w krótkotrwałych, niskokrytycznych projektach: POC-ach trwających kilka miesięcy, małych systemach wewnętrznych, które łatwo przepisać, oraz w środowiskach testowych z danymi nieopuszczającymi labu. Tam ryzyko, że ktoś będzie za 10–20 lat łamał te konkretne dane, jest niewielkie, więc lepiej skupić się na uproszczeniu architektury i zbieraniu doświadczeń.

Natomiast w długoterminowych systemach transakcyjnych (banki, ubezpieczenia, administracja), archiwach dokumentów, infrastrukturze krytycznej czy systemach przetwarzających dane zdrowotne i biometryczne strategia „poczekajmy” oznacza de facto oddanie przyszłych danych napastnikowi. Tu rozsądniej jest założyć, że migracja potrwa kilka lat i zacząć od mapowania, które komponenty wymagają PQC, zanim pojawi się presja czasowa.

Od czego zacząć przygotowanie organizacji do kryptografii postkwantowej?

Najsensowniejsze pierwsze kroki są mało „technologiczne”, a bardzo inwentaryzacyjne. Zamiast od razu szukać „magicznej biblioteki PQC”, zacznij od:

  • identyfikacji danych o długim cyklu życia i wysokiej wrażliwości,
  • audytu, gdzie i jak używane są RSA/ECC (protokoły, biblioteki, urządzenia, HSM-y),
  • oszacowania, ile realnie potrwa wymiana tych elementów, zwłaszcza w systemach legacy.

Na tej podstawie można zaprojektować etapowy plan: pilotaże PQC w mniej krytycznych obszarach, wymagania „post-quantum ready” w umowach z dostawcami oraz politykę regenerowania i kotwiczenia podpisów dla długoterminowych dokumentów. Technologia zdąży dojrzeć, ale tylko jeśli infrastruktura będzie już gotowa na jej przyjęcie.