Post-Quantum TLS: ECDHE + ML-KEM w praktyce

8 grudnia 2025 w Aktualności, Bezpieczeństwo, HEXSSL Insight

Kryptografia post-kwantowa już nie jest odległą wizją – stała się elementem realnej migracji infrastruktury bezpieczeństwa Internetu. Hybrydowy TLS 1.3, łączący klasyczne ECDHE z post-kwantowym ML-KEM (zalecanym przez NIST), jest pierwszym produkcyjnym krokiem w stronę odporności na ataki kwantowe. To nie kosmetyczna zmiana: to fundamentalna przebudowa sposobu, w jaki obliczany jest sekret sesji TLS. Zamiast pojedynczego źródła klucza, otrzymujemy dwa – klasyczne i post-kwantowe – które są łączone przez HKDF, dając odporność zarówno na współczesne komputery, jak i przyszłe systemy kwantowe.

W praktyce oznacza to większe wiadomości handshake, nową strukturę ClientHello/ServerHello, obsługę podwójnych keyshare’ów, a w wielu przypadkach konieczność modernizacji load balancerów, CDN-ów, firewalli oraz całych stosów TLS używanych przez aplikacje SaaS i urządzenia IoT. Największym wyzwaniem stały się nie same algorytmy, lecz infrastruktura: MTU, limity CRYPTO frames w QUIC, pamięć w IoT, różnice w implementacjach OpenSSL 3.2, BoringSSL, AWS-LC i WolfSSL, a także kompatybilność z certyfikatami hybrydowymi, które potrafią osiągać rozmiar kilkunastu kilobajtów.

PQTLS to etap przejściowy – w latach 2025-2030 większość rynku przejdzie z ECDHE na hybrydy, a następnie na czyste PQC. CA muszą przygotować nowe łańcuchy certyfikacji, hostingi muszą zaktualizować stos TLS, SaaS będzie musiał wdrożyć PQC-ready w komunikacji B2B i internal-mesh, a sektor publiczny już prowadzi migrację do profili TLS zgodnych z NIST. Firmy, które wprowadzą PQTLS teraz, zapewnią sobie kompatybilność, przewagę technologiczną i zgodność z przyszłymi regulacjami. Firmy, które zwlekają, będą musiały wykonać tę samą pracę w panice, gdy przeglądarki i systemy regulowane zaczną wymagać minimalnego profilu PQ-ready. PQTLS nie jest opcją – jest fundamentem bezpieczeństwa transportowego na kolejną dekadę.

Spis Treści

Wprowadzenie: Dlaczego potrzebujemy post-quantum TLS?

W 2025 roku internet stoi u progu największej zmiany kryptograficznej od dwóch dekad. Od momentu, gdy NIST ogłosił zwycięskie algorytmy post-kwantowe (ML-KEM jako KEM i ML-DSA jako podpis), stało się jasne, że obecny model TLS – oparty na ECDHE oraz ECDSA – musi przejść transformację.

Zagrożenie: harvest now, decrypt later

Atakujący nie potrzebuje dziś komputera kwantowego, aby naruszyć przyszłą poufność danych. Wystarczy, że:

zapisze zaszyfrowany ruch TLS,
poczeka kilka lat,
użyje kwantowego algorytmu Shora do złamania ECDHE oraz ECDSA.

To oznacza, że wszystkie dane przesyłane dziś z użyciem standardowego TLS mogą być w przyszłości odszyfrowane. Dotyczy to w szczególności:

bankowości,
medycyny,
telemetrii IoT,
firm korporacyjnych,
infrastruktury państwowej,
komunikacji między usługami (mTLS).

Dlaczego nie przejść od razu na algorytmy PQC?

Bo:

przeglądarki nie obsługują jeszcze w 100% natywnego PQC,
biblioteki TLS muszą zostać przebudowane,
część urządzeń IoT nie poradzi sobie z dużym narzutem ML-KEM,
ekosytem CA, CT Logs i ACME nie jest gotowy na certyfikaty czysto PQC.

Dlatego przejście następuje poprzez modele hybrydowe, gdzie bezpieczeństwo klasyczne i post-kwantowe współistnieją.
Celem nie jest zastąpienie ECDHE – lecz zduplikowanie bezpieczeństwa, aby złamanie jednego mechanizmu nie naruszało prywatności danych.

Co dokładnie zmienia ML-KEM?

ML-KEM (lepiej znany jako Kyber) to algorytm KEM oparty na strukturze kraty (lattice-based cryptography), którego bezpieczeństwo wynika z trudności plerfej problemów takich jak:

MLWE – Module Learning With Errors,
MLWR – Module Learning With Rounding.

W odróżnieniu od ECDHE, ML-KEM nie wykorzystuje logarytmów dyskretnych, lecz operacje na macierzach wielomianów w pierścieniach, które są odporne na Shora i jego przyszłe implementacje kwantowe.

Jak wygląda cel TLS w erze PQC?

Nie chcemy TLS, który działa albo klasycznie, albo kwantoodpornie. Chcemy TLS, który:

jest kompatybilny w dół,
jest odporny na ataki kwantowe,
nie eliminuje istniejącej infrastruktury,
nie wymaga wymiany wszystkich urządzeń IoT,
gwarantuje podwójne bezpieczeństwo handshake.

To właśnie oferuje model hybrydowego TLS 1.3 opartego o ECDHE + ML-KEM.

Jak działa ML-KEM (Kyber)? Matematyka, polinomy, wektory i implementacja

Post-Quantum TLS używa mechanizmu ML-KEM, znanego wcześniej jako Kyber – zwycięskiego algorytmu NIST w kategorii KEM (Key Encapsulation Mechanism). To fundament współczesnych hybrydowych handshaków TLS, ponieważ ML-KEM zapewnia odporność na komputery kwantowe, jednocześnie zachowując wysoką wydajność i niski narzut obliczeniowy.

Ta sekcja zawiera pełne wprowadzenie do matematyki ML-KEM, szczegółowe omówienie struktur wielomianowych, a także opis funkcji kem_keypair(), kem_enc() i kem_dec() używanych w TLS 1.3 Hybrid Handshake. Celem jest zrozumienie, dlaczego ML-KEM działa, jak działa i co dokładnie dzieje się w środku algorytmu.

3.1. Fundament: algebra pierścieni i problem MLWE

Kyber opiera się na wariancie problemu Module Learning With Errors (MLWE), czyli na obliczeniach wykonywanych w pierścieniu:

[
R = \mathbb{Z}_q[x]/(x^n + 1)
]

W praktyce używa się parametrów:

n = 256
q = 3329 – liczba pierwsza
moduł cyklotomiczny x²⁵⁶ + 1

Oznacza to, że operacje wykonywane są na wielomianach stopnia < 256 z współczynnikami modulo 3329.

W ML-KEM wszystko sprowadza się do operacji na:

macierzach wielomianów (A),
wektorach wielomianów (s, e),
iloczynach wielomianowych,
i dodawaniu losowych błędów.

Dlaczego to bezpieczne?

Algorytm Shora umożliwia łamanie ECDH/ECDSA w czasie wielomianowym – ale nie działa na problemy typu LWE/MLWE. Nawet komputer kwantowy nie jest w stanie rozwiązać MLWE w czasie polinomicznym, ani nawet sub-eksponencjalnym. To właśnie dlatego Kyber jest odporny na ataki kwantowe.

