Jak działają klucze szyfrowania: fundament bezpieczeństwa plików

Klucz szyfrowania to ciąg losowych bitów, który blokuje i odblokowuje dane. Przy nowoczesnym transferze plików oznacza to zazwyczaj 256-bitowy klucz AES — 32 bajty losowych danych generowanych przez kryptograficznie bezpieczny generator liczb losowych (CSPRNG). Ten sam algorytm, który zamienia wideo 10 GB w zaszyfrowany tekst, może go odkodować tylko przy podaniu dokładnie tego samego klucza. Bezpieczeństwo klucza to miejsce, gdzie szyfrowanie żyje lub umiera: doskonały szyfr AES-256 jest bezużyteczny, jeśli klucz jest słaby, przewidywalny lub ujawniony. Ten artykuł wyjaśnia, jak klucze są tworzone, współdzielone, przechowywane i niszczone w rzeczywistych usługach takich jak HexaTransfer, Tresorit i Proton Drive.

Klucze to tylko liczby losowe

Klucz 256-bitowy to 32 bajty. Jeśli wygenerujesz go w przeglądarce, wygląda tak:

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

To, co czyni go „kluczem", to sposób, w jaki algorytm go używa. AES-256-GCM pobiera 256-bitowy klucz, rozszerza go przez harmonogram kluczy na 15 kluczy rundowych i używa ich do tasowania 128-bitowych bloków przez 14 rund. Matematyka nie dba o to, skąd pochodzą bity — wymaga tylko, by były tajne i nieprzewidywalne.

„Nieprzewidywalne" to trudniejsza połowa. Jeśli atakujący może odgadnąć stan generatora liczb losowych, może odtworzyć klucz. Błąd Debian OpenSSL z 2006 roku zredukował entropię klucza do 15 bitów na dwa lata przed wykryciem — podręcznikowy przykład tego, co się dzieje, gdy losowość zawodzi.

Kryptograficznie bezpieczna losowość

Przeglądarki udostępniają crypto.getRandomValues(), które pobiera dane z CSPRNG systemu operacyjnego: /dev/urandom w Linuksie, BCryptGenRandom w Windows, SecRandomCopyBytes w macOS. Te z kolei mieszają wiele źródeł entropii — czasy przerwań, czasy szukania dysku, układy sprzętowego RNG jak Intel RDRAND.

Nie używaj Math.random() do kluczy. To przewidywalny Mersenne Twister, a jego stan można często odtworzyć z kilku wyników.

Po stronie serwera crypto.randomBytes() w Node.js i secrets.token_bytes() w Pythonie owijają CSPRNG systemu operacyjnego i są bezpieczne. Standardy NIST SP 800-90A i SP 800-90B definiują wymagania CSPRNG; Linux kernel 5.17+ używa projektu opartego na BLAKE2s, który je spełnia.

Klucze symetryczne: jeden klucz, dwa kierunki

Algorytmy symetryczne jak AES używają jednego klucza do szyfrowania i deszyfrowania. Opcje rozmiaru klucza:

• 128-bitowy — 2^128 możliwych wartości, bezpieczny do większości celów, zatwierdzony dla SECRET przez NSA CNSSP-15.
• 192-bitowy — rzadki, stosowany w niektórych kontekstach rządowych.
• 256-bitowy — 2^256 wartości, zatwierdzony dla TOP SECRET, aktualny standard dla usług transferu plików.

Podwójny rozmiar klucza nie podwaja trudności brute-force — podnosi ją do kwadratu. 2^128 już jest poza zasięgiem (wiek wszechświata razy 10 miliardów ze wszystkimi komputerami na Ziemi). 256-bitowy to zabezpieczenie przed komputerami kwantowymi, gdzie algorytm Grovera skutecznie zmniejsza o połowę siłę kluczy symetrycznych.

Trudny problem z kluczami symetrycznymi: dostarczenie tego samego klucza obu stronom bez przechwycenia przez nikogo.

Klucze asymetryczne: sztuczka z parą

Kryptografia klucza publicznego rozwiązuje dystrybucję kluczy. Każda strona generuje matematycznie powiązaną parę kluczy: klucz publiczny (udostępniany otwarcie) i klucz prywatny (przechowywany w tajemnicy). Wszystko zaszyfrowane kluczem publicznym można odszyfrować tylko kluczem prywatnym.

Popularne typy kluczy asymetrycznych:

• RSA-2048 — modulus 2048-bitowy, szeroko obsługiwany, wolny. Stosowany w certyfikatach TLS.
• RSA-4096 — mocniejszy, jeszcze wolniejszy.
• Curve25519 (X25519) — 256-bitowy klucz krzywej eliptycznej, szybki, używany przez Signal i WireGuard.
• Ed25519 — 256-bitowy klucz podpisywania, używany przez SSH i podpisywanie commitów Git.

Sam klucz prywatny to 32–512 bajtów w zależności od algorytmu. Klucze prywatne RSA są większe, bo zawierają wiele liczb pierwszych; klucze prywatne Curve25519 to po prostu 32 losowe bajty.

Szyfrowanie hybrydowe: połączenie obu w rzeczywistych systemach

Żaden praktyczny system nie szyfruje dużych plików bezpośrednio za pomocą RSA. Zamiast tego każdy prawdziwy protokół — TLS, PGP, Age, Signal, każda poważna usługa transferu plików — używa szyfrowania hybrydowego:

1. Wygeneruj losowy 256-bitowy klucz AES (klucz sesji lub klucz pliku).
2. Zaszyfruj plik za pomocą AES-256-GCM.
3. Zaszyfruj klucz sesji kluczem publicznym odbiorcy.
4. Wyślij oba.

