Od DES do kryptografii postkwantowej: wielki wyścig

Współczesna kryptografia nie jest historią coraz trudniejszych szyfrów, lecz rozwiązywania kolejnych problemów zaufania. Szyfr symetryczny chroni dane, gdy obie strony mają ten sam sekret. Kryptografia klucza publicznego pomaga uzgodnić klucz i podpisać wiadomość. Funkcja skrótu wiąże integralność z krótką wartością. Certyfikat łączy klucz z tożsamością. Protokół taki jak TLS składa te elementy w bezpieczną komunikację—o ile implementacja, konfiguracja i zarządzanie kluczami są poprawne.

Ten przewodnik prowadzi od DES z 1977 roku, przez Diffie–Hellmana, RSA, publiczny konkurs AES i kolejne wersje TLS, do pierwszych standardów postkwantowych NIST. Celem nie jest nostalgia. Starsze decyzje nadal tłumaczą dzisiejsze błędy: użycie szyfrowania bez uwierzytelnienia, brak rotacji certyfikatów, statyczny klucz współdzielony i opóźnianie migracji do chwili, gdy algorytm staje się awaryjnie przestarzały.

Mapa funkcji kryptograficznych

Potrzeba	Mechanizm	Przykłady
Poufność dużej ilości danych	Szyfr symetryczny	AES-GCM, ChaCha20-Poly1305
Uzgodnienie sekretu	Wymiana klucza / KEM	(EC)DHE, ML-KEM
Autentyczność i niezaprzeczalność	Podpis cyfrowy	RSA-PSS, ECDSA, ML-DSA
Integralność	MAC lub AEAD	HMAC, AES-GCM
Odcisk danych	Funkcja skrótu	SHA-256, SHA-3
Powiązanie klucza z nazwą	Certyfikat i PKI	X.509, urząd certyfikacji

Algorytm nie jest protokołem. AES określa transformację bloków, ale nie mówi, jak utworzyć nonce, przekazać klucz, uwierzytelnić partnera ani reagować na błąd. TLS określa negocjację, harmonogram kluczy, rekordy i komunikaty, wykorzystując kilka prymitywów.

1976: Diffie i Hellman publikują nowy kierunek

Przed kryptografią klucza publicznego dwie strony potrzebowały bezpiecznie przekazanego wspólnego sekretu. W dużej sieci dystrybucja kluczy staje się problemem logistycznym: każda para potrzebuje materiału, który napastnik nie może przechwycić.

Praca Whitfielda Diffiego i Martina Hellmana „New Directions in Cryptography” z 1976 roku zaproponowała publiczną wymianę informacji prowadzącą obie strony do tego samego sekretu. Bezpieczeństwo klasycznego Diffie–Hellmana opiera się na trudności problemu logarytmu dyskretnego w odpowiednio dobranej grupie.

Sam Diffie–Hellman nie uwierzytelnia rozmówcy. Aktywny napastnik może ustanowić osobny sekret z każdą stroną i pośredniczyć. Potrzebny jest podpis, certyfikat lub wcześniej znany klucz. To fundamentalna lekcja: poufność bez uwierzytelnienia nie powstrzymuje man-in-the-middle.

Efemeryczne DHE i ECDHE tworzą nowe klucze dla sesji. Jeśli długoterminowy klucz podpisu wycieknie później, wcześniej zapisane sesje nie powinny dać się odszyfrować. To forward secrecy, dziś standardowa cecha TLS 1.3.

DES: pierwszy publiczny federalny standard

Data Encryption Standard został opublikowany jako FIPS 46 w styczniu 1977 roku. DES szyfruje bloki 64-bitowe i używa efektywnego klucza 56-bitowego. Standaryzacja umożliwiła interoperacyjność i publiczną analizę. Kontrowersje dotyczyły krótkiego klucza oraz wpływu NSA na projekt tablic S-box.

Z czasem 56 bitów stało się za mało wobec rosnącej mocy. W 1998 roku maszyna EFF DES Cracker publicznie pokazała praktyczne przeszukiwanie przestrzeni kluczy. 3DES wykonywał DES trzy razy, wydłużając życie wdrożeń, ale był wolny, miał mały blok i pozostawał rozwiązaniem przejściowym.

Historia DES uczy, że bezpieczeństwo parametru maleje wraz z rozwojem sprzętu. Algorytm może nie mieć przełomu matematycznego, a mimo to stać się nieakceptowalny ekonomicznie.

1978: RSA łączy szyfrowanie i podpis