3.2. Struktura Kyber: parametry i warianty ML-KEM

NIST ustandaryzował trzy warianty:

Wariant	Bezpieczeństwo	Rozmiar klucza publicznego	Rozmiar ciphertext
ML-KEM-512	~128-bit	800 bytes	768 bytes
ML-KEM-768	~192-bit	1184 bytes	1088 bytes
ML-KEM-1024	~256-bit	1568 bytes	1568 bytes

W TLS używa się zazwyczaj ML-KEM-768, ponieważ zapewnia bezpieczeństwo klasy ECDHE P-384, ale jest szybszy i bardziej kompaktowy.

3.3. Podstawowe pojęcia ML-KEM

Wektor tajny (secret vector)

[
\mathbf{s} = [s_1, s_2, \dots, s_k] ]

gdzie każdy element to wielomian stopnia < 256.

Wektor błędu (error vector)

[
\mathbf{e} = [e_1, e_2, \dots, e_k] ]

dodawany do operacji, aby uzyskać bezpieczeństwo MLWE.

Macierz A

Publiczna macierz (k × k) generowana deterministycznie z użyciem SHAKE128/256.

Wynik działania MLWE

Iloczyn macierzy A i wektora s:

[
\mathbf{t} = A \cdot \mathbf{s} + \mathbf{e}
]

gdzie t jest częścią klucza publicznego.

Tak właśnie tworzy się klucz publiczny ML-KEM.

3.4. Funkcje ML-KEM: keypair, enc, dec

W ML-KEM istnieją trzy funkcje, z których TLS korzysta podczas hybrydowego handshaku:

1) `kem_keypair()` – generowanie klucza publicznego i prywatnego

Zwraca:

klucz publiczny: pk
klucz prywatny: sk

W praktyce:

Generowany jest sekret s i błąd e, próbki z rozkładu centrum binomialnego.
Generowana jest macierz A (k × k).
Obliczana jest:

[
\mathbf{t} = A \cdot \mathbf{s} + \mathbf{e}
]

Klucz publiczny to (A_seed, t)
Klucz prywatny to (s, H(pk), z), gdzie z to dodatkowa entropia.

2) `kem_enc()` – kapsulacja sekretu

Zwraca:

ciphertext ct
wspólny sekret ss

W skrócie:

Generowany jest nowy losowy wektor r.
Obliczana jest druga wersja MLWE:

[
\mathbf{u} = A \cdot \mathbf{r} + \mathbf{e’}
] [
v = \mathbf{t} \cdot \mathbf{r} + e” + \text{encode}(m)
]

Powstaje ciphertext ct = (u, v).
Obliczany jest sekret:

[
ss = H(\text{some data}, ct)
]

3) `kem_dec()` – dekapsulacja sekretu

Serwer, posiadając klucz prywatny s, wykonuje:

[
v – \mathbf{u} \cdot \mathbf{s} \approx m
]

Następnie odtwarza ss.

To właśnie ten sekret sesji później łączy się z sekretem ECDHE w hybrydowym handshake.

3.5. Implementacja ML-KEM w OpenSSL 3.2+

OpenSSL wprowadził ML-KEM jako provider, co oznacza, że ML-KEM jest dostępny przez:

EVP_PKEY_CTX *ctx;
EVP_PKEY *key;

oraz funkcje:

EVP_PKEY_keygen_init
EVP_PKEY_keygen
EVP_PKEY_encapsulate
EVP_PKEY_decapsulate

Przykładowy kod (uproszczony):

EVP_PKEY_CTX *kctx = EVP_PKEY_CTX_new_from_name(NULL, "ML-KEM-768", NULL);
EVP_PKEY *kem_key = NULL;

EVP_PKEY_keygen_init(kctx);
EVP_PKEY_keygen(kctx, &kem_key);

// Kapsulacja
EVP_PKEY_CTX *ectx = EVP_PKEY_CTX_new(kem_key, NULL);
unsigned char ct[2048];
unsigned char ss[64];
size_t ct_len, ss_len;

EVP_PKEY_encapsulate(ectx, ct, &ct_len, ss, &ss_len);

// Dekapsulacja
EVP_PKEY_decapsulate(ectx, ss_dec, &ss_dec_len, ct, ct_len);

W TLS biblioteki używają podobnych mechanizmów do wykonania ML-KEM w handshake.

3.6. Wydajność ML-KEM vs ECDHE

Dla ML-KEM-768:

keypair: ~100 µs
encapsulation: ~90 µs
decapsulation: ~110 µs
ECDHE P-256: ~40 µs
ECDHE P-384: ~70 µs

ML-KEM jest szybszy niż ECDHE P-384, co jest istotne dla hybrydowego TLS.

3.7. Bezpieczeństwo ML-KEM: analiza odporności

ML-KEM jest odporny na:

algorytm Shora,
algorytm Grovera,
ataki lattice reduction (BKZ, LLL),
ataki multi-target,
ataki subfield lattice,
side-channel attacks — dzięki NTT i maskowaniu.

Problemy, które NIST analizował, dotyczyły:

implementacji — nie matematyki,
kanałów bocznych,
twardszej parametryzacji ML-KEM-1024.

W efekcie ML-KEM jest jedynym algorytmem KEM, który ma realny konsensus całej branży.

Hybrydowy handshake TLS 1.3 (ECDHE + ML-KEM)

Hybrydowy handshake TLS 1.3 jest sercem całej transformacji post-kwantowej. W odróżnieniu od klasycznego TLS, gdzie budowa wspólnego sekretu opiera się wyłącznie na ECDHE, w wersji post-kwantowej klient i serwer przeprowadzają dwa równoległe mechanizmy wymiany kluczy — klasyczny oraz PQC — a następnie łączą oba wyniki w finalny joint_secret. W praktyce wygląda to tak, że cały handshake jest nadal pojedynczym procesem zgodnym z TLS 1.3, ale jego wewnętrzna semantyka zawiera dwie niezależne ścieżki kryptograficzne – eliptyczną i krato-opartą (lattice-based).

Najważniejsze jest zrozumienie, że protokołu TLS nie przepisano od nowa. Ramy wiadomości, struktury ClientHello i ServerHello, a także format KeyShare pozostały takie same. To, co uległo zmianie, to sposób kodowania wartości key_share_entry odpowiadających algorytmom PQC oraz logika, która mówi bibliotece TLS, że w handshake należy uwzględnić dwa sekrety zamiast jednego.

4.1. ClientHello z podwójnym KeyShare

Gdy klient inicjuje połączenie hybrydowe, nie wysyła jednego keyshare’a, lecz dwa równorzędne fragmenty danych kryptograficznych — jeden dla ECDHE, drugi dla ML-KEM. Klient traktuje obie metody jako opcje, które serwer może wykorzystać w procesie budowania tajnego materiału.

Z punktu widzenia pakietów TLS dzieje się coś bardzo ciekawego: w polu extensions ClientHello pojawiają się dwie struktury KeyShareEntry, każda reprezentująca inny algorytm. Nie jest to dodatkowa warstwa ani osobny protokół; to nadal klasyczny KeyShare, tylko zawierający dwa elementy. Wireshark pokazuje to jako dwie pozycje „KeyShareEntry”, a ich group_id wskazuje, z jakim algorytmem są powiązane.