Odbiorca odszyfrowuje klucz sesji swoim kluczem prywatnym, a następnie używa go do odszyfrowania pliku. Zyskujesz szybkość szyfrowania symetrycznego i wygodę dystrybucji kluczy szyfrowania asymetrycznego.

Dla transferu plików opartego na przeglądarce „klucz publiczny" jest często zastępowany fragmentem URL: nadawca generuje klucz sesji, umieszcza go w URL po #, a przeglądarka odbiorcy odczytuje go lokalnie. Prostsze i działa bez wymagania od odbiorców posiadania pary kluczy.

Wyprowadzanie kluczy z haseł

Użytkownicy wpisują hasła; algorytmy chcą równomiernie losowych bitów. Funkcja wyprowadzania klucza (KDF) stanowi pomost między nimi:

• PBKDF2-HMAC-SHA-256 — iteruje funkcję skrótu. OWASP 2023 zaleca 600 000 iteracji. Dostępny w Web Crypto API.
• scrypt — odporny na pamięć, odpiera ataki GPU. Parametry: N=2^17, r=8, p=1.
• Argon2id — aktualna najlepsza praktyka, zwycięzca Password Hashing Competition z 2015 roku. Parametry: memory=64 MB, iterations=3, parallelism=4.

KDF dodaje sól (losową, przechowywaną obok zaszyfrowanego tekstu) i współczynnik pracy (iteracje), by spowolnić brute-force. 12-znakowe losowe hasło przetwarzane przez Argon2id z 64 MB pamięci zajmie farmie GPU tysiące lat na wyczerpanie. Słabe hasło jak lato2024 pada w sekundy niezależnie od KDF — KDF nie może dodać entropii, której nie było.

Przechowywanie kluczy: gdzie żyją klucze?

Klucze muszą gdzieś istnieć, a to „gdzieś" jest krytyczną decyzją dotyczącą bezpieczeństwa:

• Pamięć przeglądarki (tylko sesja). Domyślne dla efemerycznych transferów plików. Klucz jest generowany, używany i odrzucany w ramach ładowania strony.
• Fragment URL. Udostępniany przez łącze, przechowywany w historii przeglądarki odbiorcy. Ważna jest ograniczona żywotność.
• Local storage / IndexedDB. Trwałe, ale dostępne dla każdego JavaScript na tym samym źródle. Ryzykowne, chyba że zaszyfrowane innym kluczem.
• Brelok systemu operacyjnego — macOS Keychain, Windows DPAPI, Linux libsecret. Sprzętowo wspierany na niektórych platformach.
• Sprzętowy moduł bezpieczeństwa (HSM) — YubiKey, chmurowy HSM (AWS CloudHSM, Azure Dedicated HSM). Klucze nigdy nie opuszczają sprzętu.
• Usługa zarządzania kluczami (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Scentralizowane, audytowalne, wycenione na około 1 USD/klucz/miesiąc.

Przy transferze plików zero-knowledge klucz żyje w fragmencie URL i przeglądarce nadawcy. Serwer nigdy go nie przechowuje.

Rotacja i niszczenie kluczy

Długotrwałe klucze kumulują ryzyko. Najlepsza praktyka to rotacja:

• Certyfikaty TLS: rotacja co 90 dni (domyślne Let's Encrypt), maksymalnie 398 dni dla publicznych CA od 2020 roku.
• Klucze szyfrowania danych: zazwyczaj rotowane co 90 dni do roku w zgodnych systemach (PCI DSS 4.0 Wymaganie 3.6).
• Klucze główne: rotowane rocznie lub przy zmianach personelu.

Niszczenie też ma znaczenie. Samo usunięcie plików kluczy z dysku jest niewystarczające — dyski SSD mogą przechowywać dane w obszarach wyrównywania zużycia. Bezpieczne niszczenie wymaga nadpisania lub dedykowanych poleceń usuwania HSM. Kryptograficzne wymazywanie — odrzucenie klucza, by zaszyfrowane dane stały się trwale nieosiągalne — jest często najczystszym podejściem dla masowych danych.

Usługi transferu plików zazwyczaj używają kluczy per plik, które istnieją tylko przez czas życia transferu (24 godziny do 7 dni) i są odrzucane wraz z zaszyfrowanym tekstem po wygaśnięciu.

Rozpoznawanie słabych praktyk kluczowych

Trzy powszechne tryby awarii, na które należy uważać:

• Klucze zakodowane na stałe w kodzie klienta. Jeśli klucz jest taki sam dla każdego użytkownika, to nie jest klucz — to zaciemnianie.
• Klucze przechowywane obok zaszyfrowanego tekstu na tym samym serwerze lub w tej samej bazie danych. Naruszenie ujawnia oba.
• Brak rotacji kluczy. Systemy legacy z kluczami szyfrowania sprzed dekady mają mniej więcej dekadę skumulowanego ryzyka naruszenia.

Renomowana usługa publikuje kryptograficzny biały papier obejmujący generowanie, przechowywanie, rotację i niszczenie kluczy — i poddaje się audytom stron trzecich przeprowadzanym przez firmy takie jak Cure53 lub Trail of Bits.

Perspektywa praktyczna

Dla bezpiecznego udostępniania plików: wybierz usługę, która generuje 256-bitowe klucze po stronie klienta za pomocą crypto.getRandomValues(), umieszcza je tylko w fragmencie URL (nigdy nie wysyłane do serwera), obsługuje klucze wyprowadzone z hasła przez PBKDF2 lub Argon2id i automatycznie wygasa zarówno klucz, jak i zaszyfrowany tekst w ciągu 24 godzin.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.