Uwaga na start: przełączenie w aplikacji VPN „AES-256” na „ChaCha20” bywa kuszące, bo wygląda jak szybka poprawka na spadki prędkości. W praktyce to często najmniej istotne pokrętło — jeśli wąskim gardłem jest serwer, Wi‑Fi, zły protokół, MTU albo CPU w routerze. Jednocześnie są sytuacje, w których wybór algorytmu (i powiązanego z nim trybu) realnie zmienia komfort: telefon przestaje się grzać, router wreszcie „dowozi” transfer, a opóźnienia przestają skakać.
Żeby podjąć decyzję szybko i bez marketingowych skrótów myślowych, trzeba rozdzielić trzy rzeczy: algorytm szyfrowania (AES, ChaCha20), tryb i uwierzytelnianie (np. AES-GCM, Poly1305, HMAC/SHA) oraz protokół VPN (WireGuard, OpenVPN, IKEv2/IPsec). Dopiero ich kombinacja wpływa na bezpieczeństwo i szybkość połączenia VPN.
AES vs ChaCha20 w VPN, WireGuard ChaCha20-Poly1305, OpenVPN AES-GCM vs AES-CBC, AES-NI i akceleracja sprzętowa, VPN wolne przez CPU, IKEv2/IPsec szyfrowanie AES, Poly1305 a HMAC/SHA, opóźnienia VPN a szyfrowanie, MTU i wydajność VPN, UDP vs TCP w VPN, mit AES-256 vs AES-128, jak sprawdzić bottleneck w VPN
VPN zwalnia, bateria leci, a w ustawieniach straszy „AES-256” i „ChaCha20”
Sygnały ostrzegawcze: kiedy wybór algorytmu może coś zmienić
Nie każdy spadek prędkości na VPN wynika z szyfrowania, ale są objawy, które dość dobrze sugerują, że to właśnie kryptografia (albo jej implementacja) dusi połączenie. Pierwszy znak: urządzenie zaczyna pracować „na granicy”. Telefon robi się ciepły przy dłuższym transferze, bateria topnieje szybciej niż zwykle, a prędkość rośnie tylko do pewnego poziomu i dalej „nie chce”.
Drugi znak: router lub NAS jako klient/serwer VPN nagle staje się najsłabszym ogniwem. W praktyce wygląda to tak, że na laptopie VPN działa szybko, ale kiedy ten sam tunel zestawiasz na routerze, transfer spada dramatycznie. To klasyczny scenariusz, w którym różnica między AES (bez akceleracji) a ChaCha20 (wydajne w software) potrafi być odczuwalna.
Trzeci znak dotyczy nie tyle „gołych Mbps”, co odczuć: lagi, rwanie wideokonferencji, skaczący ping. Same algorytmy zwykle dokładają opóźnienie liczone w ułamkach milisekundy, ale gdy CPU jest zapchany szyfrowaniem, opóźnienia potrafią puchnąć skokowo (kolejki, jitter), a to już czuć w rozmowie głosowej i grach.
Problem w liczbach: „download” to nie to samo co stabilność i opóźnienia
Łatwo wpaść w pułapkę testów typu „speedtest i koniec”. Tymczasem dla VPN równie ważne są: stabilność transferu (czy prędkość nie faluje), jitter (zmienność opóźnień) oraz czas reakcji połączenia przy wielu małych pakietach (praca zdalna, RDP/VDI, terminale, VoIP).
Wybór AES vs ChaCha20 najczęściej wpływa na wydajność szyfrowania per CPU, więc najmocniej zobaczysz go w scenariuszach „ciągłego” obciążenia: pobieranie, wysyłanie kopii zapasowych, streaming w wysokiej jakości, synchronizacja chmury. Dla samego pingu większe znaczenie mają odległość do serwera i trasa, ale jeśli CPU się dławi, opóźnienia też ucierpią.
Mit vs rzeczywistość: „AES-256 = premium, ChaCha20 = kompromis”
Mit: „Jeśli coś ma 256 w nazwie, musi być lepsze i bezpieczniejsze”. Rzeczywistość: bezpieczeństwo VPN rzadko przegrywa się na wyborze AES-128 vs AES-256, a dużo częściej na złej konfiguracji, starych trybach, błędnej implementacji albo na tym, że ktoś włączył VPN na przestarzałym protokole, bo „działa”.
Drugi mit: „ChaCha20 jest mniej bezpieczny, bo brzmi egzotycznie”. Rzeczywistość: ChaCha20 to powszechnie używany, nowoczesny szyfr, dobry szczególnie tam, gdzie liczy się szybkość w software i odporność na pułapki implementacyjne. W praktyce dla użytkownika oba (AES i ChaCha20) są uznawane za bezpieczne, jeśli są użyte we właściwym trybie i w sensownym protokole.
Dlaczego VPN bywa wolny — algorytm szyfrowania to tylko jedna z przyczyn
Najczęstsze wąskie gardła (i jak je rozpoznać po objawach)
Najbardziej praktyczny podział to: CPU-bound (blokuje procesor) vs network-bound (blokuje sieć/serwer/trasa). Jeśli jesteś CPU-bound, zmiana algorytmu lub protokołu potrafi dać odczuwalny skok. Jeśli jesteś network-bound, możesz kręcić szyfrowaniem bez efektu.
CPU-bound rozpoznasz po tym, że prędkość „dochodzi do sufitu” i stoi, a przy większym obciążeniu system zaczyna łapać zadyszkę: spada responsywność, rośnie temperatura, a na routerze widać wysokie użycie CPU. Dodatkowa wskazówka: ten sam serwer VPN na mocniejszym urządzeniu nagle działa szybciej, mimo tej samej sieci.
Network-bound to z kolei sytuacja, w której ogranicza Cię łącze, Wi‑Fi, zasięg LTE/5G, odległość od serwera lub przeciążenie po stronie dostawcy VPN. Objawy: prędkość jest podobnie słaba także bez VPN (albo spada w godzinach szczytu), ping do serwera VPN jest wysoki, a zmiana algorytmu nie zmienia niczego.
UDP vs TCP i „TCP over TCP” — typowy winowajca lagów
Wiele osób widzi w ustawieniach przełącznik UDP/TCP i traktuje go jak „szybciej/wolniej”. Realnie to raczej „stabilniej w typowej sieci” (UDP) vs „większa szansa, że przejdzie przez restrykcje” (TCP). VPN po UDP zwykle ma mniejsze opóźnienia i lepiej znosi straty pakietów.
Najbardziej podstępny przypadek to OpenVPN po TCP, gdy aplikacje w tunelu też używają TCP (czyli prawie zawsze). Pojawia się wtedy efekt TCP over TCP: podwójne retransmisje i mechanizmy kontroli przeciążenia zaczynają sobie przeszkadzać, co daje rwanie i duże opóźnienia. W takiej sytuacji zmiana AES ↔ ChaCha20 bywa kosmetyką, a prawdziwym lekarstwem jest przejście na UDP albo zmianę protokołu (np. WireGuard/IKEv2).
MTU i fragmentacja: gdy „działa, ale coś się krzaczy”
Jeśli część stron lub usług działa, a część ładuje się wiecznie, albo duże pliki rwą się mimo „dobrego internetu”, podejrzany to często MTU (maksymalny rozmiar pakietu) i fragmentacja. VPN dodaje narzut, więc pakiety, które mieściły się bez tunelu, mogą zacząć się fragmentować lub być odrzucane.
Algorytm szyfrowania tego nie naprawi. Tu pomaga zmiana ustawień MTU/MSS w kliencie VPN, wybór innego protokołu (różny narzut), czasem też przejście na inny transport/port. Jeśli masz wrażenie „VPN jest wolny, bo strony klikają się ociężale”, MTU jest jednym z pierwszych punktów do sprawdzenia.
Implementacja ma znaczenie: ten sam AES nie zawsze działa tak samo
„AES” w aplikacji A i „AES” w aplikacji B to wciąż AES, ale wydajność zależy od biblioteki kryptograficznej, sposobu wykorzystania akceleracji sprzętowej, jakości kodu i tego, czy konfiguracja nie zmusza do droższych operacji (np. niepotrzebne przełączanie kontekstu, złe ustawienia wątków, słaba obsługa sieci).
Mit: „Skoro dwa VPN mają AES-256, to będą równie szybkie”. Rzeczywistość: protokół i implementacja potrafią zmienić wynik bardziej niż sam algorytm. Dlatego czasem WireGuard „z automatu” wygrywa w praktyce, mimo że ktoś porównuje go do OpenVPN z „tym samym AES”.
AES i ChaCha20 w praktyce: co je różni dla szybkości i zużycia energii (bez kryptograficznej matematyki)
Sprzęt kontra software — czemu na jednych urządzeniach wygrywa AES, a na innych ChaCha20
Najprostsza zasada: AES bywa ekstremalnie szybki na sprzęcie z akceleracją, a ChaCha20 bywa bardzo szybki w czystym software nawet na skromniejszych CPU. I to właśnie ta różnica napędza większość „wojenek” w internecie.
W komputerach stacjonarnych i serwerach często spotyka się instrukcje typu AES-NI (albo ich odpowiedniki), które przyspieszają operacje AES. Wtedy AES-GCM potrafi mieć świetną wydajność przy niskim obciążeniu CPU. W wielu nowoczesnych telefonach też istnieją formy przyspieszenia kryptografii, ale ich efekty zależą od systemu, implementacji i tego, czy VPN korzysta z właściwych API.
ChaCha20 projektowano tak, by działał wydajnie na szerokiej gamie procesorów bez specjalnych instrukcji. W praktyce często wypada znakomicie na urządzeniach mobilnych, starszych laptopach oraz sprzęcie sieciowym klasy SOHO, gdzie AES bez akceleracji potrafi „zajechać” CPU.
Co realnie odczujesz: temperatura telefonu, obciążenie routera, czas na baterii
Jeśli VPN używasz na telefonie w LTE/5G, to „wybór algorytmu” odczujesz nie tylko prędkością, ale też tym, czy urządzenie trzyma temperaturę w ryzach. Gdy szyfrowanie jest ciężkie dla CPU, telefon może dłużej utrzymywać wysokie taktowanie, a to przekłada się na grzanie i szybsze zużycie baterii.
W routerach domowych różnica jest często jeszcze bardziej brutalna. Routery mają ograniczone CPU, a jednocześnie są „bramą” dla wielu urządzeń. Jeśli VPN jest zestawiony na routerze i to on szyfruje cały ruch, algorytm i protokół stają się krytyczne. W takiej sytuacji ChaCha20 (np. w WireGuard) często daje efekt „wreszcie jest używalnie”, bo obciążenie CPU spada.
W laptopie lub PC zazwyczaj masz na tyle mocy, że algorytm przestaje być pierwszym podejrzanym. Wtedy bardziej liczy się wybór protokołu, serwera, trasy i jakości Wi‑Fi. Wyjątek: gdy robisz bardzo duże transfery (backupy, NAS, chmura) i VPN faktycznie dochodzi do granic możliwości sprzętu.
AES-128 vs AES-256: bezpieczeństwo a wydajność bez fetyszu „256”
W ustawieniach często zobaczysz „AES-128” i „AES-256” i naturalne jest pytanie: czy 256 jest „dwa razy bezpieczniejsze”? W praktyce, dla typowego zastosowania VPN, AES-128 jest uznawany za bardzo bezpieczny, a różnice bezpieczeństwa między 128 i 256 rzadko mają znaczenie dla realnego zagrożenia użytkownika.
Za to różnica w wydajności potrafi istnieć — zależnie od trybu (np. GCM), implementacji i sprzętowej akceleracji. Czasem AES-256 jest minimalnie wolniejszy, czasem różnica jest pomijalna. Jeśli walczysz o wydajność na słabym CPU, przełączenie z 256 na 128 może być bardziej sensowne niż „szukanie magicznego ChaCha20”, o ile protokół i aplikacja w ogóle pozwalają na taką zmianę.
Mit vs rzeczywistość: „Zmiana szyfrowania naprawi każdy wolny VPN”
Mit: „VPN działa wolno, więc na pewno mam zły algorytm”. Rzeczywistość: jeśli ogranicza Cię sieć, serwer lub trasa, zmiana AES ↔ ChaCha20 da najwyżej symboliczny efekt. Szyfrowanie jest kluczowe dopiero wtedy, gdy Twój sprzęt jest na granicy wydajności albo protokół/tryb wymusza kosztowne operacje.
„Algorytm” to nie „protokół”: WireGuard, OpenVPN, IKEv2/IPsec — gdzie w ogóle masz wybór?
Pakiet kryptograficzny: co tak naprawdę wybierasz klikając „AES”
W panelu aplikacji widzisz zwykle jeden skrót, ale pod nim kryje się zestaw elementów: szyfrowanie, integralność/uwierzytelnianie oraz wymiana kluczy. To dlatego porównania typu „mój VPN ma AES-256” bywają mylące — bo nie mówią nic o tym, czy jest to AES-GCM czy AES-CBC, czy integralność jest realizowana nowocześnie, i jak działa cały protokół.
Praktycznie: jeśli aplikacja pozwala wybrać „AES-256”, sprawdź, czy obok nie ma dopisku GCM/CBC. Jeśli go nie ma, bywa, że to marketingowe uproszczenie. A jeśli masz możliwość wybrania GCM, to często jest to lepszy trop niż sama długość klucza.
WireGuard: ChaCha20-Poly1305 jako standard (i mniej „kręcenia gałkami”)
WireGuard jest popularny m.in. dlatego, że minimalizuje liczbę opcji, które użytkownik może przypadkiem zepsuć. Standardowo używa ChaCha20-Poly1305 (czyli szyfrowanie + integralność w konstrukcji typu AEAD). W praktyce, jeśli wybierasz WireGuard, to nie przełączasz się na AES w ustawieniach — wybór algorytmu jest wbudowany w projekt protokołu.
To zmienia optykę: zamiast pytać „AES czy ChaCha20?”, częściej pytasz „WireGuard czy OpenVPN/IKEv2?” oraz „czy moje urządzenie i sieć lubią WireGuard?”. Dla wielu użytkowników odpowiedź brzmi: WireGuard daje świetny stosunek szybkości do prostoty, szczególnie na mobilkach i routerach SOHO.
Mit: „WireGuard jest zawsze najszybszy”. Rzeczywistość: zwykle jest bardzo szybki, ale jeśli sieć po drodze „nie lubi” UDP (albo operator agresywnie tnie/kształtuje ruch), możesz zobaczyć losowe spadki, gorszą stabilność albo problem z zestawieniem tunelu. Wtedy nie wygrywa „inny szyfr”, tylko inny sposób transportu lub protokół, który łatwiej przejdzie przez restrykcje.
Mit: „Skoro nie mogę zmienić algorytmu w WireGuard, to mam mniejszą kontrolę i gorzej”. Rzeczywistość: mniej gałek to mniej miejsc, gdzie da się wybrać coś przestarzałego albo wolnego. Z punktu widzenia użytkownika to często plus: odpada rozkmina „AES-256-CBC czy coś innego”, zostaje decyzja praktyczna — czy ten protokół działa stabilnie w Twojej sieci i na Twoim sprzęcie.
Jeśli potrzebujesz szybkiej decyzji: na telefonie i routerze domowym WireGuard bywa pierwszym strzałem właśnie dlatego, że ChaCha20-Poly1305 jest lekki dla CPU i nie wymaga akceleracji. Gdy widzisz, że VPN na routerze dobija do 100% CPU, a Wi‑Fi „udaje, że jest szybkie”, przejście z OpenVPN na WireGuard potrafi zrobić większą różnicę niż jakiekolwiek żonglowanie długością klucza AES. Z drugiej strony, w sieciach firmowych i hotelowych, gdzie wszystko przechodzi przez jedną bramkę i polityki, stabilniejszy może być IKEv2/IPsec albo OpenVPN na porcie, który nie rzuca się w oczy.
OpenVPN: tu faktycznie grzebiesz w AES/ChaCha20, ale płacisz narzutem
OpenVPN daje najwięcej „pokręteł” i dlatego dostarcza najwięcej mitów. Da się wybrać AES (często GCM) albo ChaCha20 (najczęściej jako ChaCha20-Poly1305), czasem do tego TCP/UDP, porty, dodatkowe opcje. To przydatne, gdy musisz się przecisnąć przez dziwne sieci albo specyficzne firewalle — OpenVPN bywa wtedy jak scyzoryk.
Cena jest prosta: większy narzut i większa zależność od implementacji. Na słabszych urządzeniach OpenVPN potrafi być wąskim gardłem nawet wtedy, gdy „algorytm brzmi nowocześnie”. Jeśli ktoś obiecuje „wystarczy przełączyć OpenVPN na AES-256 i będzie rakieta”, to zwykle życzeniowe myślenie — częściej pomaga zmiana na UDP, poprawienie MTU albo przesiadka na WireGuard/IKEv2.
IKEv2/IPsec: AES jest tu typowym wyborem, a stabilność bywa mocną stroną
W IKEv2/IPsec w praktyce najczęściej spotkasz pakiety oparte o AES (często AES-GCM), a sam protokół jest dobrze wspierany przez systemy mobilne. To jeden z powodów, dla których IKEv2 bywa „nudno stabilny” na telefonie: szybkie ponowne łączenie, sensowne zachowanie przy zmianach sieci (Wi‑Fi ↔ LTE) i solidna integracja z OS.
Mit: „IKEv2 jest wolny, bo ma AES”. Rzeczywistość: jeśli urządzenie ma sprzętową akcelerację i sensowną implementację, IKEv2 potrafi działać bardzo sprawnie. Gdy jest wolno, winny bywa raczej serwer, trasa albo przeciążenie/brak akceleracji na urządzeniu brzegowym (np. routerze), a nie sama etykieta „AES”.
Inne opcje, które realnie zmieniają bezpieczeństwo (często bardziej niż AES vs ChaCha20)
Najpierw uwierzytelnianie i PFS, dopiero potem „jaki szyfr”
Jeśli masz wybór w ustawieniach, większą robotę robi zwykle wymiana kluczy i to, czy sesje mają PFS (Perfect Forward Secrecy). To ona decyduje, czy przejęcie jednego klucza w przyszłości pozwoli komuś odtworzyć stary ruch. Różnice między „dobrym AES” i „dobrym ChaCha20” są realne, ale przy poprawnej konfiguracji obie opcje są daleko od pierwszej linii ryzyka dla typowego użytkownika.
Tryb pracy robi różnicę: AES-GCM kontra AES-CBC (i dlaczego „AES to AES” to skrót)
Jeśli gdziekolwiek w ustawieniach widzisz tylko „AES”, to w praktyce brakuje najważniejszego doprecyzowania: w jakim trybie ten AES pracuje. Dla użytkownika VPN ma to znaczenie nie dlatego, że musisz znać kryptografię, tylko dlatego, że niektóre kombinacje są zwyczajnie bardziej nowoczesne i mniej problematyczne.
AES-GCM to najczęstszy „dobry domyślny wybór”, bo łączy szyfrowanie z kontrolą integralności w jednej konstrukcji (AEAD). AES-CBC to starszy tryb, który sam z siebie nie zapewnia integralności — trzeba go poprawnie „dopiąć” osobnym mechanizmem (np. HMAC). Da się to zrobić bezpiecznie, ale rośnie liczba miejsc, gdzie implementacja może być słabsza, a narzut CPU bywa większy.
Mit: „AES-CBC jest zawsze niebezpieczny”. Rzeczywistość: potrafi być bezpieczny w poprawnie złożonym pakiecie, ale w VPN łatwiej i czyściej celować w GCM (albo ChaCha20-Poly1305), jeśli masz wybór. To nie fetysz „nowe = lepsze”, tylko pragmatyka: mniej klocków do źle poskładania.
Integralność i „MAC”: Poly1305 vs HMAC, czyli co pilnuje, żeby pakiety nie były podmieniane
VPN to nie tylko „tajność”. Równie ważne jest, żeby ktoś po drodze nie mógł podmienić pakietu i żeby druga strona to wykryła. W praktyce spotkasz dwa popularne podejścia:
- AEAD (np. AES-GCM, ChaCha20-Poly1305) – szyfrowanie i integralność są „w jednym zestawie”.
- Osobny MAC (np. HMAC-SHA256) – często w starszych konfiguracjach, gdzie szyfrowanie i integralność są rozdzielone.
W WireGuard integralność zapewnia Poly1305 razem z ChaCha20 (stąd nazwa zestawu). W wielu konfiguracjach IPsec i OpenVPN spotkasz HMAC ze SHA-2. Z punktu widzenia użytkownika nie chodzi o to, by wybierać „najmocniejszą nazwę”, tylko by unikać archaicznych składników (np. MD5/SHA-1) i mieszanek, które brzmią jak z instrukcji sprzed dekady.
Pułapki w menu ustawień: gdzie łatwo „wygrać liczbą”, a przegrać w praktyce
„AES-256” jako hasło marketingowe: co jest ukryte drobnym drukiem
Samo „AES-256” nie mówi, czy dostajesz nowoczesne AEAD, jak wygląda wymiana kluczy, czy sesje mają PFS, ani czy implementacja nie jest przypadkiem ustawiona pod kompatybilność z bardzo starymi klientami. Zdarza się, że dwie aplikacje chwalą się tym samym szyfrem, a jedna działa płynnie, a druga zjada CPU i gubi pakiety — bo różni je protokół, biblioteka, tryb pracy i masa detali „pod spodem”.
Mit: „Jak jest 256, to już wszystko jest premium”. Rzeczywistość: w typowym VPN różnicę jakości częściej robi GCM vs CBC, sensowny handshake i implementacja, a nie sama długość klucza. „256” bywa po prostu łatwe do sprzedania.
Mylenie szyfrowania z protokołem: „ustawiłem ChaCha20 w OpenVPN, więc mam WireGuard”
ChaCha20 w OpenVPN nie zmienia OpenVPN w WireGuard. Nadal zostaje ten sam silnik połączenia, narzut, sposób transportu i zachowanie w sieci. Jeśli Twoim problemem jest niestabilność w sieci hotelowej albo blokady, to czasem pomoże OpenVPN po TCP/443 niezależnie od szyfru. Jeśli problemem jest CPU na routerze — wtedy prędzej pomoże zmiana protokołu na WireGuard niż sama zamiana AES ↔ ChaCha20 w ramach OpenVPN.
TCP w tunelu: gdy „wolno” nie jest winą szyfru, tylko podwójnej kontroli retransmisji
Jeden z klasycznych scenariuszy: użytkownik ustawia OpenVPN na TCP, bo „TCP jest bardziej niezawodne”, a potem narzeka na lagi i rwanie wideokonferencji. Jeśli w tunelu masz TCP, a w środku leci kolejny TCP (czyli prawie zawsze, bo WWW), to w razie strat pakietów oba poziomy próbują „naprawiać” to samo. Efekt: opóźnienia, szarpanie, wrażenie „zamulenia”. Szyfr może być idealny, a i tak będzie źle.
Tu nie wygrywa „AES-128 zamiast AES-256”. Wygrywa zwykle UDP (WireGuard / IKEv2 / OpenVPN-UDP) albo rozwiązanie, które lepiej pasuje do warunków sieciowych.
Jak sprawdzić, czy AES ma u Ciebie przyspieszenie sprzętowe (i kiedy to w ogóle ma sens)
Komputer: szybka weryfikacja bez polowania na specyfikację
Na PC/laptopie największą różnicę robi wsparcie typu AES-NI. Jeśli jest, AES potrafi być bardzo szybki i energooszczędny. Jak to sprawdzić praktycznie?
- Windows: w praktyce na większości nowszych CPU AES-NI jest, ale najpewniejsze jest sprawdzenie narzędziem typu CPU-Z albo w informacjach o CPU (funkcje/instrukcje). Jeśli VPN „nie grzeje” CPU przy transferze, to też często znak, że akceleracja działa.
- Linux:
grep -m1 -o aes /proc/cpuinfo(jeśli zwróci „aes”, CPU deklaruje instrukcje AES). - macOS (Apple Silicon): AES ma wsparcie sprzętowe; w praktyce i AES, i ChaCha20 potrafią działać bardzo dobrze, a wybór protokołu częściej przebija wybór szyfru.
Jeśli masz nowy laptop i szybkie łącze, a VPN i tak jest wolny, to podejrzenie numer jeden zwykle nie brzmi „zły algorytm”, tylko: serwer VPN, trasa, przeciążenie, MTU albo Wi‑Fi.
Telefon i tablet: tu częściej liczy się implementacja i „koszt na wat”
W mobilkach wsparcie sprzętowe dla AES często istnieje, ale realny wynik zależy od systemu, biblioteki kryptograficznej i tego, jak aplikacja VPN robi I/O. Dlatego na jednym telefonie IKEv2 z AES-GCM będzie świetne, a na innym WireGuard z ChaCha20 będzie po prostu bardziej stabilny i mniej prądożerny.
Najprostszy test „użytkowy”: jeśli przy dłuższym transferze przez VPN telefon wyraźnie się nagrzewa i szybciej traci baterię, a po zmianie protokołu robi się chłodniej — to zwykle znak, że trafiłeś w bardziej pasujący zestaw (niekoniecznie tylko algorytm).
Router/NAS: CPU i brak akceleracji potrafią zabić każdy „ładny szyfr”
W sprzęcie SOHO najczęściej problem jest brutalnie prosty: mały CPU + dużo ruchu. Jeśli router ma robić VPN dla całego domu, to nawet „bezpieczna konfiguracja” może być nieużywalna wydajnościowo. Tu decyzja bywa bardziej inżynierska niż ideologiczna:
- gdy jest opcja, WireGuard często daje najlepszy stosunek prędkości do obciążenia,
- jeśli musisz zostać przy OpenVPN, poluj na UDP i AES-GCM oraz unikaj zbędnych dodatków,
- jeśli IPsec jest sprzętowo wspierany przez router (częste w niektórych platformach), IKEv2/IPsec potrafi być zaskakująco sprawny.
Decyzja w 5 minut: co wybrać, gdy zależy Ci na prędkości, stabilności i braku wpadek
Scenariusze, które faktycznie rozstrzygają „AES czy ChaCha20”
To nie jest konkurs piękności algorytmów. Najczęściej chodzi o dopasowanie do sprzętu i warunków sieci:
- Router lub starszy NAS jako klient VPN: najpierw sprawdź WireGuard (ChaCha20-Poly1305). Jeśli odpada przez sieć/polityki, dopiero wtedy kombinuj z OpenVPN/IKEv2.
- Nowy laptop/PC z AES-NI: AES (zwłaszcza GCM) zwykle nie będzie Twoim bottleneckiem; wybieraj protokół pod stabilność i przechodzenie przez sieci (często IKEv2 albo WireGuard).
- Telefon w ciągłym ruchu (Wi‑Fi ↔ LTE): IKEv2 bywa „nudno stabilny”, WireGuard często jest bardzo szybki — wybór zależy od tego, czy w Twoich sieciach UDP przechodzi bez problemów.
- Słabe Wi‑Fi / sieci z restrykcjami: czasem wygra OpenVPN, nawet jeśli jest cięższy, bo po prostu działa tam, gdzie inne protokoły są przycinane.
Mit: „Najlepszy algorytm da najlepszy ping”. Rzeczywistość: opóźnienia najczęściej rosną przez dystans do serwera, jitter w sieci i retransmisje, a nie dlatego, że wybrałeś AES-256 zamiast ChaCha20.
Mini-checklista: zanim zaczniesz przełączać szyfry w ciemno
- Jeśli masz problem z prędkością: sprawdź obciążenie CPU na urządzeniu (router/telefon/serwer). Gdy dobija do sufitu, zmiana protokołu (np. na WireGuard) zwykle daje więcej niż zmiana AES-256 → AES-128.
- Jeśli masz problem ze stabilnością: przetestuj inny protokół/transport (UDP vs TCP, inny port), zanim uznasz, że „szyfr jest zły”.
- Jeśli widzisz AES-CBC i masz możliwość przejścia na AES-GCM albo ChaCha20-Poly1305, to jest to sensowny ruch w stronę nowocześniejszego pakietu.
- Jeśli konfiguracja pozwala na przestarzałe skróty (MD5/SHA-1) lub dziwne „kompatybilności”, odpuść je nawet wtedy, gdy obiecują minimalny zysk wydajności.
- Gdy wszystko jest „teoretycznie idealne”, a i tak jest wolno: zmień serwer/lokalizację, sprawdź MTU i jakość łącza — algorytm szyfrowania bywa wtedy najmniej winny.
Nie wpadnij w „szyfromanie”: kiedy dłubanie przy AES/ChaCha20 jest stratą czasu
Najłatwiej stracić godzinę na przełączanie „AES-256 ↔ AES-128 ↔ ChaCha20”, gdy prawdziwy problem siedzi gdzie indziej. Dwie rzeczy, które najczęściej udają „winę algorytmu”, to przeciążony serwer i zła ścieżka sieciowa (routing, peering, Wi‑Fi). Jeśli bez VPN masz stabilny ping, a z VPN ping skacze i raz jest dobrze, raz fatalnie — to częściej brzmi jak obciążenie serwera lub jitter, nie jak „zły szyfr”.
Mit: „Jak zmienię z AES na ChaCha20, to VPN nagle przestanie się przycinać”. Rzeczywistość: jeśli gubisz pakiety na Wi‑Fi albo siedzisz daleko od lokalizacji serwera, różnica między dobrymi szyframi bywa kosmetyczna, a opóźnienia robi sieć.
Tryb szyfrowania ma znaczenie: AES-GCM kontra AES-CBC (i czemu CBC potrafi boleć)
Jeśli gdziekolwiek masz wybór w stylu AES-GCM vs AES-CBC, to zwykle jest bardziej „realna” decyzja niż 128 vs 256 bitów. GCM to nowoczesny tryb AEAD — ma szyfrowanie i integralność w jednym, zwykle lepiej się skaluje i jest prostszy w bezpiecznym użyciu. CBC to starsza szkoła: działa, ale wymaga dodatkowych elementów (MAC), jest bardziej podatny na błędy konfiguracji i w praktyce potrafi kosztować więcej CPU przy dużej liczbie pakietów.
Mit: „CBC jest równie dobre, bo to dalej AES”. Rzeczywistość: AES to klocki, a tryb to instrukcja składania. Zły zestaw (np. CBC + stare HMAC/ustawienia kompatybilności) potrafi przynieść więcej ryzyka niż jakiekolwiek rozważania, czy ChaCha20 jest „nowsze”.
Jeśli widzisz w panelu opcje typu AES-256-CBC i AES-256-GCM, to najczęściej GCM jest sensowniejszym wyborem (o ile druga strona go wspiera i nie psuje tego reszta konfiguracji).
Co jeszcze w „pakiecie” wpływa na bezpieczeństwo bardziej niż AES vs ChaCha20
Wymiana kluczy i PFS: bez tego „mocny szyfr” jest tylko plakatem
To, co boli w praktyce, to nie „czy AES jest bezpieczny”, tylko czy sesje są zestawiane w nowoczesny sposób. Szukaj oznak typu ECDHE / PFS (Perfect Forward Secrecy). Dzięki temu nawet jeśli kiedyś wycieknie długoterminowy klucz/hasło, nie da się masowo odszyfrować starych nagrań ruchu.
Mit: „Mam AES-256, więc nawet jak ktoś nagra ruch, to i tak nic nie zrobi”. Rzeczywistość: bez właściwej wymiany kluczy i PFS ryzyko przesuwa się w stronę „kiedyś to odszyfrują” albo „złamali klucz i czytają historię”. Szyfr to tylko element układanki.
Uwierzytelnianie serwera: certyfikaty, pinning, nie „klikaj akceptuj”
W wielu problematycznych konfiguracjach użytkownik przegrywa nie przez algorytm, tylko przez zbyt luźne weryfikowanie serwera. Jeśli aplikacja pozwala „zaakceptować nowy certyfikat, bo się zmienił” bez jasnego powodu, to prosisz się o ataki typu MITM w niepewnych sieciach.
To też moment, w którym marketing o szyfrze odwraca uwagę: można mieć ChaCha20-Poly1305 i jednocześnie kiepsko rozwiązaną warstwę zaufania.
Stare skróty i „kompatybilność”: SHA-1/MD5 jako czerwone flagi
Jeśli w ustawieniach przewijają się MD5 albo SHA-1, traktuj to jak lampkę ostrzegawczą. Dla użytkownika to prosta heurystyka: skoro ktoś trzyma stare składniki, to często trzyma też inne „muzealne” decyzje (tryby, negocjacje, ustawienia zgodności), które mogą odbić się i na bezpieczeństwie, i na stabilności.
Opóźnienia i „responsywność” VPN: gdzie algorytm może mieć wpływ, a gdzie prawie nigdy
Algorytm szyfrowania może dorzucić kilka milisekund, gdy urządzenie jest słabe albo gdy jedziesz na limicie CPU (typowo routery, małe VPS-y, stare telefony). Ale większość „lagi w grze” i „czkawki w rozmowie” to efekt:
- odległości do serwera i liczby przeskoków po drodze,
- jitteru w LTE/5G albo zatkanego Wi‑Fi,
- retransmisji (zwłaszcza gdy ktoś upiera się na TCP tam, gdzie powinno być UDP),
- złego MTU (fragmentacja, czarne dziury PMTU) i ogólnie problemów z pakietami.
Praktyczna obserwacja: jeśli speedtest „jakoś leci”, ale strony otwierają się z opóźnieniem, a czat w aplikacji łapie pauzy — to brzmi bardziej jak MTU/jitter niż „AES vs ChaCha20”. W takiej sytuacji często pomaga zmiana serwera na bliższy, inny protokół (np. IKEv2 ↔ WireGuard) albo dopracowanie MTU, a nie pogoń za szyfrem.
Inne algorytmy, które możesz zobaczyć — i jak je czytać po ludzku
W panelach i plikach konfiguracyjnych przewijają się nazwy, które wyglądają groźnie, ale da się je „z grubsza” sklasyfikować bez doktoratu:
- ChaCha20-Poly1305 – nowoczesny zestaw AEAD, standard w WireGuard; zwykle dobry wybór, zwłaszcza na słabszym sprzęcie lub tam, gdzie implementacja jest dopracowana.
- AES-128/256-GCM – nowoczesny zestaw AEAD; świetny na CPU z akceleracją AES, często spotykany w IPsec i OpenVPN.
- AES-128/256-CBC + HMAC-SHA256 – starsze podejście, które nadal działa, ale ma więcej miejsc, gdzie można coś sknocić; jeśli masz alternatywę w AEAD, zwykle lepiej ją wybrać.
- SHA-256/SHA-384 – to zwykle skróty do integralności/podpisów, nie „szyfrowanie danych”; sama obecność SHA-2 to nic złego, ale nie myl tego z tajnością.
Mit: „Im więcej nazw w konfiguracji, tym bezpieczniej”. Rzeczywistość: im dłuższa lista „obsługiwanych” rzeczy, tym częściej to znak, że trzymana jest kompatybilność wstecz. A kompatybilność bywa wygodna, ale potrafi też wpuścić stare, gorsze wybory do negocjacji.
Praktyczny finał: jak wybrać bez wchodzenia w kryptografię
Jeśli chcesz decyzji, która działa „w większości normalnych przypadków”, trzymaj się krótkich zasad:
- Najpierw protokół, potem algorytm: jeśli możesz, testuj WireGuard albo IKEv2 zanim zaczniesz żonglować AES-128/AES-256 w OpenVPN.
- W OpenVPN/IPsec celuj w AEAD: AES-GCM albo ChaCha20-Poly1305, zamiast CBC.
- Nie płać wydajnością za „256”, jeśli nie musisz: AES-128-GCM jest w praktyce bardzo mocny; częściej ogranicza Cię CPU/serwer/sieć niż „za krótkie klucze”.
- Jeśli sprzęt jest słaby (router/NAS), wybór „lżejszego” zestawu i protokołu zrobi różnicę szybciej niż kosmetyka w parametrach.
- Jeśli coś „magicznie” obiecuje ogromny zysk tylko po zmianie szyfru, sprawdź czerwone flagi: TCP w tunelu, odległa lokalizacja serwera, przeciążenie, MTU, stare składniki (SHA-1/MD5).
Źródła informacji
- FIPS PUB 197: Advanced Encryption Standard (AES). National Institute of Standards and Technology (NIST) (2001) – Oficjalna specyfikacja AES; podstawy bezpieczeństwa i parametry algorytmu.
- RFC 8439: ChaCha20 and Poly1305 for IETF Protocols. Internet Engineering Task Force (IETF) (2018) – Standard ChaCha20-Poly1305 (AEAD); opis konstrukcji i użycia w protokołach.
- WireGuard: Protocol and Cryptographic Specification. WireGuard – Opis zestawu kryptograficznego WireGuard (m.in. ChaCha20-Poly1305) i założeń.