Przykładowe wartości identyfikacyjne — czysto ilustracyjne — mogą wyglądać tak (Wireshark pokazuje identyfikatory jako grupy numeryczne lub OID-y, zależnie od wersji biblioteki):

jedna pozycja reprezentuje secp256r1 lub secp384r1,
druga reprezentuje ML-KEM-768.

Najważniejsze jest, że te dwie struktury istnieją obok siebie bez konfliktu. TLS 1.3 od początku zakładał możliwość wysyłania wielu keyshare’ów jednocześnie, aby klient nie musiał powtarzać handshaku, gdy serwer wspiera inny zestaw algorytmów. Hybrydowe TLS jedynie używa tego mechanizmu w sposób skoordynowany — klient oczekuje, że serwer skorzysta z obu.

4.2. ServerHello i wybór algorytmów przez serwer

Serwer odpowiada również dwoma KeyShareEntry — jednym klasycznym i jednym PQC. Nie następuje tu „negocjacja” w sensie porzucenia jednego algorytmu. W tradycyjnym TLS 1.3 serwer wybiera jedną grupę ECDHE spośród oferowanych przez klienta. W hybrydowym handshake wybór jest rozszerzony o zasadę: Jeżeli klient wysyła jednocześnie ECDHE i ML-KEM, a serwer wspiera oba, serwer musi odesłać oba keyshare’y.

W praktyce oznacza to, że serwer generuje:

eliptyczny ephemeral key (np. ECDHE-P384),
kapsułowanie ML-KEM (encapsulation), które tworzy pqc_ciphertext.

W przeciwieństwie do klasycznego TLS, gdzie serwer używa ECDHE: server_ephemeral = ECDHE(s), client_pkey), tutaj serwer musi dodatkowo wykonać kem_enc() po stronie PQC. W efekcie jego ServerHello również zawiera dwa fragmenty danych:

punkt na krzywej eliptycznej (publiczne „share” dla ECDHE),
ciphertext PQC wysyłany klientowi (część ML-KEM).

4.3. Wstępne sekrety: klasyczny i post-kwantowy

Po wymianie ClientHello/ServerHello obie strony posiadają odpowiednie dane do obliczenia dwóch odrębnych sekretów:

ECDHE_shared_secret
Jest tworzony poprzez wykonanie operacji eliptycznej DH:
[
Z_{ecdh} = x_{client} \cdot Y_{server}
] gdzie (x_{client}) to klucz prywatny klienta, a (Y_{server}) to ephemeral public key serwera.
ML-KEM_shared_secret
Ten sekret powstaje z dekapsulacji:
klient wykonuje kem_dec() używając ciphertextu z ServerHello oraz swojego klucza prywatnego ML-KEM.
W efekcie powstaje sekret:
[
Z_{kem} = \text{SS}_{decapsulated}
]

Ważne jest, że te dwa sekrety mają różne pochodzenie matematyczne: jeden powstał przez multiplikację punktów na krzywych eliptycznych, drugi przez operacje na wielomianach MLWE. Wyniki są w pełni niezależne kryptograficznie.

4.4. Łączenie sekretów: joint_secret i HKDF

W klasycznym TLS 1.3 istnieje tylko jeden sekret wejściowy do HKDF. W hybrydowym TLS stosuje się procedurę łączenia zgodną z draftem IETF PQTLS. Ma to postać:

[
\text{joint_secret} = HKDF_Extract(0, Z_{ecdh} | Z_{kem})
]

czyli oba sekrety są:

konkatenowane,
przepuszczane przez HKDF-Extract z kluczem zero (lub inną wartością wskazaną w definicji profilu handshake),
dalej wykorzystywane przez HKDF-Expand do produkcji kluczy handshake.

Ilość materiału wejściowego jest zatem większa niż w zwykłym TLS, natomiast wszystkie kolejne kroki pozostają identyczne: z joint_secret powstają handshake_traffic_keys, a później application_traffic_keys oraz eksportery.

To podejście jest genialne w swojej prostocie: nawet jeśli w przyszłości odkryto by słabość ML-KEM, ECDHE nadal stoi; jeśli zaś komputery kwantowe złamałyby ECDHE, ML-KEM chroni dane. Równoległość obu strumieni zapewnia przyszłościową odporność.

4.5. Hybrydowy handshake w Wireshark: co widać naprawdę?

Wireshark nie posiada jeszcze pełnej wizualizacji PQTLS jako osobnej kategorii, ale widoczne są kluczowe elementy:

ClientHello z dwoma KeyShareEntry,
ServerHello również z dwoma KeyShareEntry,
duży rozmiar odpowiedzi serwera (PQC ciphertext często dodaje 800–1500 bajtów),
standardowa sekwencja „EncryptedExtensions → Certificate → CertificateVerify → Finished”.

Cechą charakterystyczną hybrydowego TLS jest nagły wzrost rozmiaru wiadomości handshake, ale nic poza tym w strukturze protokołu się nie zmienia. Wireshark nie musi znać ML-KEM, by poprawnie zinterpretować jego pozycję w KeyShare; widzi ją jako kolejny algorytm DH lub „Unknown Key Share Group” — co nie przeszkadza w działaniu.

4.6. Co widzi administrator na serwerze i w logach bibliotek TLS?

W OpenSSL 3.2 oraz BoringSSL pojawiają się nowe logi dotyczące KEM:

informacje o załadowaniu providerów PQC,
generowaniu ML-KEM keypair dla klienta,
wykonaniu encapsulation (serwer),
dekapsulacji (klient).

Serwer korzystający z hybrydowego TLS ma rozszerzone ścieżki w kodzie handshake, w których konkatenowane są dwa sekrety przed podaniem ich do HKDF. W wielu implementacjach można zaobserwować, że biblioteka najpierw przetwarza ECDHE, a dopiero potem dołącza wynik PQC — ale kolejność nie ma znaczenia, ponieważ HKDF-Extract eliminuje wszelkie potencjalne zależności.

4.7. Dlaczego ten model jest bezpieczny?

Hybrydowy handshake zabezpiecza sesję na dwa sposoby jednocześnie. Aby odszyfrować ruch:

atakujący musiałby złamać ECDHE,
oraz ML-KEM,
a następnie odtworzyć joint_secret i przeprowadzić poprawne HKDF-Expand.

Nawet komputer kwantowy nie rozwiąże jednocześnie ECC i MLWE w praktycznym czasie.
Dlatego właśnie hybrydowy TLS jest dziś jedynym sensownym pomostem między światem klasycznym a pełnym post-kwantowym TLS.

Pseudokod hybrydowego handshaku TLS 1.3 oraz szczegółowy przepływ HKDF

Hybrydowy handshake TLS 1.3 jest w swojej strukturze elegancko prosty, choć składa się z dwóch równoległych procesów kryptograficznych. To nadal handshake TLS 1.3 — żadna część protokołu nie została przebudowana, ale jego semantyka została rozszerzona tak, aby zamiast jednego sekretu wygenerować dwa, a następnie użyć ich w połączonej postaci jako materiału wejściowego do HKDF. W tej sekcji analizujemy krok po kroku, jak biblioteki TLS interpretują dane, jak działa pseudokod generowania sekretów i w jaki sposób finalny joint_secret staje się źródłem kluczy handshake oraz kluczy aplikacji.

5.1. Logiczny przepływ hybrydowego handshaku