Ronald Rivest, Adi Shamir i Leonard Adleman opublikowali metodę opartą na arytmetyce modulo iloczynu dużych liczb pierwszych. Publiczny klucz może szyfrować lub weryfikować podpis, prywatny odszyfrowywać lub podpisywać. Bezpieczeństwo wiąże się z trudnością faktoryzacji odpowiednio dużego modułu.

„Podręcznikowego RSA” nie wolno używać bez schematu kodowania. Deterministyczne szyfrowanie jest podatne, a podpis surowej wartości nie zapewnia wymaganej struktury. Standardy takie jak OAEP dla szyfrowania i PSS dla podpisów dodają losowość oraz formatowanie z analizą bezpieczeństwa.

RSA był szeroko używany w certyfikatach i starszych handshake’ach TLS. W TLS 1.3 usunięto statyczną wymianę klucza RSA; certyfikat RSA może nadal podpisywać handshake, lecz sekret sesji pochodzi z (EC)DHE lub PSK. Rozdzielenie podpisu od wymiany klucza zapewnia forward secrecy.

Funkcje skrótu i lekcja kolizji

Kryptograficzny hash mapuje dowolne dane do wartości stałej długości. Oczekuje się odporności na znalezienie preimage, second preimage i kolizji. Kolizja to dwie różne wiadomości z tym samym hashem; jej koszt dla idealnej funkcji n-bitowej jest rzędu 2^(n/2) z powodu paradoksu urodzinowego.

MD5 i SHA-1 utraciły odporność na kolizje. To nie oznacza, że każda obserwowana suma natychmiast ujawnia preimage, ale eliminuje bezpieczne użycie w podpisywaniu dokumentów i certyfikatów, gdzie napastnik może przygotować dwie treści. Migracja do SHA-256 i SHA-3 pokazuje potrzebę crypto agility: możliwość wymiany algorytmu bez przebudowy całego produktu.

Hash hasła bez salt i kosztownej funkcji jest błędem. Hasła wymagają Argon2id, scrypt, bcrypt lub PBKDF2 z unikalną salt oraz parametrami spowalniającymi zgadywanie. SHA-256 jest szybki celowo, co pomaga atakującemu w offline cracking.

Konkurs AES: otwarty proces zamiast tajnego wyboru

W 1997 roku NIST rozpoczął publiczny konkurs na następcę DES. Zgłoszono 15 algorytmów, analizowanych przez społeczność podczas otwartych konferencji. W 2000 roku wybrano rodzinę Rijndael autorstwa Joana Daemena i Vincenta Rijmena, a FIPS 197 opublikowano 26 listopada 2001 roku.

AES operuje na blokach 128-bitowych i używa kluczy 128, 192 lub 256 bitów. Sam szyfr blokowy potrzebuje trybu. ECB ujawnia powtarzalność bloków i nie powinien chronić strukturalnych danych. CBC wymaga nieprzewidywalnego IV oraz oddzielnego MAC z właściwą kolejnością. Współczesne protokoły preferują AEAD, które łączy szyfrowanie z uwierzytelnieniem.

AES-GCM jest wydajny i szeroko wspierany sprzętowo, ale ponowne użycie nonce z tym samym kluczem może katastrofalnie naruszyć bezpieczeństwo. ChaCha20-Poly1305 bywa wydajniejszy na urządzeniach bez akceleracji AES. Wybór prymitywu nie zwalnia z projektu cyklu życia nonce i kluczy.

Od SSL do TLS 1.0

Netscape rozwijał SSL dla bezpiecznego handlu WWW. SSL 2.0 miał istotne wady, a SSL 3.0 stał się podstawą standaryzacji IETF. TLS 1.0 opublikowano jako RFC 2246 w styczniu 1999 roku. Protokół negocjował wersję i zestaw szyfrów, uwierzytelniał serwer certyfikatem, ustalał sekrety oraz chronił rekordy.

Elastyczność zapewniała zgodność, ale utrzymywała stare opcje. Ataki na padding CBC, renegocjację, RC4 i downgrade pokazywały, że protokół jest tak mocny jak najsłabsza negocjowalna ścieżka oraz implementacja. POODLE wykorzystał możliwość zejścia do SSL 3.0, a późniejsze standardy formalnie zabroniły przestarzałych wersji i szyfrów.

TLS 1.3: mniej opcji, silniejsze założenia

TLS 1.3 został opublikowany w RFC 8446 w sierpniu 2018 roku. Usunął statyczne RSA i Diffie–Hellmana, stare szyfry, kompresję rekordów i tryby nie-AEAD. Wszystkie publiczno-kluczowe wymiany klucza zapewniają forward secrecy. Po ServerHello komunikaty handshake są szyfrowane, a HKDF zapewnia separację sekretów.