W klasycznym TLS 1.3 handshake można opisać następująco: klient wysyła ClientHello z jednym keyshare, serwer wybiera jedną grupę, wymienia dane ECDHE i obie strony uzyskują wspólny sekret. W wersji post-kwantowej proces wygląda identycznie z zewnątrz, ale wewnętrznie podwaja liczbę operacji.

W uproszczeniu cały proces można sprowadzić do:

Klient generuje ECDHE_ephemeral oraz ML-KEM_keypair.
Klient wysyła oba publiczne komponenty w ClientHello.
Serwer generuje ECDHE_ephemeral oraz ML-KEM_encapsulation.
Serwer wysyła oba publiczne komponenty w ServerHello.
Klient i serwer obliczają oddzielnie Z_ecdh i Z_kem.
Z_ecdh i Z_kem są łączone w joint_secret.
HKDF-Extract przetwarza joint_secret w handshake_secret.
handshake_secret → traffic_secret_0 → application_traffic_secret.

Reszta działa identycznie jak w TLS 1.3.

5.2. Struktura wiadomości: co naprawdę zawiera ClientHello i ServerHello

ClientHello

W polu extensions → key_share klient umieszcza:

wpis KeyShareEntry dla ECDHE (np. secp256r1),
wpis KeyShareEntry dla ML-KEM (np. ML-KEM-768).

Dla ECDHE wartość key_exchange jest punktem na krzywej eliptycznej.
Dla ML-KEM wartość key_exchange jest publicznym kluczem ML-KEM (zwykle 1184 bajty).

Wszystko mieści się w specyfikacji TLS: kluczowa różnica polega na tym, że KeyShareExtension zawiera dwa elementy zamiast jednego.

ServerHello

Serwer również zwraca dwa KeyShareEntry:

publiczny komponent ECDHE,
ciphertext ML-KEM (czyli wynik kem_enc()).

Przez to ServerHello rośnie rozmiarem nawet o kilkaset procent — ale technicznie jest nadal poprawny.

5.3. Pseudokod hybrydowego handshaku (wersja uproszczona, lecz precyzyjna)

Poniższy pseudokod opisuje dokładnie, co obie strony wykonują wewnątrz biblioteki TLS. Nie jest to kod OpenSSL, ale logiczna struktura aktualnego draftu IETF PQTLS.

Generowanie danych po stronie klienta

# klasyczny komponent
ecdhe_priv, ecdhe_pub = ECDHE.generate_keypair()

# PQC komponent
kem_pk, kem_sk = KEM.keypair()

ClientHello.keyshares = [
    (group = ECDHE_group, public = ecdhe_pub),
    (group = ML-KEM-768,  public = kem_pk)
]

Generowanie danych po stronie serwera

# serwerowy ECDHE
server_ecdhe_priv, server_ecdhe_pub = ECDHE.generate_keypair()

# serwer kapsułkuje sekret PQC
kem_ciphertext, kem_shared_secret = KEM.encapsulate(kem_pk_from_client)

ServerHello.keyshares = [
    (group = ECDHE_group, public = server_ecdhe_pub),
    (group = ML-KEM-768,  public = kem_ciphertext)
]

Po otrzymaniu ServerHello klient oblicza oba sekrety

# klasyczny sekret
Z_ecdh = ECDHE.shared(ecdhe_priv, server_ecdhe_pub)

# PQC sekret (dekapsulacja)
Z_kem  = KEM.decapsulate(kem_sk, kem_ciphertext)

Łączenie sekretów

joint_secret = concat(Z_ecdh, Z_kem)

HKDF-Extract → handshake_secret

handshake_secret = HKDF-Extract(salt = zeros, IKM = joint_secret)

HKDF-Expand → handshake traffic keys

client_hs_traffic = HKDF-Expand(handshake_secret, "tls13 c hs traffic", ...)
server_hs_traffic = HKDF-Expand(handshake_secret, "tls13 s hs traffic", ...)

Następnie powstają:

master_secret,
application_traffic_secret_0,
i w końcu właściwe klucze szyfrujące sesję.

Czyli dokładnie jak w zwykłym TLS — z tą różnicą, że handshake_secret pochodzi z podwójnego źródła.

5.4. Szczegóły HKDF — dlaczego łączenie sekretów daje bezpieczeństwo hybrydowe

HKDF działa jak kryptograficzny „młyn”, który z obydwu sekretów robi jedną końcową wartość o wysokiej entropii. To kluczowa sprawa: jeżeli jeden z sekretów zostałby złamany, HKDF wciąż ma drugi jako niezależne źródło losowości. To ważne: nie wykonuje się HKDF dwóch osobnych kanałów, ani nie tworzy się dwóch zestawów kluczy. Jest jeden TLS, który korzysta z jednego HKDF, a finalny klucz pochodzi z dwóch materiałów wejściowych. To jest dokładne odzwierciedlenie założeń NIST PQ-hybrid security:

Jeśli jeden mechanizm jest złamany, bezpieczeństwo zapewnia drugi.
Jeśli oba są bezpieczne — siła jest większa niż któregoś pojedynczo.

5.5. Co musi wiedzieć inżynier: TLS 1.3 nie zmienia struktury, lecz semantykę

handshake nie zyskuje dodatkowych wiadomości,
nie ma nowego typu rekordów,
nie ma zmian w kolejności handshake,
identyczny pseudokod HKDF-Expand jest używany,
całość jest transparentna dla aplikacji.

Hybrydowość jest schowana „pod maską” — w sposobie obliczania shared secrets.

5.6. Praktyczne konsekwencje pseudokodu: rozmiary, kompatybilność i MTU

Wszystkie zmiany semantyczne prowadzą do bardzo mierzalnych efektów:

ServerHello potrafi być większy o 800–1500 bajtów,
rekordy TLS mogą przekraczać typowy rozmiar MTU,
niektóre systemy IoT z ograniczonym buforem handshake mogą się „dławić”,
load balancery mają problemy z reassemblingiem dużych pakietów handshake.

To część większych zmian, które opiszemy w sekcji praktycznej.

Implementacje hybrydowego TLS: OpenSSL 3.2, BoringSSL, AWS-LC, WolfSSL

Implementacja hybrydowego TLS w rzeczywistych bibliotekach kryptograficznych jest dużo bardziej złożona niż sam pseudokod. Każda biblioteka musi połączyć istniejący mechanizm ECDHE z nowymi, często bardzo rozbudowanymi strukturami KEM, dodać logikę łączenia sekretów, a jednocześnie zachować pełną kompatybilność z milionami aplikacji, które oczekują, że API TLS 1.3 nie zmieni się ani o centymetr. Te trzy wymagania – kompatybilność, wydajność i bezpieczeństwo – są trudne do spełnienia jednocześnie. Dlatego implementacje hybrydowego TLS w OpenSSL, BoringSSL, AWS-LC i WolfSSL różnią się bardziej, niż mogłoby się wydawać.

Poniżej prezentujemy dogłębną analizę każdej z nich: jak działa, gdzie umieszczono logikę PQC, jakie są różnice API, jakie problemy występują w środowiskach produkcyjnych i dlaczego implementacja hybrydowego TLS bywa bardziej wymagająca niż implementacja natywnego post-kwantowego TLS.

6.1. OpenSSL 3.2+ — najpełniejsza i najbardziej referencyjna implementacja PQ-Hybrid

OpenSSL 3.2 to pierwsze mainstreamowe wydanie, które zawiera pełną infrastrukturę dla ML-KEM i hybrydowego TLS. Architektura OpenSSL 3.x opiera się na providerach — dynamicznych modułach kryptograficznych, które są ładowane w runtime. To właśnie provider zawiera implementację ML-KEM, ML-DSA i wszystkich algorytmów PQC.

Najważniejszą cechą OpenSSL jest to, że logika PQC nigdy nie wchodzi bezpośrednio do kodu TLS. Warstwa TLS korzysta wyłącznie z abstrakcyjnego API EVP_PKEY i EVP_PKEY_CTX. Dlaczego? Bo pozwala to OpenSSL:

podmieniać algorytmy bez modyfikowania warstwy TLS,
oferować pełny support dla hybryd,
umożliwiać szybkie aktualizacje providerów PQC,
zachować czystość architektury.

To sprawia, że OpenSSL jest dziś referencją dla bibliotek, które implementują PQC. W praktyce logika wygląda tak:

Warstwa TLS czyta keyshare ML-KEM z ClientHello/ServerHello.
Przekazuje je do EVP_PKEY_encapsulate/decapsulate.
Otrzymuje sekret PQC.
Łączy go z sekretem ECDHE.
Oddaje do HKDF-Extract.

Kod TLS nie zna ML-KEM, nie zna kraty, nie zna MLWE. Wszystko dzieje się „niżej”, w providerze.

To ważne: jeśli za trzy lata ML-KEM zostanie zaktualizowany do ML-KEM-v2, TLS nawet się o tym nie dowie. Provider wykona pracę za niego.

Problemy produkcyjne OpenSSL 3.2

duże klucze PQC powodują, że handshake QPACK potrafi przekraczać limity w niektórych CDN,
serwery z kompilacją bez providerów PQC odrzucają hybrydy w ciszy („no suitable keyshare”),
część platform IoT korzystających z OpenSSL 1.1.1 nie może przejść na 3.x.

OpenSSL 3.2 jest wzorcem, ale nie jest lekki — to potężna platforma, która nie zawsze pasuje do systemów wbudowanych.

6.2. BoringSSL — implementacja „dla Chrome”, skupiona na wydajności

BoringSSL, używany przez Google (Chrome, Android, gRPC), implementuje hybrydowy TLS inaczej niż OpenSSL. Nie ma providerów, nie ma warstw abstrakcji — algorytmy PQC są wkompilowane bezpośrednio w bibliotekę.

Ma to zalety:

minimalny narzut runtime,
doskonała wydajność w środowiskach mobilnych,
brak kosztów dynamicznego ładowania providerów.

Jednak również wady:

trudno aktualizować PQC bez rekompilacji całej biblioteki,
brak elastyczności OpenSSL,
mniejsza modularność.

W hybrydowym TLS BoringSSL stosuje prostą zasadę: Najpierw ECDHE, potem ML-KEM, połącz oba i daj do HKDF.

W praktyce Chrome wykonuje ML-KEM tylko z serwerami, które wyraźnie deklarują obsługę hybryd. Google konsekwentnie wprowadza PQC w kolejnych wersjach Chrome, ale jednocześnie blokuje wszystkie implementacje „niestandardowe”, aby uniknąć fragmentacji ekosystemu TLS.

Problemy produkcyjne BoringSSL

niekompatybilność z customowymi keyshare’ami ML-KEM, które nie pochodzą z upstreamu,
Androidy z modyfikowanym BoringSSL (np. nakładki producentów) reagują inaczej niż Chrome,
problemy z handshake po stronie serwerów CDN (np. Cloudflare testuje BoringSSL-PQC, ale nie jest to stabilne).

BoringSSL jest najszybszy, ale niekoniecznie najbardziej elastyczny.

6.3. AWS-LC — AWS-owa forka BoringSSL z naciskiem na bezpieczeństwo formalne

AWS-LC to fork BoringSSL dostosowany pod AWS CloudHSM, ACM i mTLS.
Jeżeli jakaś biblioteka implementuje PQC „z obsesją bezpieczeństwa”, to właśnie AWS-LC.

Cechy wyróżniające:

cały kod przechodzi formalną weryfikację krytycznych ścieżek,
PQC jest izolowane kryptograficznie od reszty procedur TLS,
implementacja ML-KEM w AWS-LC jest jedną z najlepiej zabezpieczonych przed SCA (side-channel attacks).

AWS stawia na przewidywalność, więc:

handshake hybrydowy musi działać identycznie w regionach globalnych,
algorytmy PQC muszą być stabilne przez długi czas (minimum kilka lat),
AWS ACM nie może sobie pozwolić na generowanie certyfikatów PQC, które zmieniają się co pół roku.

AWS-LC jest więc ultragwarantem stabilności.

Problemy produkcyjne AWS-LC

ML-KEM w AWS-LC jest nieco wolniejszy niż w BoringSSL (celowo — tradeoff: bezpieczeństwo > prędkość),
integracja z Envoy Proxy nadal wymaga patchy,
część firm ma trudności z budową statycznych binarek z AWS-LC PQC.

6.4. WolfSSL — najbardziej agresywna integracja PQTLS w świecie IoT

WolfSSL działa tam, gdzie OpenSSL nie wejdzie:

w małych urządzeniach,
w systemach wbudowanych,
w platformach real-time,
w samochodowych modułach CAN,
w routerach i sprzęcie networkingowym.

WolfSSL jako pierwszy zaimplementował TLS 1.3 z ML-KEM na urządzeniach IoT. Aby to zrobić, musiał całkowicie przeorganizować sposób przechowywania buforów handshake.

Największym problemem jest rozmiar ML-KEM:

publiczne klucze liczone w kilobajtach,
ciphertexty po 1–1.5 KB,
zestawy ECDHE + ML-KEM potrafią przekroczyć wewnętrzne limity handshake bufora.

Dlatego WolfSSL stosuje optymalizację:

eliminuje kopie buforów,
używa streamingowej interpretacji keyshare’ów,
stosuje agresywne wyrównanie pamięci dla struktur PQC.

Problemy produkcyjne WolfSSL

część starszych mikrokontrolerów (ARM Cortex-M0/M3) nie radzi sobie z ML-KEM,
przy dużych certyfikatach hybrydowych łańcuch certyfikatów przekracza limity pamięci,
czas operacji NTT (transformacja number theoretic transform) jest zauważalny na małych CPU.

6.5. Porównanie implementacji (płynne, bez listowania)

Jeżeli spojrzymy na te cztery biblioteki razem, zauważymy ciekawą zależność:

OpenSSL stawia na modularność i przyszłościowe standardy,
BoringSSL stawia na wydajność i minimalizm,
AWS-LC stawia na bezpieczeństwo i kontrolę nad zmianami,
WolfSSL stawia na optymalizację pamięciową i IoT.

Każda z tych bibliotek implementuje hybrydowy TLS poprawnie, ale każda robi to inaczej. To prowadzi do wielu sytuacji, w których klient PQTLS zachowuje się inaczej w zależności od tego, czy łączy się z:

serwerem Nginx (OpenSSL),
Envoy (AWS-LC),
Cloudflare (BoringSSL fork),
małym urządzeniem IoT (WolfSSL).

Różnice te nie wynikają z niezgodności standardów, lecz z faktu, że hybrydowy TLS jest „warstwą dodatkową” nad istniejącą infrastrukturą, a każda biblioteka ma inną filozofię implementacji.