Skrócenie handshake poprawia opóźnienie. Tryb 0-RTT pozwala przesłać wczesne dane przy wznowieniu, lecz te dane mogą zostać odtworzone przez napastnika. Aplikacja powinna dopuszczać 0-RTT tylko dla operacji bezpiecznych przy replay, nie dla płatności czy zmiany stanu.

Praktyczny audyt TLS 1.3, mTLS i PKI sprawdza nie tylko wersję protokołu, ale łańcuch certyfikatów, nazwy, rotację, ochronę klucza, unieważnianie i zaufane urzędy.

PKI: matematyka spotyka operacje

Certyfikat X.509 podpisany przez zaufany urząd wiąże klucz publiczny z nazwą i okresem ważności. Klient buduje łańcuch do zaufanego root CA i sprawdza podpisy, nazwę hosta, czas oraz ograniczenia. Awaria często nie wynika z AES czy RSA, lecz z wygasłego certyfikatu, złej nazwy, przypadkowo zaufanego CA albo wycieku klucza prywatnego.

mTLS dodaje certyfikat klienta, zapewniając silną tożsamość maszyna–maszyna. Nie zastępuje autoryzacji: ważny certyfikat mówi, kim jest klient, a polityka decyduje, co wolno mu zrobić. Automatyczna rejestracja, krótkie okresy ważności i rotacja zmniejszają koszt operacyjny PKI.

2024: pierwsze standardy postkwantowe NIST

Duży, odporny na błędy komputer kwantowy mógłby użyć algorytmu Shora przeciw problemom faktoryzacji i logarytmu dyskretnego, zagrażając RSA oraz ECC. Nie łamie w ten sam sposób szyfrów symetrycznych; algorytm Grovera daje ogólne przyspieszenie przeszukiwania, dlatego większe klucze symetryczne zachowują margines.

13 sierpnia 2024 roku NIST zatwierdził trzy standardy:

FIPS 203 / ML-KEM do ustanawiania klucza;
FIPS 204 / ML-DSA do podpisów;
FIPS 205 / SLH-DSA jako bezstanowy podpis oparty na hashach.

Migracja jest pilna nie dlatego, że istnieje publiczny komputer łamiący RSA, lecz przez scenariusz „harvest now, decrypt later”: napastnik zapisuje zaszyfrowany ruch i odszyfruje go w przyszłości. Organizacje powinny inwentaryzować algorytmy, długość poufności danych i zależności protokołów. Więcej opisuje przewodnik po kryptografii postkwantowej.

Najtrwalsze lekcje

Nie projektuj własnej kryptografii. Używaj utrzymanych bibliotek i standardowych protokołów.
Uwierzytelniaj szyfrowane dane. Poufność bez integralności umożliwia manipulację.
Klucze są ważniejsze niż nazwa algorytmu. Chroń generowanie, przechowywanie, dostęp, rotację i usuwanie.
Zapewnij crypto agility. Inwentarz i możliwość migracji są kontrolą bezpieczeństwa.
Weryfikuj tożsamość, nie tylko szyfrowanie. Błędny certyfikat może bezpiecznie zaszyfrować dane do napastnika.
Testuj konfigurację. Poprawny prymityw w złym trybie nadal jest podatny.

Kryptografia jest też elementem zarządzania sekretami i podpisywania artefaktów Sigstore. Klucz aplikacji, klucz KMS i klucz podpisu mają inne cele, właścicieli oraz zasady rotacji; wspólny magazyn nie powinien oznaczać wspólnych uprawnień.

FAQ

Czy AES-256 jest zawsze lepszy od AES-128?

Ma większy margines wobec brute force, ale oba są uważane za silne przy poprawnym użyciu. Ryzyko częściej leży w nonce, trybie, kluczu i implementacji. Wymagania regulacyjne oraz plan PQC mogą uzasadniać AES-256.

Czy TLS szyfruje adres strony?

Chroni treść HTTP i większość handshake’u w TLS 1.3, ale metadane sieciowe nadal ujawniają adres IP, a nazwa hosta może być widoczna bez Encrypted Client Hello. DNS również wymaga osobnej ochrony.

Czy komputer kwantowy złamie całe szyfrowanie?

Nie. Największe zagrożenie dotyczy RSA, Diffie–Hellmana i ECC. Szyfry symetryczne oraz hashe wymagają dostosowania parametrów, ale nie stają się automatycznie bezużyteczne.

Źródła

Nie wiesz, czy Twoje certyfikaty, mTLS i klucze wytrzymają audyt? Zamów audyt bezpieczeństwa obejmujący konfigurację i cykl życia kryptografii.