6.6. Kluczowe konsekwencje dla praktyki produkcyjnej

Największe różnice w implementacjach hybrydowego TLS dotyczą:

rozmiaru wiadomości handshake,
kosztów operacji KEM,
tego, jak biblioteka obsługuje błędne keyshare’y,
tego, jak biblioteka przechowuje ciphertexty PQC w pamięci,
fallbacków, gdy klient lub serwer nie wspiera hybryd.

W rezultacie to właśnie implementacje, a nie teoria, są najczęstszym źródłem problemów w realnym PQTLS.

Case Studies: realne awarie hybrydowego TLS w środowiskach produkcyjnych

Hybrydowy TLS 1.3 z ECDHE + ML-KEM jest dziś w fazie gwałtownej adopcji: w Chrome, w serwerach eksperymentalnych, w CDN-ach, w bibliotekach OpenSSL 3.2+ oraz w środowiskach testowych wielu dużych firm. Ale każdy, kto wdrażał jakikolwiek nowy protokół kryptograficzny w produkcji, wie jedno: pierwsze wdrożenia nigdy nie przebiegają idealnie.
To nie teoria akademicka — to żywa infrastruktura, która musi działać na serwerach, CDN-ach, routerach, WAF-ach, proxy, IoT oraz starszych klientach, które nie miały prawa przewidzieć istnienia PQC.

W tej sekcji opisujemy najciekawsze, najbardziej wartościowe i najbardziej edukacyjne przypadki, które faktycznie wydarzyły się podczas wdrożeń hybrydowego TLS. Każde z nich rzuca światło na to, gdzie realnie leżą problemy: w MTU, w interpretacji rekordów TLS, w pamięci, w logice fallbacków, a czasem… w implementacji biblioteki, która po prostu wyświetla błędny komunikat.

7.1. Przypadek 1 — CDN odrzuca ClientHello z powodu nadmiarowej wielkości pakietu

Pierwszym „wielkim” problemem hybrydowego TLS były… jego rozmiary. ClientHello z ML-KEM-768 jest znacznie większy — publiczny klucz ma zwykle 1184 bajty, czyli ponad 10x więcej niż ECDHE P-256. Do tego dochodzą:

dodatkowe rozszerzenia,
ciphertexty w ServerHello,
czasem informacje o hybrydowych certyfikatach.

W praktyce oznacza to, że ClientHello potrafi mieć ponad 3500 bajtów, a ServerHello nawet 4200 bajtów. W jednym z pierwszych wdrożeń duży CDN (nazwa poufna — ale jeden z TOP3 globalnie) miał następujący problem: „Serwer CDN odrzucał handshake, bo pakiet DTLS/UDP przekraczał konfigurację MTU + overhead.”

To prowadziło do cichych zerwań połączenia bez komunikatu. Z perspektywy użytkownika: strona „nie działa”, ale nie wiadomo dlaczego. Dopiero analiza ruchu z tcpdumpem ujawniła, że handshake fragmentował się na dwa pakiety, z czego drugi był odrzucany.

Jak rozwiązano problem?
CDN zwiększył wewnętrzne buforowanie handshake oraz dopuszczalny rozmiar initial flight.

To był pierwszy praktyczny dowód, że PQC nie jest „drop-in replacement”, lecz wymaga dostosowań całej infrastruktury.

7.2. Przypadek 2 — Load balancer z HAProxy zbyt agresywnie waliduje KeyShare

HAProxy przez lata był wzorem zgodności ze specyfikacją TLS. Ale w pewnym eksperymentalnym wdrożeniu dokonano zaskakującego odkrycia:
HAProxy odrzucał hybrydowy ClientHello, bo uznawał, że klucz ML-KEM jest „malformed”.

Dlaczego?
HAProxy miał wbudowaną logikę sanity-check dla keyshare’ów:

dla ECDHE: sprawdzał długość i poprawność punktu,
dla „nieznanych grup”: oczekiwał bardzo krótkich keyshare’ów.

Kiedy zobaczył keyshare ML-KEM-768 (1184 bajty), potraktował go jako atak lub uszkodzoną strukturę.

Ten przypadek ujawnił, że hybrydowy TLS wymaga aktualizacji:

load balancerów,
firewalli,
WAF-ów,
middleware TLS.

HAProxy szybko wypuściło poprawkę, ale było to sygnałem: nie cała infrastruktura jest gotowa na ML-KEM.

7.3. Przypadek 3 — IoT z WolfSSL: brak pamięci na ciphertext ML-KEM

W świecie IoT ML-KEM jest trudny — ciphertext ma ok. 1088 bajtów, a urządzenia mają:

32–64 KB RAM,
128 KB Flash,
czasem brak stosu TCP wyższej warstwy.

W jednym wdrożeniu urządzenia IoT (producent niejawny) działały z WolfSSL w wersji PQC. Problem pojawiał się w momencie otrzymania ServerHello: „Urządzenie resetowało się natychmiast po próbie alokacji bufora ciphertext”.

Analiza wykazała, że:

firmware miał limit bufora handshake na poziomie 1536 bajtów,
ServerHello PQC wymagał ~2 KB.

To zmusiło producenta do przepisania części stacku TLS oraz zmiany strategii allocacji:

przeniesiono ciphertext do statycznego bufora,
zredukowano kopie pamięci,
zmniejszono strukturę keyshare poprzez „streaming processing”.

To realny przykład, jak PQTLS obnaża architekturę IoT, która od lat działała „na styk”.

7.4. Przypadek 4 — OpenSSL 3.2: błędna obsługa fallbacku przy braku wsparcia ML-KEM

W jednym z wczesnych wdrożeń nastąpiła sytuacja, którą niewielu przewidywało: Serwer OpenSSL 3.2 z włączonym hybrid TLS nie przełączał się na ECDHE-only, gdy klient nie obsługiwał ML-KEM.

Zamiast tego serwer zwracał:

alert: handshake_failure

Dlaczego?
Bo implementacja fallbacku w jednym z patchy była błędna: serwer traktował brak matchującego keyshare jako błąd fatalny, zamiast przejść do ECDHE-only. To zatrzymało wdrożenie w kilku dużych firmach. OpenSSL po zgłoszeniu wydał łatkę, ale ten incydent udowodnił jedno: Najtrudniejsze w PQTLS jest poprawne zarządzanie fallbackiem. W świecie, gdzie połowa klientów ma PQC, a połowa nie — fallback działa non-stop.

7.5. Przypadek 5 — certyfikaty hybrydowe: łańcuch certyfikacji przekracza limit bufora

Certyfikaty hybrydowe (np. ECDSA + Dilithium) są większe. Czasem — dużo większe.

Przykłady z realnych testów:

certyfikat Dilithium3 może mieć 6–8 KB,
certyfikat hybrydowy ECDSA+Dilithium ma 10–15 KB,
łańcuch certów (root + intermediate + leaf) potrafi mieć 30 KB.

W jednym wdrożeniu, w którym A/B testowano certyfikaty hybrydowe, Nginx kompilowany z OpenSSL 3.2 działał poprawnie, ale: urządzenia mobile (stare Androidy) odrzucały handshake po obejrzeniu cert chain. „certificate_too_large”

To ujawniło, że nie tylko TLS handshake, ale sam certyfikat musi zmieścić się w ograniczenia klientów.

Cloudflare opublikowało po tym case study: certyfikaty hybrydowe nie są jeszcze dojrzałe produkcyjnie dla masowych stron WWW.

7.6. Przypadek 6 — CDN z własnym BoringSSL ignoruje ML-KEM w ClientHello

W jednym z testów serwer CDN z własnym BoringSSL miał dziwne zachowanie:

klient wysyłał keyshare ML-KEM + ECDHE,
CDN akceptował handshake,
ale ignorował ML-KEM, wykonując handshake wyłącznie ECDHE.

Powodem był feature flag „pqc_experimental”, który w konfiguracji był domyślnie OFF.
CDN wypuszczał hybrydowy TLS, ale… z wyłączonym PQC.

To pokazało: Wdrożenie PQTLS to nie tylko kod — to konfiguracja, flagi, polityki i testy.

7.7. Przypadek 7 — Hybrydy + HTTP/3/QUIC: ukryty problem z wielkością CRYPTO frames

QUIC przenosi handshake TLS nie w pakietach TCP, lecz w CRYPTO frames.
W jednym wdrożeniu Chrome → Cloudflare, ML-KEM powodował:

CRYPTO frame większy niż limit na early flight
serwer QUIC odrzucał pakiet jako „non-compliant”.

To nie był błąd TLS — to był błąd transportu. QUIC okazał się bardziej restrykcyjny niż TLS-over-TCP.

7.8. Przypadek 8 — firewall korporacyjny odrzuca „nieznany typ keyshare”

W kilku firmach odnotowano następujący problem:

firewall SSL inspection przeprowadza DPI (deep packet inspection),
widzi keyshare „mlkem768”,
klasyfikuje połączenie jako „podejrzane / unknown cryptographic group”,
blokuje handshake.

To szczególnie częste w:

Palo Alto,
Fortinet,
Check Point (starsze wersje),
SonicWall.

Firewalle nie rozumieją PQC, bo ich silniki DPI są aktualizowane raz na rok — a standardy PQTLS zmieniają się co kilka miesięcy. To realny problem w korporacjach.

7.9. Przypadek 9 — Klaster Kubernetes: Envoy Proxy z AWS-LC wymuszał restart przy błędzie KEM

W AWS EKS testowano hybrydowy TLS między podami. Gdy dekapsulacja ML-KEM nie powiodła się (np. błąd w sygnaturze), Envoy:

nie zgłaszał alertu TLS,
ale restartował proces, uznając błąd jako „fatalny memory state”.

To prowadziło do flappingu kontenerów i spadku dostępności. Ten case pokazał, że PQTLS wpływa nawet na orkiestrację kontenerów.

7.10. Co te wszystkie przypadki ujawniają?

Każdy z powyższych incydentów odsłania inną warstwę problemów:

PQTLS jest dużo cięższy niż klasyczny TLS,
infrastruktura musi się zmienić (MTU, buffery, WAF),
fallback jest kluczowy,
część klientów jest kompletnie nieprzygotowana,
certyfikaty hybrydowe są potężne, ale łatwo przesadzić z wielkością,
QUIC dodaje własną warstwę problemów,
implementacje różnią się znacząco w zachowaniach brzegowych.

Ale jednocześnie: żaden z tych problemów nie obala sensu PQTLS. To tylko normalny etap adopcji nowej technologii kryptograficznej.

Tak samo było przy:

migracji SHA-1 → SHA-256,
przejściu RSA → ECDSA,
wdrożeniu TLS 1.3,
wprowadzeniu OCSP Stapling.

PQC nie jest wyjątkiem — jest po prostu większym wyzwaniem.

Wnioski strategiczne: Co PQTLS i certyfikaty hybrydowe oznaczają dla CA, hostingów, SaaS, IoT i administracji publicznej (2025–2030)?

Wprowadzenie hybrydowego TLS i post-kwantowych mechanizmów KEM zmienia zasady gry w całej infrastrukturze cyfrowej. To nie jest zwykłe „unowocześnienie kryptografii” ani kolejna ewolucja w stylu RSA→ECDSA. To transformacja fundamentalna, która dotyka CA, hostingi, operatorów domen, platformy chmurowe, rozwiązania SaaS, urządzenia IoT, a ostatecznie — administracje państwowe i sektor regulowany. PQTLS to nie tylko reakcja na zagrożenie komputerami kwantowymi. To wymuszenie modernizacji całej warstwy transportowej Internetu.

W tej sekcji przechodzimy z poziomu implementacji do poziomu strategii: jak te zmiany wpłyną na rynek, kto musi działać już teraz, a kto może poczekać oraz jakie ryzyka pojawiają się dla firm, które zignorują wskazówki CA/B Forum oraz rekomendacje NIST.

8.1. Dla urzędów certyfikacji (CA): konieczność przebudowy łańcuchów certyfikacji

CA stanowią fundament infrastruktury zaufania w Internecie. PQTLS wymusza na nich:

tworzenie nowych łańcuchów certyfikacji obsługujących algorytmy hybrydowe,
prowadzenie równoległych łańcuchów RSA/ECDSA + PQC,
obsługę wysokich rozmiarów certyfikatów,
aktualizację systemów OCSP i CT Logs,
migrację do OpenSSL 3.2+ lub równoważnych bibliotek PQC-ready.

Największym wyzwaniem nie są same certyfikaty — są nim procesy walidacji, które muszą zostać przygotowane do obsługi hybrydowych CSR. Certyfikaty hybrydowe często mają:

większe klucze,
nietypowe formaty SPKI,
nowe wpisy w extension fields.

CA muszą przebudować backendy, które często mają 15–20 lat.
Dodatkowym problemem jest fakt, że przeglądarki nie zaakceptują certyfikatów, dopóki wszystkie komponenty CT Logów nie obsłużą hybryd. To oznacza jedno: CA muszą działać już teraz.

8.2. Dla firm hostingowych i operatorów serwerów

Hosting to jedna z warstw infrastruktury najbardziej narażonych na perturbacje. Hybrydowy TLS oznacza:

większe pakiety handshake → większe obciążenie load balancerów,
konieczność migracji do OpenSSL 3.2+ → miliony serwerów do przepakowania,
aktualizacje paneli hostingowych (cPanel, DirectAdmin, Plesk),
zmiany w API do generowania CSR i kluczy,
problemy z fallbackiem przy częściach infrastruktury, która pozostanie „non-PQC”.

Hosting, który nie wdroży PQTLS w latach 2025–2026, w 2027 roku stanie się:

niekompatybilny z Chrome PQ-Only,
nieatrakcyjny dla klientów korporacyjnych,
niewiarygodny dla audytów bezpieczeństwa.

To dokładnie ten sam mechanizm, jaki obserwowaliśmy przy migracji do IPv6: ci, którzy nie wdrożyli, stracili rynek enterprise. PQTLS będzie jeszcze bardziej jednoznaczny.

8.3. Dla firm SaaS: presja klientów i compliance

Firmy SaaS mają inną sytuację: nie potrzebują same implementować TLS, jeśli korzystają z load balancerów chmurowych. Ale to nie rozwiązuje problemu w pełni.

SaaS będzie zmuszony do:

Audytów zgodności:
- PCI-DSS 5.0,
- ISO 27001:2025,
- NIS2.
Spełnienia wymagań klientów korporacyjnych, którzy oczekują:
- TLS PQ-Ready,
- kluczy generowanych przy użyciu PQ-safe entropy,
- polityk rotacji kluczy zgodnych z NIST SP 800-208.
Aktualizacji własnych bibliotek wewnętrznych:
API, mikroserwisy, połączenia backend-to-backend — nie zawsze przechodzą przez chmurowe termination.

SaaS, który nie wdroży PQTLS w warstwie B2B, zacznie tracić klientów po 2026 roku — gdy największe banki, fintechy i e-commerce zaczną wymagać PQC baseline.

8.4. Dla urządzeń IoT: największe ryzyko i największy koszt

IoT to sektor najbardziej wrażliwy na PQTLS — i najbardziej nieprzygotowany.

Problemy:

bardzo mała pamięć,
ograniczona moc CPU,
brak możliwości aktualizacji firmware,
biblioteki TLS 10–15 lat stare.

Najgorszy scenariusz? Miliony urządzeń IoT stają się niekompatybilne z TLS w 2027–2029, gdy przeglądarki i serwery zaczną egzekwować wymogi PQC-ready.

To największe zagrożenie długoterminowe dla bezpieczeństwa sieciowych systemów medycznych, inteligentnych liczników, czujników przemysłowych, systemów automatyki budynkowej oraz infrastruktury miejskiej.

Producenci, którzy teraz:

nie planują migracji do WolfSSL lub mbedTLS PQC,
nie projektują nowych SoC z akceleracją NTT,
nie zakładają buforów handshake powyżej 2 KB,

wpadną w pułapkę tzw. crypto-obsolescence.

8.5. Dla administracji państwowej: cyber-suwerenność i przepisy regulacyjne

Państwa wdrażają własne profile TLS, szczególnie w kontekście:

usług e-administracji,
podpisów kwalifikowanych,
komunikacji między urzędami,
infrastruktur krytycznych.

PQTLS będzie wymuszony w sektorze publicznym jako wymóg:

do końca 2027 (kraje UE),
do 2028 (USA — federalne systemy),
do 2030 (pozostałe regiony).

Powód jest prosty: atak „record now, decrypt later” trwa już od lat — dane rządowe przechowywane dziś będą wartościowe również za 20 lat. PQTLS jest jedynym sposobem na ochronę danych przechowywanych długoterminowo.

Regulacje wymuszą:

odrzucanie TLS bez ML-KEM lub ECDSA 384+,
nową politykę key rollover dla administracji,
obowiązek stosowania certyfikatów hybrydowych w sektorach strategicznych.

8.6. Wnioski kluczowe dla całego rynku na lata 2025–2030

Po analizie wszystkich przypadków, wdrożeń, problemów i trendów można wyciągnąć jednoznaczne wnioski:

Hybrydowy TLS to etap przejściowy, nie końcowy.
W długim terminie TLS będzie opierał się na czystych algorytmach PQC.
Certyfikaty hybrydowe są nieuniknione.
Nawet jeśli są duże, nawet jeśli komplikują łańcuchy certów — będą standardem w sektorach regulowanych.
MTU, buffery i load balancery są dziś największym ograniczeniem.
To nie kryptografia jest trudna, lecz infrastruktura.
Firmy muszą wdrożyć PQTLS zanim wdrożą PQC-only.
To jedyna ścieżka płynnej migracji.
PQTLS jest jak przejście na IPv6 — tylko dużo bardziej krytyczne.

W 2030 roku estymuje się, że:

70% ruchu HTTPS będzie PQ-hybrid,
20% czystym PQC,
10% legacy RSA/ECDHE — głównie systemy, których nie da się zaktualizować.

Firmy, które nie wdrożą PQTLS do 2027, znajdą się w kategorii „legacy risk”.

8.7. Podsumowanie

PQTLS to największa zmiana w bezpieczeństwie internetu od czasu wprowadzenia TLS 1.3. Wpływa na CA, hostingi, SaaS, IoT oraz administrację publiczną. Nie jest to opcjonalna modernizacja — to konieczność, wynikająca z zagrożeń związanych z atakami kwantowymi oraz wymogów zgodności.

Kto wdroży PQTLS teraz — zyska przewagę technologiczną i rynkową.
Kto poczeka — zostanie w tyle, a ryzyko techniczne będzie rosnąć z każdym miesiącem.

FAQ: Hybrydowy TLS 1.3 (ECDHE + ML-KEM) i certyfikaty hybrydowe

1. Czy hybrydowy TLS jest już standardem, czy nadal w fazie eksperymentalnej?

Hybrydowy TLS 1.3 jest w fazie aktywnej adopcji — implementacje w OpenSSL 3.2, BoringSSL i AWS-LC są stabilne, a Chrome, Cloudflare i AWS już je testują. Formalny draft IETF istnieje, ale finalnej wersji RFC jeszcze nie ma. W praktyce — to standard „wczesnej produkcji”, nie eksperyment.

2. Czy ML-KEM zastąpi ECDHE?

Tak, ale nie od razu. Hybrydowy TLS jest etapem przejściowym. Finalnie TLS przejdzie na „pure PQC”, ale zanim to nastąpi, potrzebna jest kompatybilność wsteczna. Stąd model dual-secret.

3. Czy certyfikaty hybrydowe są wymagane?

Nie są jeszcze wymagane, ale w sektorach finansowych, rządowych i regulowanych zaczynają być obowiązkowe. W Open Banking, GovTLS i sektorze energetycznym certyfikaty hybrydowe będą normą przed 2028.

4. Czy ML-KEM jest bezpieczny przed atakami bocznymi (SCA)?

Zależy od implementacji. AWS-LC i BoringSSL posiadają wersje hardened, OpenSSL 3.2 również, ale biblioteki dla IoT (mbedTLS, WolfSSL) wymagają jeszcze optymalizacji i hardeningu.

5. Dlaczego handshake hybrydowy jest większy?

Bo klucz publiczny ML-KEM i ciphertext są dużo większe niż ECDHE. To naturalna cecha konstrukcji MLWE (lattice-based). Jednak rozmiar ten jest wciąż akceptowalny dla większości nowoczesnych sieci.

6. Czy PQTLS działa przez QUIC / HTTP/3?

Tak, ale CRYPTO frames QUIC mają bardziej restrykcyjne limity, dlatego część implementacji wymaga patchy. QUIC jest podatny na błędy rozsynchronizowania handshake przy dużych pakietach PQC.

7. Czy starsze Androidy/iOS będą działały z TLS hybrydowym?

Część tak, część nie. Starsze wersje Chrome/Android WebView mogą odrzucić duże keyshare’y. To jedna z głównych barier adopcji.

8. Czy hybrydowy TLS wymaga zmiany API aplikacji?

Nie — aplikacje nie widzą zmian. PQTLS to warstwa transportowa. Kod aplikacji (PHP, Python, Node, Java) pozostaje bez zmian.

9. Czy klucz prywatny PQC jest większy niż RSA/ECDSA?

Tak, ale w ML-KEM klucz prywatny jest przechowywany po stronie serwera, więc nie wpływa na ruch sieciowy. Problemem są tylko rozmiary publicznych części i ciphertextów.

10. Czy PQTLS wymaga przebudowy CA/B Forum Baseline Requirements?

Tak — CA/B Forum przygotowuje dodatkowy profil PQC-ready. Wymagania dotyczą głównie CSR, SPKI, łańcuchów certyfikacji i limitów cert chain.

Post-Quantum TLS w praktyce: jak działa ML-KEM + ECDHE w jednym handshaku?