Laboratorium 4

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Algorytmy kryptograficzne symetryczne blokowe. Standard DES i Triple-DES.

Celem zadania jest przeprowadzenie kryptoanalitycznej oceny historycznego standardu szyfrowania Data Encryption Standard (DES) oraz jego rozwinięcia Triple-DES (3DES), ze szczególnym uwzględnieniem matematycznych i architektonicznych ograniczeń wynikających ze zbyt krótkiego klucza (56 bitów) oraz małego rozmiaru bloku (64 bity). Studenci analizują teoretyczne i praktyczne wektory ataków na DES: atak siłowy (Brute-Force za pomocą maszyn rozproszonych), kryptoanalizę różnicową i liniową oraz atak Meet-in-the-Middle redukujący przestrzeń klucza 2DES do zaledwie 2^57 operacji.

W części praktycznej studenci badają podatność Sweet32 (CVE-2016-2183) wynikającą z paradoksu dnia urodzin w szyfrach o 64-bitowym bloku w długotrwałych sesjach TLS, demonstrują odzyskanie poufnych danych sesyjnych oraz opracowują formalny plan migracji infrastruktury instytucji finansowej do standardu Advanced Encryption Standard (AES-256-GCM) zgodnie z zaleceniami NIST SP 800-131A.

Regionalny Bank Spółdzielczy w Płocku utrzymuje połączenia międzyoddziałowe oraz sesje komunikacyjne z bankomatami za pośrednictwem przestarzałych protokołów tunelowania, w których jako domyślny algorytm szyfrowania danych transmisyjnych skonfigurowano 3DES (Triple-DES w trybie EDE z trzema kluczami). W dokumentacji technicznej argumentowano, że efektywna długość klucza 3DES (168 bitów lub 112 bitów dla wersji dwukluczowej) zapewnia wystarczającą odporność na ataki siłowe.

Podczas audytu bezpieczeństwa przeprowadzonego na zlecenie KNF audytorzy zwrócili uwagę, że 3DES nadal operuje na archaicznym, 64-bitowym rozmiarze bloku (8 bajtów). W przypadku przesyłania dużych wolumenów danych w ramach jednej sesji (np. transmisja logów transakcyjnych, replikacja baz danych), zgodnie z paradoksem dnia urodzin kolizja bloków pojawia się już po przetworzeniu około 2^32 bloków (zaledwie ok. 32 GB danych), co umożliwia przeprowadzenie ataku Sweet32 i odszyfrowanie ciasteczek sesyjnych lub tokenów autoryzacyjnych.

Dodatkowo wykazano, że w niektórych starszych terminalach płatniczych POS nadal dopuszczony był pojedynczy DES (56 bitów), którego złamanie na współczesnych klastrach FPGA lub GPU zajmuje mniej niż 24 godziny.

Zarząd banku otrzymał nakaz natychmiastowego wycofania algorytmów DES i 3DES ze wszystkich systemów produkcyjnych i zastąpienia ich nowoczesnym standardem AES-256 w trybie uwierzytelnionym Galois/Counter Mode (GCM).

Grupa laboratoryjna przyjmuje zadanie kryptoanalityków. Studenci muszą zademonstrować matematyczne podstawy ataku Sweet32, zasymulować kolizję bloków w OpenSSL, wyliczyć prawdopodobieństwo wystąpienia kolizji, a następnie przygotować bezpieczną konfigurację środowiska OpenSSL i OpenVPN migrującą cały ruch na AES-256-GCM.

• Narzędzie OpenSSL 3.x z bibliotekami kryptograficznymi legacy i default
• Python 3 z biblioteką pycryptodome do symulacji kolizji blokowych (Paradoks urodzin)
• Narzędzie testssl.sh do wykrywania podatności Sweet32 w usługach sieciowych
• Wireshark do analizy negocjacji zestawów szyfrów 3DES w protokołach sieciowych
• Narzędzie benchmarkowe openssl speed do porównania wydajności DES vs 3DES vs AES

1. Zbadanie struktury matematycznej algorytmu DES: sieć Feistela, 16 rund, funkcja F, permutacje P i tablice S-Box.
2. Analiza długości klucza DES (64 bity, z czego 8 bitów to bity parzystości, co daje efektywne 56 bitów).
3. Zbadanie ataku Meet-in-the-Middle na algorytm Double-DES (2DES) i uzasadnienie konieczności stosowania potrójnego szyfrowania (3DES).
4. Analiza algorytmu Triple-DES w wariantach: 3-kluczowym (Keying Option 1, 168 bitów) oraz 2-kluczowym (Keying Option 2, 112 bitów).
5. Zbadanie matematycznych podstaw podatności Sweet32: wyprowadzenie wzoru na prawdopodobieństwo kolizji bloków P ≈ n^2 / (2 * 2^B).
6. Napisanie skryptu w języku Python symulującego wystąpienie kolizji w szyfrze o bloku 64-bitowym po przesłaniu około 2^32 bloków.
7. Demonstracja szyfrowania pliku za pomocą 3DES w OpenSSL: openssl enc -des-ede3-cbc -in dane.txt -out dane.enc.
8. Wykrycie podatności Sweet32 na serwerze testowym za pomocą skryptu testssl.sh -W target.local.
9. Przeprowadzenie testu wydajnościowego: openssl speed des des-ede3 aes-128-cbc aes-256-gcm.
10. Analiza wyników benchmarku: wykazanie, dlaczego 3DES jest 3-krotnie wolniejszy od DES i wielokrotnie wolniejszy od AES wspieranego sprzętowo przez instrukcje AES-NI.
11. Zaprojektowanie procedury migracji: wycofanie zestawów szyfrów zawierających 3DES z konfiguracji serwerów WWW, poczty i VPN.
12. Skonfigurowanie OpenSSL do wymuszenia nowoczesnych szyfrów: zmiana konfiguracji na AES-256-GCM z kluczem 256-bitowym i blokiem 128-bitowym.
13. Weryfikacja braku podatności Sweet32 po migracji do AES-256.
14. Opracowanie harmonogramu wycofania certyfikatów i kluczy 3DES z terminali płatniczych i bankomatów.
15. Sformułowanie formalnej opinii kryptograficznej dla zarządu banku dotyczącej niezgodności DES/3DES ze standardem PCI DSS v4.0.
16. Przygotowanie tabelarycznego zestawienia porównawczego właściwości DES, 3DES i AES (długość klucza, rozmiar bloku, liczba rund, znane ataki).
17. Sporządzenie sprawozdania laboratoryjnego z kompletnymi obliczeniami matematycznymi i listingami komend.

Warto pamiętać, że atak Sweet32 nie polega na złamaniu klucza 3DES, lecz na wykorzystaniu małego rozmiaru bloku (64 bity). W trybach takich jak CBC kolizja szyfrogramów (C_i = C_j) oznacza, że P_i ⊕ C_{i-1} = P_j ⊕ C_{j-1}. Jeśli napastnik zna treść jednego z bloków jawnych (np. standardowy nagłówek HTTP), może natychmiast odzyskać zawartość drugiego bloku (np. poufne ciasteczko sesyjne). W algorytmie AES rozmiar bloku wynosi 128 bitów, co przesuwa granicę kolizji do 2^64 bloków (ponad 250 miliardów gigabajtów), całkowicie neutralizując to zagrożenie.

Poniżej przedstawiono benchmark wydajnościowy algorytmów DES, 3DES oraz AES za pomocą wbudowanego narzędzia OpenSSL speed:

Wykrycie podatności Sweet32 na serwerze za pomocą narzędzia testssl.sh:

Bezpieczne szyfrowanie pliku symetrycznym algorytmem AES-256-GCM z wygenerowaniem tagu uwierzytelniającego:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Wpływ rozmiaru bloku szyfru (64 bity w DES/3DES vs 128 bitów w AES) na podatność na kolizje w oparciu o paradoks dnia urodzin.
2. Mechanizm ataku Sweet32 (CVE-2016-2183) w długotrwałych sesjach TLS i VPN umożliwiający deszyfrowanie ciasteczek sesyjnych w tekście jawnym.
3. Kryptoanaliza efektywnej długości klucza: 56 bitów w DES, podatność 2DES na atak Meet-in-the-Middle oraz 112 bitów bezpieczeństwa 3DES.
4. Wymogi formalnego wycofania algorytmów 3DES zgodnie ze standardami NIST SP 800-131A Rev. 2 oraz wytycznymi PCI DSS v4.0.
5. Procedura bezpiecznej migracji infrastruktury kryptograficznej do standardu Advanced Encryption Standard (AES-GCM z kluczem 256-bitowym).
6. Praktyczna weryfikacja podatności serwerów TLS na przestarzałe zestawy szyfrów 3DES za pomocą skanerów kryptograficznych testssl.sh i nmap.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna symulacja ataku Sweet32 dowiodła, że stosowanie szyfrów blokowych o 64-bitowej długości bloku stwarza krytyczne zagrożenie w długotrwałych połączeniach sieciowych. W oparciu o paradoks dnia urodzin kolizja bloków pojawia się już po przesłaniu około 32 gigabajtów danych, co pozwala podsłuchującemu napastnikowi na odzyskanie wrażliwych ciasteczek sesyjnych w tekście jawnym. Przeprowadzona kryptoanaliza potwierdziła ponadto, że efektywna siła 3-kluczowego 3DES wynosi zaledwie 112 bitów ze względu na ataki typu Meet-in-the-Middle, co dyskwalifikuje ten algorytm we współczesnych systemach. Wyłączenie przestarzałych zestawów szyfrów na serwerach i migracja do AES-256-GCM całkowicie wyeliminowały ryzyko ataków kolizyjnych oraz przyniosły wielokrotny wzrost przepustowości dzięki 128-bitowemu blokowi. Wdrożone zmiany stanowią realizację bezwzględnych zaleceń NIST SP 800-131A oraz standardu bezpieczeństwa płatności kartowych PCI DSS.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Algorytmy kryptograficzne symetryczne blokowe. Tryby pracy szyfrów blokowych.

Celem zadania jest przeprowadzenie dogłębnej analizy kryptoanalitycznej i technicznej czterech podstawowych trybów pracy szyfrów blokowych (Block Cipher Modes of Operation): Electronic Codebook (ECB), Cipher Block Chaining (CBC), Counter (CTR) oraz Galois/Counter Mode (GCM) na przykładzie algorytmu AES. Studenci badają zasady propagacji błędów, mechanizmy wektora inicjalizacyjnego (IV / Nonce) oraz fundamentalne zagrożenia wynikające ze stosowania trybu ECB (determinizm kryptograficzny i zachowanie struktury danych jawnych).

W części praktycznej studenci demonstrują słynny atak wizualny na tryb ECB przy użyciu nieskompresowanego obrazu bitmapowego (obrazek pingwina Tuxa), badają katastrofalne skutki ponownego użycia tego samego wektora IV w trybie CTR/GCM (Nonce Reuse Attack) oraz implementują bezpieczne szyfrowanie uwierzytelnione (Authenticated Encryption with Associated Data - AEAD) gwarantujące jednoczesną poufność i integralność.

Oprogramowanie medyczne PACS (Picture Archiving and Communication System) w Szpitalu Wojewódzkim w Białymstoku służy do archiwizacji i przesyłania badań obrazowych pacjentów (rezonans magnetyczny MRI, tomografia komputerowa CT, zdjęcia rentgenowskie RTG). Do szyfrowania przesyłanych plików DICOM zastosowano algorytm AES z kluczem 256-bitowym. Programista odpowiedzialny za moduł kryptograficzny wybrał najprostszy w implementacji tryb ECB (Electronic Codebook), argumentując, że AES-256 jest najsilniejszym dostępnym standardem.

Podczas audytu bezpieczeństwa testerzy przechwycili w sieci lokalnej zaszyfrowany plik badania tomograficznego. Mimo że plik był w 100% poprawnie zaszyfrowany silnym kluczem AES-256, testerzy bez znajomości klucza byli w stanie wyraźnie odczytać zarys narządów wewnętrznych pacjenta, zidentyfikować obecność guza nowotworowego oraz odczytać numer PESEL i nazwisko pacjenta zakodowane w nagłówku obrazu.

Wynikało to z faktu, że w trybie ECB każdy identyczny 16-bajtowy blok tekstu jawnego zawsze szyfruje się do identycznego 16-bajtowego bloku szyfrogramu. Jednolite tła i powtarzające się wzorce medyczne zostały w pełni odwzorowane w pliku zaszyfrowanym, co stanowiło drastyczne naruszenie tajemnicy lekarskiej i wymogów RODO.

Dyrekcja szpitala zleciła audytorom (grupie laboratoryjnej) natychmiastowe przeprowadzenie analizy porównawczej trybów pracy szyfrów blokowych, zademonstrowanie wycieku wzorców w ECB, zbadanie trybów CBC, CTR i GCM oraz wdrożenie bezpiecznego standardu szyfrowania dokumentacji medycznej.

Studenci muszą zasymulować szyfrowanie pliku graficznego BMP w trybach ECB, CBC i GCM, wykazać wyciek wzorców w ECB, zbadać wpływ losowości IV na unikalność szyfrogramów oraz przygotować rekomendacje wdrożeniowe dla deweloperów oprogramowania medycznego.

• Narzędzie OpenSSL 3.x CLI
• Przeglądarka obrazów i edytor graficzny (GIMP / ImageMagick)
• Python 3 z bibliotekami cryptography i Pillow (PIL)
• Narzędzie hexdump / xxd do inspekcji nagłówków plików graficznych
• Narzędzie ent do badania entropii plików zaszyfrowanych

1. Pobranie lub wygenerowanie nieskompresowanego pliku graficznego w formacie BMP o wyrazistych kontrastowych kształtach (np. logo uczelni lub pingwin Tux).
2. Zbadanie struktury pliku BMP: nagłówek 54 bajty (informacje o rozmiarze i palecie) oraz surowe dane pikseli.
3. Zaszyfrowanie pliku BMP algorytmem AES-128 w trybie ECB za pomocą OpenSSL: openssl enc -aes-128-ecb -in tux.bmp -out tux_ecb.enc -k TajneHaslo123.
4. Przywrócenie oryginalnego 54-bajtowego nagłówka BMP do pliku zaszyfrowanego za pomocą polecenia dd.
5. Otwarcie zmodyfikowanego pliku w przeglądarce graficznej i udokumentowanie widocznego konturu obrazu (dowód wycieku wzorców w ECB).
6. Zaszyfrowanie tego samego pliku BMP w trybie CBC z losowym wektorem IV: openssl enc -aes-128-cbc -in tux.bmp -out tux_cbc.enc -k TajneHaslo123.
7. Przywrócenie nagłówka BMP do pliku zaszyfrowanego CBC i zaobserwowanie całkowitego szumu pseudolosowego (brak jakichkolwiek wzorców).
8. Zbadanie entropii kryptograficznej obu plików za pomocą narzędzia ent: porównanie stopnia losowości bloków ECB vs CBC.
9. Zbadanie zasady działania trybu licznikowego (CTR): przekształcenie szyfru blokowego w szyfr strumieniowy za pomocą licznika i wektora Nonce.
10. Analiza zagrożenia Nonce Reuse w trybie CTR: wykazanie, że użycie tego samego wektora (Key, Nonce) dla dwóch wiadomości pozwala na odzyskanie XOR tekstów jawnych (C1 ⊕ C2 = P1 ⊕ P2).
11. Zbadanie trybu Galois/Counter Mode (GCM): połączenie trybu CTR z funkcją haszującą GHASH w ciele Galois GF(2^128).
12. Zaszyfrowanie pliku w trybie AES-256-GCM z wygenerowaniem 128-bitowego tagu uwierzytelniającego (Authentication Tag).
13. Zademonstrowanie wykrycia modyfikacji pojedynczego bitu szyfrogramu w trybie GCM (odrzucenie pliku z powodu błędu integralności).
14. Porównanie podatności trybów na błędy transmisji (propagacja błędów bitowych w ECB, CBC, CTR).
15. Opracowanie instrukcji bezpiecznego generowania wektorów IV (kryptograficznie silny generator liczb losowych /dev/urandom).
16. Przygotowanie formalnej rekomendacji zakazującej stosowania trybu ECB w jakimkolwiek module oprogramowania medycznego.
17. Sporządzenie sprawozdania laboratoryjnego z porównaniem wygenerowanych obrazów, analizą entropii i listingami poleceń.

Wizualny wyciek informacji w trybie ECB jest najbardziej uderzającym dowodem na to, że silny algorytm szyfrujący (jak AES-256) staje się bezużyteczny przy złym doborze trybu pracy. Tryb ECB może być bezpiecznie stosowany wyłącznie do szyfrowania pojedynczych bloków o długości dokładnie jednego bloku (16 bajtów), np. do zabezpieczenia klucza sesyjnego (Key Wrap). Do szyfrowania jakichkolwiek dłuższych danych należy bezwzględnie stosować szyfrowanie uwierzytelnione AEAD (AES-GCM lub ChaCha20-Poly1305).

Poniżej przedstawiono procedurę demonstracji wycieku danych w trybie ECB na pliku obrazu BMP:

Szyfrowanie tego samego obrazu w bezpiecznym trybie CBC z losowym wektorem inicjalizacyjnym (IV):

Badanie entropii plików za pomocą narzędzia ent (wartość maksymalna: 8.000000 bitów/bajt):

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza podatności trybu ECB (Electronic Codebook) na wyciek wzorców danych w wyniku deterministycznego szyfrowania identycznych bloków.
2. Znaczenie kryptograficzne losowego wektora inicjalizującego (IV) w trybie CBC oraz konsekwencje stosowania stałego lub przewidywalnego IV.
3. Przekształcenie szyfru blokowego w szyfr strumieniowy w trybach CTR (Counter) i OFB oraz krytyczny wymóg unikalności pary klucz i nonce.
4. Przewaga szyfrowania uwierzytelnionego AEAD w trybie GCM (Galois/Counter Mode) zapewniającego jednoczesną poufność i integralność danych.
5. Podatność trybu CBC na ataki manipulacji bitami tekstu szyfrowanego (Bit-Flipping Attack) przy braku zewnętrznego uwierzytelnienia HMAC.
6. Dobór optymalnego trybu pracy szyfru blokowego w architekturach bazodanowych, protokołach sieciowych oraz pamięciach masowych.

Przykładowe wnioski (wzór do sprawozdania): Eksperyment wizualny z szyfrowaniem obrazu bitmapowego dobitnie wykazał całkowitą nieprzydatność trybu ECB do ochrony danych o powtarzalnej strukturze, gdyż zachowuje on pełne kontury grafiki w tekście zaszyfrowanym. Zastosowanie trybu CBC z losowym wektorem inicjalizacyjnym skutecznie ukryło wszelkie wzorce statystyczne, dowodząc konieczności zapewnienia właściwości dyfuzji w całym potoku danych. Wykazano jednak, że tryb CBC bez mechanizmu MAC jest podatny na manipulacje poszczególnymi bitami, co pozwala napastnikowi na deterministyczne modyfikowanie tekstu jawnego po stronie odbiorcy. Wdrożenie trybu Galois/Counter Mode wyeliminowało tę podatność, oferując szyfrowanie uwierzytelnione ze sprzętowym wsparciem mnożenia w ciałach Galois. Wyniki badań jednoznacznie wskazują, że współczesne standardy bezpieczeństwa powinny bezwzględnie wymuszać stosowanie trybów AEAD, takich jak AES-GCM lub ChaCha20-Poly1305.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Algorytmy kryptograficzne symetryczne blokowe. Integralność i dopełnienie PKCS#7.

Celem zadania jest zbadanie klasycznego, wysoce wyrafinowanego ataku kryptograficznego typu Padding Oracle Attack (atak na wyrocznię dopełnienia) w szyfrach blokowych pracujących w trybie CBC ze standardem dopełnienia PKCS#7. Studenci poznają mechanizm działania kanałów bocznych (Side-Channel), w których aplikacja nieświadomie ujawnia informację o poprawności lub błędzie dopełnienia kryptograficznego w komunikatach błędów HTTP (np. błąd 500 Padding Error vs 200/404) lub w czasie odpowiedzi serwera (Timing Attack).

W ramach laboratorium studenci przeprowadzają symulację ataku Padding Oracle w środowisku testowym, deszyfrując pojedyncze bajty tajnego tokena bez znajomości klucza AES, a następnie wdrażają odporną na tego typu ataki architekturę kryptograficzną opartą na szyfrowaniu uwierzytelnionym AES-GCM (Authenticated Encryption) lub mechanizmie Encrypt-then-MAC (HMAC-SHA256).

Portal korporacyjny PolskieSieci Gazowe S.A. wykorzystywał do autoryzacji sesji użytkowników zaszyfrowane ciasteczka przesyłane w nagłówku HTTP. Ciasteczko zawierało zaszyfrowany identyfikator użytkownika, rolę oraz znacznik czasu, zabezpieczone algorytmem AES-128-CBC z dopełnieniem PKCS#7. Po odszyfrowaniu ciasteczka serwer sprawdzał poprawność paddingu; jeśli padding był błędny, aplikacja zwracała specyficzny komunikat błędu 'HTTP 500 - Invalid Padding', natomiast w przypadku poprawnego paddingu, ale nieprawidłowych danych użytkownika, serwer zwracał błąd 'HTTP 200 - User Not Found'.

Różnica w komunikatach błędu stworzyła idealną wyrocznię dopełnienia (Padding Oracle). Zespół audytorów, wykorzystując zautomatyzowane narzędzie (PadBuster), wysłał serię zmodyfikowanych żądań HTTP (średnio 128 zapytań na bajt). Modyfikując ostatni bajt przedostatniego bloku szyfrogramu (wektora IV lub bloku C_{n-1}), audytorzy byli w stanie odgadnąć wartość bajtu jawnego na podstawie informacji, czy serwer zgłosił błąd paddingu.

W niespełna 10 minut audytorzy odszyfrowali zawartość całego ciasteczka sesyjnego administratora, a następnie – wykorzystując właściwości trybu CBC – sfałszowali nowe ciasteczko nadające im rolę 'SuperAdmin' bez znajomości klucza szyfrującego AES. Podatność ta umożliwiła całkowite przejęcie kontroli nad systemem zarządzania stacjami redukcyjno-pomiarowymi gazu.

Dyrektor ds. Cyberbezpieczeństwa nakazał natychmiastowe zlikwidowanie luki Padding Oracle i zastąpienie podatnego mechanizmu CBC szyfrowaniem uwierzytelnionym AEAD.

Zadaniem grupy laboratoryjnej jest odtworzenie podatności w środowisku kontrolowanym, zademonstrowanie odszyfrowania tekstu jawnego za pomocą narzędzia PadBuster / skryptu w Pythonie, a następnie przepisanie modułu kryptograficznego na standard AES-GCM, w którym jakakolwiek modyfikacja szyfrogramu powoduje natychmiastowe odrzucenie wiadomości przez tag uwierzytelniający przed sprawdzeniem jakiegokolwiek paddingu.

• Środowisko podatne: skrypt Python Flask / PHP symulujący wyrocznię dopełnienia (Padding Oracle)
• Narzędzie audytorskie PadBuster (skrypt Perl / Python do automatycznej eksploatacji padding oracle)
• OpenSSL 3.x do implementacji szyfrowania AES-256-GCM
• Narzędzie cURL do testowania odpowiedzi serwera na zmodyfikowane bloki
• Biblioteka Cryptography (Python) do implementacji bezpiecznego potoku AEAD

1. Zbadanie specyfikacji standardu dopełnienia PKCS#7 (uzupełnianie brakujących bajtów wartością liczbową równą liczbie dodanych bajtów, np. 0x01 lub 0x04 0x04 0x04 0x04).
2. Zrozumienie matematycznej zależności w trybie CBC: P_i = D_K(C_i) ⊕ C_{i-1}.
3. Zidentyfikowanie różnic w odpowiedziach podatnego serwera: analiza kodów HTTP i czasów odpowiedzi dla poprawnego i błędnego paddingu.
4. Przygotowanie środowiska testowego z podatnym endpointem /api/auth/profile przyjmującym ciasteczko CBC.
5. Uruchomienie narzędzia PadBuster przeciwko podatnemu endpointowi: padbuster http://target/api/auth/profile <ciasteczko> 16 -encoding 0.
6. Zaobserwowanie procesu odgadywania bajtów tekstu jawnego od końca bloku (od bajtu 16 do 1).
7. Zanotowanie liczby zapytań HTTP wymaganych do odszyfrowania jednego 16-bajtowego bloku (maksymalnie 256 zapytań na bajt).
8. Zademonstrowanie odzyskania pełnego tekstu jawnego ciasteczka (role=admin;user_id=1).
9. Zademonstrowanie ataku fałszowania (CBC Bit-Flipping / CBC Forgery): wygenerowanie ważnego zaszyfrowanego ciasteczka dla nowego użytkownika.
10. Analiza przyczyn luki: oddzielenie szyfrowania od uwierzytelnienia (brak weryfikacji integralności wiadomości przed deszyfrowaniem).
11. Zbadanie standardu szyfrowania uwierzytelnionego AEAD (Authenticated Encryption with Associated Data).
12. Przepisanie modułu kryptograficznego z AES-CBC na AES-256-GCM z wykorzystaniem 128-bitowego tagu autoryzacji (Auth Tag).
13. Weryfikacja zachowania modułu AES-GCM przy próbie modyfikacji pojedynczego bitu szyfrogramu (natychmiastowy wyjątek InvalidTagException).
14. Wdrożenie obsługi ujednoliconych komunikatów błędów: jednakowy czas odpowiedzi i identyczny kod błędu HTTP 401 dla wszystkich nieudanych prób autoryzacji.
15. Zbadanie mechanizmu stałoczasowego porównywania skrótów (hmac.compare_digest / CRYPTO_memcmp) w celu eliminacji ataków czasowych.
16. Ponowne uruchomienie narzędzia PadBuster przeciwko zabezpieczonemu endpointowi i potwierdzenie całkowitej nieskuteczności ataku.
17. Skompilowanie raportu laboratoryjnego z analizą matematyczną ataku i bezpiecznym kodem AES-GCM.

Atak Padding Oracle jest możliwy wyłącznie wtedy, gdy system deszyfruje wiadomość i sprawdza padding PRZED upewnieniem się, że wiadomość nie została zmodyfikowana w trakcie transmisji. Wdrożenie szyfrowania uwierzytelnionego AEAD (takiego jak AES-GCM) całkowicie eliminuje ten problem, ponieważ odbiorca najpierw weryfikuje kryptograficzny tag autoryzacyjny. Jeśli tag się nie zgadza, operacja deszyfrowania zostaje natychmiast przerwana, a błędy paddingu w ogóle nie są ewaluowane.

Poniżej przedstawiono implementację bezpiecznego szyfrowania i deszyfrowania AES-256-GCM w języku Python uniemożliwiającą ataki Padding Oracle:

Próba modyfikacji choćby jednego bitu w szyfrogramie GCM powoduje natychmiastowe odrzucenie bez ujawniania informacji o paddingu:

Eksploatacja podatnej wyroczni CBC za pomocą narzędzia PadBuster w środowisku testowym:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Mechanizm dopełnienia blokowego PKCS#7 w trybie CBC oraz analiza informacji ujawnianych przez wyrocznię dopełnienia w aplikacjach webowych.
2. Matematyczny model ataku Padding Oracle: bajt po bajcie odzyskiwanie tekstu jawnego bez znajomości klucza szyfrującego w kanale podatnym.
3. Porównanie paradygmatów MAC-then-Encrypt, Encrypt-and-MAC oraz zalecanej architektury Encrypt-then-MAC w przeciwdziałaniu atakom wyroczni.
4. Eliminacja podatności na ataki czasowe (Timing Attacks) poprzez projektowanie operacji kryptograficznych wykonywanych w stałym czasie.
5. Zastosowanie szyfrowania uwierzytelnionego (AEAD AES-256-GCM) uniemożliwiającego przetwarzanie sfałszowanego szyfrogramu przed weryfikacją tagu MAC.
6. Analiza historycznych podatności kryptograficznych wykorzystujących wyrocznie dopełnienia (POODLE, Lucky Thirteen, ASP.NET Padding Oracle).

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzona symulacja ataku na wyrocznię dopełnienia PKCS#7 dowiodła, że subtelne różnice w komunikatach błędów serwera pozwalają na całkowite odszyfrowanie wiadomości CBC bez jakiejkolwiek wiedzy o kluczu tajnym. Napastnik manipulując ostatnim blokiem szyfrogramu i obserwując reakcję wyroczni jest w stanie odzyskać każdy bajt tekstu jawnego w maksymalnie 256 zapytaniach na bajt. Badanie potwierdziło fundamentalną wadę koncepcji unieważniania danych dopiero po deszyfracji, co stanowiło źródło znanych historycznych podatności takich jak POODLE czy Lucky Thirteen. Zastąpienie podatnego trybu CBC szyfrowaniem uwierzytelnionym AES-GCM całkowicie wyeliminowało ten problem, ponieważ niespójny kryptograficznie tag uwierzytelniający powoduje natychmiastowe odrzucenie pakietu przed rozpoczęciem dekodowania. Wdrożenie architektury AEAD stanowi najpewniejszy środek zaradczy eliminujący ataki typu Chosen-Ciphertext Attacks na warstwę kryptograficzną.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia asymetryczna. Algorytm RSA, parametry matematyczne i generowanie kluczy.

Celem zadania jest zbadanie podstaw matematycznych, właściwości kryptograficznych oraz praktycznych aspektów generowania i zarządzania asymetrycznymi kluczami algorytmu RSA (Rivest-Shamir-Adleman) przy użyciu narzędzia OpenSSL 3.x. Studenci analizują strukturę modułu RSA (n = p * q), znaczenie publicznego wykładnika (e = 65537) oraz prywatnego wykładnika (d), badając podatności wynikające ze stosowania zbyt krótkich kluczy (RSA 512, 1024 bity) podatnych na faktoryzację za pomocą uogólnionego sita ciał liczbowych (GNFS).

W części praktycznej studenci dokonują rygorystycznego benchmarku wydajności operacji asymetrycznych (podpisywanie vs weryfikacja podpisu, szyfrowanie vs deszyfrowanie) dla długości kluczy 2048, 3072 i 4096 bitów. Projekt uczy inspekcji struktury kluczy w formacie ASN.1/DER (OpenSSL asn1parse), konwersji pomiędzy formatami PEM i DER oraz bezpiecznego zabezpieczania klucza prywatnego hasłem frazowym z wykorzystaniem nowoczesnych algorytmów derywacji klucza (KDF).

Główny Urząd Geodezji i Kartografii (GUGiK) wdraża system bezpiecznej wymiany cyfrowych operatów geodezyjnych i map katastralnych. Zgodnie z wytycznymi technicznymi, każdy dokument przekazywany do państwowego zasobu geodezyjnego musi zostać podpisany cyfrowo przez uprawnionego geodetę za pomocą klucza asymetrycznego RSA.

W trakcie audytu bezpieczeństwa oprogramowania używanego przez geodetów ujawniono, że starsze aplikacje nadal generowały klucze RSA o długości zaledwie 1024 bitów z publicznym wykładnikiem e=3, co zgodnie z aktualnymi wytycznymi NIST i Narodowego Centrum Bezpieczeństwa Cyberprzestrzeni (NCBC) stanowi krytyczne zagrożenie (klucze RSA 1024 są uznawane za złamane lub możliwe do sfaktoryzowania przez zaawansowane grupy dysponujące odpowiednimi zasobami obliczeniowymi).

Dodatkowo część wykonawców skarżyła się, że generowanie kluczy 4096-bitowych powoduje znaczne spowolnienie pracy serwerów walidujących przy masowym podpisywaniu tysięcy plików dziennie, co wywołało dyskusję na temat optymalnego doboru długości klucza (kompromis pomiędzy poziomem bezpieczeństwa w horyzoncie 10 lat a wydajnością obliczeniową).

Główny Geodeta Kraju powołał zespół audytorów (grupę laboratoryjną) w celu opracowania jednoznacznego Standardu Kryptograficznego Kluczy Asymetrycznych dla całego resortu.

Zadaniem studentów jest wygenerowanie kluczy o długościach 1024, 2048, 3072 i 4096 bitów, przeprowadzenie precyzyjnych testów wydajnościowych (liczba operacji podpisywania i weryfikacji na sekundę za pomocą openssl speed), zbadanie wewnętrznej struktury kluczy poleceniem asn1parse, zaszyfrowanie klucza prywatnego silnym hasłem frazowym oraz sformułowanie rekomendacji dotyczącej minimalnej bezpiecznej długości klucza (min. 3072 bity do roku 2030 wg NIST).

• Narzędzie OpenSSL 3.x CLI
• Narzędzie openssl speed do pomiaru wydajności operacji kryptograficznych
• Narzędzie asn1parse / dumpasn1 do inspekcji struktur ASN.1
• Narzędzie factordb-py / msieve do demonstracji faktoryzacji słabych modułów RSA
• Skrypt Python (moduł cryptography) do automatyzacji testów wydajnościowych

1. Zbadanie podstaw matematycznych RSA: generowanie liczb pierwszych p i q, obliczanie modułu n, funkcji Eulera φ(n) oraz prywatnego wykładnika d = e^-1 mod φ(n).
2. Analiza znaczenia standardowego wykładnika publicznego e = 65537 (liczba pierwsza Fermata F_4) pod kątem ochrony przed atakami Coppersmitha.
3. Wygenerowanie pary kluczy RSA 2048 bitów za pomocą nowoczesnego polecenia: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out rsa2048_priv.pem.
4. Wygenerowanie kluczy RSA o długościach 3072 oraz 4096 bitów.
5. Wyodrębnienie klucza publicznego z klucza prywatnego: openssl pkey -in rsa2048_priv.pem -pubout -out rsa2048_pub.pem.
6. Inspekcja parametrów matematycznych klucza za pomocą polecenia: openssl pkey -in rsa2048_priv.pem -text -noout.
7. Zbadanie struktury pliku PEM w notacji ASN.1 za pomocą polecenia openssl asn1parse -in rsa2048_priv.pem.
8. Zaszyfrowanie klucza prywatnego silnym hasłem frazowym przy użyciu algorytmu AES-256-CBC i PBKDF2: openssl pkey -in rsa2048_priv.pem -aes256 -out rsa2048_encrypted.pem.
9. Przeprowadzenie testu wydajnościowego algorytmu RSA za pomocą wbudowanego narzędzia benchmarkowego: openssl speed rsa.
10. Porównanie liczby operacji podpisywania na sekundę (sign/s) oraz weryfikacji na sekundę (verify/s) dla długości 2048, 3072 i 4096 bitów.
11. Analiza asymetrii operacji RSA: wykazanie, dlaczego weryfikacja podpisu (z małym wykładnikiem e) jest wielokrotnie szybsza niż generowanie podpisu (z dużym wykładnikiem d).
12. Praktyczna demonstracja podpisywania dokumentu PDF/tekstowego za pomocą openssl dgst -sha256 -sign rsa2048_priv.pem -out dokument.sig dokument.pdf.
13. Weryfikacja poprawności podpisu za pomocą klucza publicznego: openssl dgst -sha256 -verify rsa2048_pub.pem -signature dokument.sig dokument.pdf.
14. Zademonstrowanie wykrycia modyfikacji choćby jednego bajtu w dokumencie (błąd Verification Failure).
15. Zbadanie podatności krótkiego klucza RSA 512 bitów za pomocą internetowej bazy faktoryzacji FactorDB.
16. Opracowanie wytycznych dla resortu: ustalenie minimalnej długości klucza RSA na 3072 bity (równoważnik 128 bitów bezpieczeństwa symetrycznego).
17. Podsumowanie wyników w sprawozdaniu laboratoryjnym z tabelami wydajności i analizą kryptoanalityczną.

Zwróćcie uwagę na asymetrię wydajnościową algorytmu RSA. Ponieważ wykładnik publiczny `e` jest małą liczbą (zazwyczaj 65537 = 2^16 + 1, posiadającą zaledwie dwa bity równe 1 w zapisie binarnym), operacja szyfrowania lub weryfikacji podpisu wymaga zaledwie 17 mnożeń modularnych. Natomiast wykładnik prywatny `d` ma taką samą długość bitową jak moduł `n` (np. 3072 bity pełne losowych jedynek), co oznacza, że operacja deszyfrowania lub składania podpisu jest około 30-50 razy wolniejsza!

Poniżej przedstawiono benchmark wydajnościowy algorytmu RSA dla różnych długości kluczy za pomocą openssl speed:

Inspekcja wewnętrznych parametrów matematycznych klucza RSA (moduł n, liczby p i q, wykładnik d):

Podpisanie dokumentu urzędowego funkcją SHA-256 i weryfikacja poprawności podpisu:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Podstawy matematyczne kryptosystemu RSA: dobór liczb pierwszych, problem faktoryzacji dużych liczb (IFP) oraz właściwości stałej e równej 65537.
2. Porównanie złożoności obliczeniowej i poziomu bezpieczeństwa kluczy RSA o długości 2048, 3072 i 4096 bitów według wytycznych NIST SP 800-57.
3. Asymetria wydajnościowa algorytmu RSA: drastyczna różnica w czasie wykonywania operacji prywatnych (podpis) i publicznych (weryfikacja).
4. Audyt integralności i poprawności struktury klucza RSA (parametry chińskiego twierdzenia o resztach CRT) za pomocą narzędzi OpenSSL.
5. Podatności implementacyjne RSA: ataki Bleichenbachera na schemat dopełnienia PKCS#1 v1.5 oraz konieczność migracji do RSA-OAEP i RSA-PSS.
6. Perspektywy czasowe bezpieczeństwa RSA w obliczu rozwoju algorytmu Shora i komputerów kwantowych oraz kierunki migracji do kryptografii postkwantowej.

Przykładowe wnioski (wzór do sprawozdania): Pomiary wydajnościowe operacji RSA jednoznacznie wykazały gigantyczną asymetrię pomiędzy błyskawiczną weryfikacją podpisu z małym wykładnikiem e=65537 a kosztownym obliczeniowo procesem generowania podpisu kluczem prywatnym. Przejście z klucza o długości 2048 bitów do rozmiaru 4096 bitów spowodowało niemal siedmiokrotny spadek liczby generowanych podpisów na sekundę przy wzroście bezpieczeństwa do poziomu zaledwie 128 bitów symetrycznych. Szczegółowy audyt struktury ASN.1 wygenerowanych kluczy potwierdził obecność poprawnych parametrów chińskiego twierdzenia o resztach, które przyspieszają operacje prywatne blisko czterokrotnie. Badania wykazały również krytyczną potrzebę wycofania przestarzałego schematu dopełnienia PKCS#1 v1.5 na rzecz standardów RSA-PSS i RSA-OAEP odpornych na ataki wyroczni Bleichenbachera. Zgodnie z wytycznymi NIST klucze RSA 2048-bitowe należy bezwzględnie zastępować kluczami co najmniej 3072-bitowymi lub migrować do znacznie wydajniejszej kryptografii opartej na krzywych eliptycznych.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia asymetryczna. Krzywe eliptyczne, problem logarytmu dyskretnego ECDLP.

Celem zadania jest zbadanie nowoczesnej kryptografii opartej na krzywych eliptycznych (Elliptic Curve Cryptography - ECC) oraz przeprowadzenie rygorystycznego porównania kryptoanalitycznego i wydajnościowego pomiędzy tradycyjnymi krzywymi NIST (krzywe Weierstrassa, np. secp256r1 / prime256v1) a nowoczesnymi krzywymi Montgomery'ego i Edwardsa zaprojektowanymi przez Daniela J. Bernsteina (Curve25519: algorytm wymiany kluczy X25519 oraz podpis cyfrowy Ed25519). Studenci analizują trudność problemu dyskretnego logarytmu na krzywych eliptycznych (ECDLP), badając dlaczego klucz ECC o długości zaledwie 256 bitów zapewnia taki sam poziom bezpieczeństwa co 3072-bitowy klucz RSA.

W części praktycznej studenci badają odporność implementacji na ataki z wykorzystaniem kanałów bocznych (Side-Channel Timing Attacks) i błędów weryfikacji punktów (Invalid Curve Attacks), mierzą zużycie zasobów i czas generowania podpisów narzędziem openssl speed, generują pary kluczy Ed25519 oraz wdrażają je w bezpiecznej infrastrukturze kluczy SSH i certyfikatów TLS.

Firma telekomunikacyjna IoT SmartGrid Polska Sp. z o.o. zarządza siecią 100 000 inteligentnych liczników energii elektrycznej (Smart Meters) komunikujących się z serwerami centralnymi za pośrednictwem sieci komórkowej LTE-M / NB-IoT. Każdy licznik jest mikrokontrolerem o ograniczonych zasobach pamięci RAM (zaledwie kilkadziesiąt kilobajtów) i zasilaniu bateryjnym, który co 15 minut musi podpisać cyfrowo pakiet danych telemetrycznych i przesłać go do bazy rozliczeniowej.

Początkowo w projekcie planowano użycie standardu RSA-2048, jednakże testy terenowe wykazały, że rozmiar kluczy i podpisu (256 bajtów na każdą ramkę) generuje zbyt wysoki narzut na transfer danych telemetrycznych, a operacja podpisywania RSA drenuje baterię mikrokontrolera w ciągu kilku miesięcy.

Zarząd nakazał przejście na kryptografię krzywych eliptycznych (ECC). Pojawił się jednak spór techniczny: część inżynierów rekomendowała standardowe krzywe NIST P-256 (secp256r1), podczas gdy zespół ds. cyberbezpieczeństwa wskazał na potencjalne ryzyko ukrytych podatności (niewyjaśnione stałe w generatorze parametrów NIST, podatność na ataki czasowe przy złej implementacji) i zażądał wdrożenia bezpiecznej, nowoczesnej krzywej Ed25519 (Edwards-curve Digital Signature Algorithm), która charakteryzuje się stałoczasową implementacją (constant-time) i odpornością na ataki side-channel.

Grupa laboratoryjna przyjmuje zadanie wykonania niezależnego studium porównawczego. Studenci muszą zbadać właściwości matematyczne obu krzywych, przeprowadzić testy wydajnościowe w OpenSSL, wygenerować klucze Ed25519 oraz porównać narzut rozmiaru podpisu (zaledwie 64 bajty w Ed25519 w porównaniu z 256 bajtami w RSA).

Sprawozdanie musi zawierać precyzyjną analizę matematyczną równania krzywej Edwardsa (-x^2 + y^2 = 1 - (121665/121666)x^2y^2), porównanie benchmarków CPU i rozmiarów kluczy oraz instrukcję wdrożenia Ed25519 w środowisku IoT.

• Narzędzie OpenSSL 3.x z obsługą algorytmów X25519 i Ed25519
• Narzędzie openssl speed do pomiaru wydajności ecdsa vs ed25519 vs rsa
• OpenSSH z obsługą kluczy ssh-ed25519
• Python 3 z biblioteką cryptography (moduły ed25519 i x25519)
• Narzędzie asn1parse do inspekcji formatów kluczy ECC

1. Zbadanie równania Weierstrassa dla krzywej NIST P-256 (y^2 = x^3 - 3x + b mod p) oraz równania skręconej krzywej Edwardsa dla Ed25519.
2. Analiza problemu dyskretnego logarytmu na krzywych eliptycznych (ECDLP) i porównanie siły kryptograficznej (ECC 256 bit ≈ RSA 3072 bit ≈ 128 bitów symetrycznych).
3. Wygenerowanie klucza prywatnego ECDSA opartego na krzywej NIST P-256: openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:prime256v1 -out ec_p256_priv.pem.
4. Wygenerowanie klucza prywatnego Ed25519 za pomocą OpenSSL: openssl genpkey -algorithm ED25519 -out ed25519_priv.pem.
5. Wyodrębnienie kluczy publicznych i porównanie ich rozmiarów w formacie PEM i surowym binarnym (klucz publiczny Ed25519 to zaledwie 32 bajty!).
6. Zbadanie cech stałoczasowej implementacji Ed25519: brak instrukcji warunkowych zależnych od tajnych bitów klucza (ochrona przed Timing Attacks).
7. Przeprowadzenie benchmarku wydajnościowego za pomocą OpenSSL: openssl speed ecdsap256 ed25519.
8. Porównanie liczby operacji na sekundę: wykazanie wyższości Ed25519 w operacjach generowania i weryfikacji podpisu.
9. Złożenie podpisu cyfrowego pod pakietem telemetrycznym za pomocą Ed25519: openssl dgst -sign ed25519_priv.pem -out telemetria.sig telemetria.json.
10. Weryfikacja rozmiaru wygenerowanego podpisu cyfrowego (dokładnie 64 bajty w formacie surowym).
11. Weryfikacja podpisu za pomocą klucza publicznego Ed25519: openssl dgst -verify ed25519_pub.pem -signature telemetria.sig telemetria.json.
12. Wygenerowanie bezpiecznej pary kluczy do uwierzytelniania administratorów w systemie SSH za pomocą nowoczesnego algorytmu: ssh-keygen -t ed25519 -C 'admin@smartgrid.pl'.
13. Zbadanie różnic w algorytmie uzgadniania kluczy sesyjnych X25519 (Diffie-Hellman na krzywej Curve25519).
14. Napisanie skryptu w języku Python demonstrującego proces wymiany kluczy X25519 pomiędzy dwoma urządzeniami IoT.
15. Opracowanie analizy bilansu energetycznego i oszczędności pasma transmisyjnego w sieci LTE-M przy migracji z RSA na Ed25519.
16. Sformułowanie oficjalnej rekomendacji technicznej dotyczącej standardu kryptograficznego dla platformy IoT.
17. Skompilowanie raportu laboratoryjnego z tabelami porównawczymi i listingami kodu źródłowego.

Zasadniczą zaletą Ed25519 w porównaniu z klasycznym ECDSA na krzywych NIST jest całkowita odporność na błędy generatora liczb losowych podczas podpisywania. W algorytmie ECDSA użycie tej samej liczby losowej 'k' do podpisania dwóch różnych wiadomości pozwala każdemu obserwatorowi na natychmiastowe obliczenie klucza prywatnego (taka luka doprowadziła m.in. do słynnego złamania zabezpieczeń konsoli PlayStation 3). Ed25519 jest algorytmem deterministycznym: wartość 'k' jest wyliczana kryptograficznie ze skrótu klucza prywatnego i wiadomości, co całkowicie eliminuje to śmiertelne zagrożenie.

Poniżej przedstawiono benchmark wydajnościowy algorytmów ECDSA P-256 oraz Ed25519 za pomocą openssl speed:

Generowanie pary kluczy Ed25519 i sprawdzenie zwięzłego formatu klucza w OpenSSL:

Implementacja bezpiecznej wymiany kluczy X25519 w języku Python z modułem cryptography:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Podstawy matematyczne kryptografii na krzywych eliptycznych: równanie Weierstrassa a krzywe Edwardsa i Montgomery'ego oraz problem ECDLP.
2. Porównanie długości klucza i poziomu bezpieczeństwa ECC z klasycznym RSA (klucz ECC 256-bitowy odpowiada sile klucza RSA 3072-bitowego).
3. Analiza kontrowersji wokół stałych krzywej NIST P-256 (secp256r1) w porównaniu do w pełni transparentnej konstrukcji krzywej Curve25519.
4. Właściwości implementacyjne Curve25519 / Ed25519: naturalna odporność na ataki czasowe (Side-Channel Timing Attacks) dzięki operacjom w stałym czasie.
5. Wydajność operacji wymiany kluczy (X25519) oraz podpisów cyfrowych (Ed25519, RFC 8032) w porównaniu ze standardem ECDSA na krzywych NIST.
6. Wdrażanie nowoczesnych algorytmów ECC w protokołach TLS 1.3, SSHv2, WireGuard oraz systemach bezpiecznej poczty elektronicznej.

Przykładowe wnioski (wzór do sprawozdania): Badania benchmarkingowe algorytmów na krzywych eliptycznych wykazały druzgocącą przewagę protokołu Ed25519 i wymiany X25519 nad tradycyjnym standardem NIST P-256. Konstrukcja krzywej Edwardsa umożliwia wykonywanie kompletnych formuł dodawania punktów w stałym czasie, co z natury eliminuje ryzyko ataków kryptoanalitycznych opartych na wyciekach czasowych. Zastosowanie kluczy o długości 256 bitów zapewniło równoważny poziom bezpieczeństwa do 3072-bitowego klucza RSA, redukując rozmiar nagłówków protokołów i czas przetwarzania o ponad 80%. Transparentne pochodzenie parametrów matematycznych krzywej Curve25519 usuwa obawy dotyczące potencjalnych osłabień ze strony agencji rządowych, obecne przy parametrach krzywych Weierstrassa. Z tych powodów w nowoczesnych architekturach teleinformatycznych, takich jak protokoły WireGuard i TLS 1.3, algorytmy rodziny 25519 stanowią bezdyskusyjny standard pierwszego wyboru.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia asymetryczna. Protokół wymiany kluczy Diffie-Hellmana i utajnianie w przód.

Celem zadania jest zbadanie mechanizmu matematycznego i protokolarnego uzgadniania wspólnego klucza symetrycznego przez niezabezpieczony kanał komunikacyjny przy użyciu protokołu Diffie-Hellmana (DH) oraz jego efemerycznych wariantów: Finite Field Diffie-Hellman Ephemeral (DHE) i Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). Studenci analizują fundamentalną dla współczesnej kryptografii właściwość Perfect Forward Secrecy (PFS) – gwarancję, że skompromitowanie długoterminowego klucza prywatnego serwera w przyszłości nie pozwoli na odszyfrowanie nagranego wcześniej archiwalnego ruchu sieciowego.

W części praktycznej studenci przeprowadzają symulację ataku typu Man-in-the-Middle (MitM) na nieuwierzytelniony protokół Diffie-Hellmana, badają podatność Logjam (słabe parametry grup DH 512/1024 bity), implementują bezpieczną wymianę kluczy z uwierzytelnieniem asymetrycznym (podpis RSA/ECDSA) oraz konfigurują bezpieczne grupy Diffie-Hellmana (RFC 7919 / ffdhe3072) i krzywe eliptyczne w serwerze OpenSSL i demonie SSH.

Krajowa Agencja Informacyjna 'Monitor' przesyła poufne depesze dziennikarskie oraz materiały śledcze pomiędzy korespondentami wojennymi a centralą w Warszawie. W przeszłości do zabezpieczenia tuneli komunikacyjnych stosowano statyczną wymianę kluczy RSA (klient szyfrował symetryczny klucz sesyjny kluczem publicznym serwera i przesyłał go przez sieć).

Podczas audytu bezpieczeństwa eksperci uświadomili kierownictwu agencji, że wrogie służby specjalne stosują strategię 'Harvest Now, Decrypt Later' (Zbieraj teraz, odszyfruj później): masowo rejestrują i archiwizują cały zaszyfrowany ruch internetowy agencji. W przypadku, gdy za 5 lub 10 lat serwer agencji zostanie przejęty lub klucz prywatny RSA zostanie ujawniony (np. w wyniku kradzieży fizycznej serwera lub nakazu sądowego), napastnicy będą mogli jednym kluczem odszyfrować wszystkie nagrane terabajty depesz z ostatnich 10 lat, dekonspirując źródła dziennikarskie.

Co więcej, w konfiguracji części routerów VPN nadal stosowano grupę DH 1024-bitową (Diffie-Hellman Group 2), co w świetle badań nad atakiem Logjam czyni wymianę klucza podatną na złamanie przez podmioty państwowe dysponujące superkomputerami.

Dyrektor agencji podjął decyzję o bezwzględnym wdrożeniu protokołów gwarantujących Perfect Forward Secrecy (PFS) dla wszystkich kanałów komunikacji. Klucze sesyjne muszą być generowane efemerycznie (każda sesja posiada unikalny klucz niszczony natychmiast po zakończeniu transmisji), a parametry wymiany kluczy muszą spełniać najwyższe standardy kryptograficzne.

Zespół studentów ma za zadanie zasymulować matematyczny przebieg protokołu Diffie-Hellmana w języku Python, zademonstrować atak Man-in-the-Middle na sesję pozbawioną podpisu cyfrowego, skonfigurować bezpieczne parametry grup DHE (min. 3072 bity wg RFC 7919) oraz zweryfikować obecność PFS w sesjach TLS.

• Narzędzie OpenSSL 3.x z modułami dhparam i s_client
• Python 3 z bibliotekami cryptography i math do symulacji matematycznej protokołu DH
• Wireshark do inspekcji ramek ServerKeyExchange i ClientKeyExchange w protokole TLS
• Narzędzie testssl.sh z testem wsparcia dla Forward Secrecy (testssl.sh -f)
• Serwer OpenSSH z konfiguracją KexAlgorithms

1. Zbadanie matematycznych podstaw protokołu Diffie-Hellmana: duża liczba pierwsza p, generator g, tajne wykładniki a i b, wartości publiczne A = g^a mod p oraz B = g^b mod p.
2. Wyprowadzenie dowodu tożsamości wspólnego sekretu: K = B^a mod p = (g^b)^a = g^(ab) mod p = (g^a)^b = A^b mod p.
3. Napisanie skryptu w języku Python symulującego wymianę kluczy pomiędzy dwiema stronami (Alice i Bob).
4. Zademonstrowanie ataku Man-in-the-Middle (Mallory w środku) na protokół DH pozbawiony uwierzytelnienia.
5. Analiza, w jaki sposób podpis cyfrowy (RSA / ECDSA) chroni protokół Diffie-Hellmana przed atakiem MitM (podpisywanie wartości efemerycznych A i B).
6. Zbadanie pojęcia Perfect Forward Secrecy (PFS): dlaczego zniszczenie efemerycznych wartości a i b po zakończeniu sesji uniemożliwia późniejsze odszyfrowanie ruchu.
7. Analiza podatności Logjam: niebezpieczeństwo stosowania standardowych grup DH o długości 512 i 1024 bitów.
8. Wygenerowanie bezpiecznych parametrów Diffie-Hellmana o długości 3072 bitów za pomocą OpenSSL: openssl dhparam -out dhparam3072.pem 3072.
9. Zbadanie ustandaryzowanych bezpiecznych grup Diffie-Hellmana zdefiniowanych w RFC 7919 (ffdhe3072, ffdhe4096).
10. Konfiguracja serwera WWW Apache/Nginx z wymuszeniem algorytmów wymiany kluczy z PFS (wyłącznie ECDHE i DHE).
11. Przetestowanie konfiguracji serwera narzędziem testssl.sh -f target.local (weryfikacja statusu: Perfect Forward Secrecy: Supported).
12. Inspekcja pakietu TLS ServerKeyExchange w programie Wireshark: odczytanie parametrów efemerycznej krzywej eliptycznej (Named Curve: x25519) i podpisu cyfrowego.
13. Konfiguracja algorytmów wymiany kluczy w demonie OpenSSH: KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512.
14. Zbadanie wpływu PFS na możliwość deszyfrowania ruchu sieciowego w systemach IDS (dlaczego IDS musi działać jako endpoint lub deszyfrować w locie).
15. Opracowanie procedury audytu zgodności z zaleceniami KNF w zakresie Forward Secrecy.
16. Przygotowanie sprawozdania laboratoryjnego z wyprowadzeniami matematycznymi i analizą zrzutów z Wiresharka.

Różnica pomiędzy statycznym RSA a efemerycznym Diffie-Hellmanem (DHE/ECDHE) jest fundamentalna dla bezpieczeństwa państwa i biznesu. W statycznym RSA ten sam klucz asymetryczny służy zarówno do uwierzytelnienia serwera, jak i do zaszyfrowania klucza sesyjnego. W DHE/ECDHE klucz asymetryczny serwera służy WYŁĄCZNIE do złożenia podpisu cyfrowego pod efemerycznymi parametrami DH wygenerowanymi na ułamek sekundy dla tej jednej sesji. Po zakończeniu połączenia liczby te są bezpowrotnie usuwane z pamięci RAM, co oznacza, że żaden podmiot na świecie nie będzie w stanie odszyfrować zapisanego ruchu, nawet posiadając klucz prywatny serwera.

Poniżej przedstawiono matematyczną symulację protokołu Diffie-Hellmana i generowanie parametrów RFC 7919 w OpenSSL:

Weryfikacja obsługi Perfect Forward Secrecy na serwerze za pomocą narzędzia testssl.sh:

Demonstracja wymiany kluczy Diffie-Hellmana w języku Python z weryfikacją identyczności sekretu:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Zasada działania protokołu Diffie-Hellmana: problem logarytmu dyskretnego w ciele skończonym (DHE) oraz na krzywej eliptycznej (ECDHE).
2. Własność doskonałego utajniania w przód (Perfect Forward Secrecy) i ochrona zarejestrowanego ruchu sieciowego przed deszyfracją po kompromitacji klucza głównego.
3. Podatność surowego protokołu Diffie-Hellmana na atak człowieka pośrodku (Man-in-the-Middle) wynikająca z braku wbudowanego uwierzytelnienia stron.
4. Integracja protokołu ECDHE z cyfrowymi podpisami asymetrycznymi w celu stworzenia bezpiecznej, uwierzytelnionej wymiany kluczy w TLS.
5. Analiza podatności słabych grup DH: atak Logjam (CVE-2015-4000) na parametry 512/1024-bitowe oraz wymóg stosowania bezpiecznych grup RFC 7919.
6. Wykorzystanie ulotnych kluczy sesyjnych (Ephemeral Keys) a optymalizacja zarządzania zasobami procesora serwera przy masowej liczbie połączeń.

Przykładowe wnioski (wzór do sprawozdania): Eksperymentalna symulacja pasywnego podsłuchu i późniejszej kryptoanalizy potwierdziła fundamentalne znaczenie własności doskonałego utajniania w przód zapewnianej przez warianty efemeryczne DHE i ECDHE. W przeciwieństwie do przestarzałej wymiany kluczy opartej na statycznym RSA, skompromitowanie długoterminowego klucza prywatnego serwera nie pozwala na odszyfrowanie wcześniej zarejestrowanych sesji komunikacyjnych. Demonstracja ataku Man-in-the-Middle na surowy protokół Diffie-Hellmana dowiodła jednak, że uzgadnianie klucza bez kryptograficznego podpisu tożsamości stron jest całkowicie bezbronne wobec aktywnego przechwycenia. Wdrożenie protokołu ECDHE z krzywą X25519 połączonego z uwierzytelnieniem certyfikatem X.509 wyeliminowało zarówno podatność na podsłuch, jak i ryzyko manipulacji parametrami DH. Otrzymana architektura gwarantuje maksymalny poziom bezpieczeństwa transmisji przy znikomym narzucie na proces negocjacji sesji.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia asymetryczna. Standard OpenPGP, sieć zaufania Web of Trust i szyfrowanie end-to-end.

Celem zadania jest zaprojektowanie, wdrożenie i przetestowanie zdecentralizowanej infrastruktury bezpiecznej wymiany korespondencji i plików opartej na otwartym standardzie OpenPGP (RFC 4880 / RFC 9580) przy użyciu oprogramowania GnuPG (GNU Privacy Guard). Studenci badają zasady szyfrowania od końca do końca (End-to-End Encryption - E2EE), asymetrycznego podpisywania wiadomości, zarządzania podkluczami (Subkeys: certyfikacja [C], podpisywanie [S], szyfrowanie [E], uwierzytelnianie [A]) oraz konstruowania certyfikatów unieważnienia (Revocation Certificates).

W części analitycznej studenci poznają model sieci zaufania (Web of Trust - WoT) w zestawieniu ze zhierarchizowaną strukturą urzędów certyfikacji X.509 PKI. W części praktycznej tworzą klucze główne przechowywane offline, generują podklucze operacyjne, publikują klucze na zaufanych serwerach kluczy (Keyservers z weryfikacją Hagrid / WKD - Web Key Directory) oraz konfigurują integrację z klientem pocztowym Thunderbird z modułem Enigmail/OpenPGP.

Wydawnictwo Prasowe i Kancelaria Adwokacka 'Lex & Iustitia' reprezentuje sygnalistów, dziennikarzy śledczych oraz świadków koronnych w głośnych sprawach korupcyjnych. Pomiędzy adwokatami a klientami przesyłane są pliki zawierające dowody przestępstw, wyciągi z kont bankowych oraz nagrania audio. Przesyłanie tych materiałów standardową pocztą elektroniczną lub popularnymi komunikatorami stwarza ryzyko ich przechwycenia na serwerach operatorów pocztowych (brak szyfrowania end-to-end).

Podczas audytu bezpieczeństwa wykazano, że prawnicy nie potrafili poprawnie zweryfikować tożsamości kluczy publicznych swoich korespondentów, co doprowadziło do incydentu, w którym adwokat przesłał poufne materiały śledcze, szyfrując je fałszywym kluczem PGP podstawionym przez napastnika na publicznym serwerze kluczy (atak podszycia się pod tożsamość / MitM).

Dodatkowo pracownicy przechowywali swoje główne klucze prywatne na laptopach służbowych bez haseł frazowych i bez wygenerowanych certyfikatów unieważnienia, co w przypadku zgubienia komputera uniemożliwiało poinformowanie świata o kompromitacji klucza.

Dziekan izby adwokackiej zobowiązał kancelarię do wdrożenia rygorystycznego Standardu Bezpieczeństwa Korespondencji Prawnej opartego na GnuPG.

Grupa laboratoryjna przyjmuje zadanie wdrożenia infrastruktury OpenPGP: zaprojektowanie hierarchii klucza głównego i podkluczy, wygenerowanie certyfikatów unieważnienia, opublikowanie kluczy w protokole WKD (Web Key Directory), przeprowadzenie ceremonii podpisywania kluczy (Key Signing Party) budującej sieć zaufania (Web of Trust) oraz przetestowanie szyfrowania i podpisywania korespondencji.

• Oprogramowanie GnuPG (gpg) v2.2+ w środowisku Linux / Windows (Gpg4win)
• Klient poczty elektronicznej Mozilla Thunderbird z wbudowaną obsługą OpenPGP
• Menedżer kluczy Kleopatra (darmowe GUI dla GnuPG)
• Narzędzie paperkey do drukowania papierowych kopii zapasowych kluczy prywatnych
• Serwery kluczy keys.openpgp.org / keyserver.ubuntu.com

1. Zbadanie założeń standardu OpenPGP: model hybrydowy (szyfrowanie wiadomości kluczem symetrycznym AES-256, szyfrowanie klucza symetrycznego kluczem publicznym RSA/Ed25519).
2. Analiza architektury klucza GnuPG: klucz główny (Master Key [C]) oraz wyspecjalizowane podklucze (Subkeys [S], [E], [A]).
3. Wygenerowanie bezpiecznej pary kluczy z długością 3072/4096 bitów lub na krzywych eliptycznych Ed25519/Cv25519: gpg --full-generate-key.
4. Wprowadzenie rygorystycznego hasła frazowego (Passphrase) chroniącego klucz prywatny.
5. Natychmiastowe wygenerowanie certyfikatu unieważnienia (Revocation Certificate): gpg --output revoke.asc --gen-revoke <KeyID>.
6. Zabezpieczenie certyfikatu unieważnienia i klucza głównego w bezpiecznym sejfie offline.
7. Wygenerowanie dedykowanego podklucza do podpisywania [S] i podklucza do szyfrowania [E]: gpg --edit-key <KeyID> -> addkey.
8. Zbadanie 40-znakowego odcisku palca klucza (Fingerprint) za pomocą polecenia gpg --fingerprint.
9. Eksport klucza publicznego w formacie ASCII-Armor: gpg --armor --export <KeyID> > public.asc.
10. Symulacja ceremonii podpisywania kluczy (Key Signing Party): bezpośrednia weryfikacja tożsamości i odcisku palca pomiędzy dwoma studentami.
11. Złożenie podpisu zaufania na kluczu partnera: gpg --sign-key <PartnerKeyID> i określenie poziomu zaufania (Trust Level w Web of Trust).
12. Zaszyfrowanie i podpisanie pliku dokumentu prawnego: gpg --armor --sign --encrypt --recipient <PartnerEmail> umowa.pdf.
13. Weryfikacja i odszyfrowanie wiadomości przez odbiorcę: gpg --decrypt umowa.pdf.asc.
14. Zbadanie komunikatu weryfikacji podpisu: potwierdzenie integralności i tożsamości nadawcy (Good signature from...).
15. Skonfigurowanie klienta Mozilla Thunderbird do automatycznego podpisywania i szyfrowania korespondencji e-mail.
16. Zbadanie mechanizmu Web Key Directory (WKD) umożliwiającego bezpieczne pobieranie kluczy z domeny nadawcy bez podatności serwerów SKS.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z analizą odcisków palców i zrzutami ekranu.

W profesjonalnych wdrożeniach OpenPGP klucz główny (Master Key) służy wyłącznie do certyfikacji innych kluczy (funkcja [C] - Certify) i powinien być po wygenerowaniu podkluczy usunięty ze stacji roboczej i zarchiwizowany na zaszyfrowanym nośniku offline (lub wydrukowany za pomocą narzędzia paperkey). Do codziennej pracy na laptopie importuje się wyłącznie podklucze: do podpisywania ([S] - Sign) oraz do szyfrowania ([E] - Encrypt). W przypadku kradzieży laptopa unieważnia się wyłącznie podklucze, a tożsamość główna i zaufanie w sieci Web of Trust pozostają nienaruszone!

Poniżej przedstawiono procedurę generowania klucza, podkluczy i certyfikatu unieważnienia w GnuPG:

Weryfikacja odcisków palców (Fingerprint) oraz podkluczy za pomocą polecenia gpg:

Szyfrowanie i jednoczesne podpisywanie dokumentu cyfrowego dla klienta kancelarii:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Architektura OpenPGP (RFC 4880 i RFC 9580): separacja klucza głównego (Certyfikacja) od dedykowanych podkluczy roboczych (Szyfrowanie, Podpis, Uwierzytelnianie).
2. Model sieci zaufania (Web of Trust – WoT) jako zdecentralizowana alternatywa dla hierarchicznej infrastruktury klucza publicznego X.509 PKI.
3. Procedury bezpiecznego podpisywania kluczy publicznych (Keysigning Parties), poziomy zaufania (Trust Levels) oraz obliczanie ważności klucza w GnuPG.
4. Wymóg prewencyjnego wygenerowania certyfikatu unieważnienia (Revocation Certificate) i procedury postępowania w przypadku utraty kontroli nad kluczem.
5. Bezpieczne przechowywanie klucza certyfikującego w trybie offline i operowanie na stacjach roboczych wyłącznie dedykowanymi podkluczami.
6. Dystrybucja kluczy publicznych za pośrednictwem współczesnych serwerów weryfikujących oraz federacyjnego standardu WKD (Web Key Directory).

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie i wdrożenie korporacyjnej infrastruktury OpenPGP wykazało, że kluczem do długoterminowego bezpieczeństwa tożsamości jest bezwzględna separacja klucza certyfikującego od podkluczy roboczych. Umieszczenie głównego klucza prywatnego w bezpiecznym magazynie offline chroni tożsamość użytkownika przed kompromitacją w przypadku infekcji codziennej stacji roboczej. Przeprowadzona symulacja unieważnienia skompromitowanego podklucza szyfrującego za pomocą wcześniej przygotowanego certyfikatu unieważnienia potwierdziła natychmiastowe odcięcie możliwości nadsyłania zaszyfrowanej korespondencji. Model sieci zaufania efektywnie zweryfikował autentyczność kluczy współpracowników w zespole projektowym bez konieczności polegania na komercyjnych urzędach certyfikacji. Wdrożenie standardu Web Key Directory na serwerze domenowym zautomatyzowało dystrybucję kluczy publicznych pracowników i zabezpieczyło proces przed fałszowaniem tożsamości w publicznych bazach keyserverów.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia symetryczna i asymetryczna. Modele szyfrowania hybrydowego (KEM/DEM).

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie bezpiecznego, modularnego potoku kryptograficznego realizującego szyfrowanie hybrydowe (Hybrid Encryption Scheme) w modelu KEM/DEM (Key Encapsulation Mechanism / Data Encapsulation Mechanism). Studenci badają zasady łączenia zalet kryptografii asymetrycznej (wygodna wymiana kluczy bez współdzielonego sekretu) z zaletami kryptografii symetrycznej (ogromna wydajność i możliwość szyfrowania gigabajtowych strumieni danych).

Projekt obejmuje implementację potoku przetwarzania danych: wygenerowanie jednorazowego symetrycznego klucza sesyjnego (AES-256-GCM), zaszyfrowanie właściwego pliku danych wraz z metadanymi, opakowanie (enkapsulację) klucza sesyjnego za pomocą klucza publicznego odbiorcy (RSA-OAEP z SHA-256 lub ECIES na krzywej Curve25519) oraz sformatowanie bezpiecznego kontenera kryptograficznego (wzorowanego na standardzie CMS / PKCS#7 / OpenPGP) z integralnością uwierzytelnioną.

Centralny Ośrodek Informatyki Archiwalnej 'Kronika' przetwarza i archiwizuje wielogigabajtowe zbiory zdigitalizowanych dokumentów historycznych, rejestrów państwowych oraz ksiąg wieczystych. Zbiory te muszą być okresowo przesyłane przez publiczne sieci WAN do zapasowego repozytorium w bunkrze danych.

Wstępna koncepcja zakładała użycie algorytmu asymetrycznego RSA do bezpośredniego szyfrowania całych plików archiwów (pliki tar.gz o rozmiarze od 10 GB do 500 GB). Próba ta zakończyła się katastrofą techniczną: algorytm RSA z definicji nie pozwala na szyfrowanie danych dłuższych niż rozmiar modułu minus dopełnienie (dla RSA 2048 to zaledwie 214 bajtów przy dopełnieniu OAEP), a dzielenie wielogigabajtowego pliku na 200-bajtowe kawałki i szyfrowanie każdego z nich z osobna trwało dziesiątki godzin i powodowało gigantyczny narzut pamięciowy.

Z kolei zastosowanie samego szyfrowania symetrycznego AES-256 rodziło problem bezpiecznego dostarczenia klucza do oddalonego bunkra bez ryzyka jego przechwycenia w drodze.

Dyrektor archiwum zlecił zespołowi inżynierów (grupie laboratoryjnej) zaprojektowanie i zaimplementowanie profesjonalnego mechanizmu szyfrowania hybrydowego w architekturze KEM/DEM.

Zadaniem studentów jest stworzenie zautomatyzowanego skryptu (w Bashu z OpenSSL lub w Pythonie), który dla każdego archiwum generuje losowy klucz AES-256 i unikalny wektor IV (DEM), szyfruje wielogigabajtowy plik strumieniowo w trybie AES-GCM z obliczeniem tagu autoryzacji, szyfruje klucz sesyjny kluczem publicznym RSA-OAEP/ECIES odbiorcy (KEM) i pakuje całość do spójnego pliku kontenera binarnego (.secpack).

• Narzędzie OpenSSL 3.x CLI
• Python 3 z zaawansowaną biblioteką cryptography (moduły hazmat primitives)
• Narzędzie tar i gzip do przygotowywania paczek danych
• Narzędzie hexdump / xxd do analizy nagłówka kontenera kryptograficznego
• Narzędzie sha256sum do weryfikacji integralności danych po odszyfrowaniu

1. Zrozumienie podziału ról w szyfrowaniu hybrydowym: KEM (mechanizm enkapsulacji klucza) oraz DEM (mechanizm enkapsulacji danych).
2. Analiza matematycznych ograniczeń RSA: dlaczego algorytm asymetryczny może szyfrować wyłącznie bloki o rozmiarze mniejszym niż moduł n.
3. Zbadanie standardu dopełnienia RSA-OAEP (Optimal Asymmetric Encryption Padding) z funkcją skrótu SHA-256.
4. Wygenerowanie 3072-bitowej asymetrycznej pary kluczy odbiorcy (bunkier danych): bunkier_priv.pem i bunkier_pub.pem.
5. Zaimplementowanie procedury KEM: wygenerowanie losowego, jednorazowego klucza symetrycznego AES-256 (32 bajty) za pomocą generatora kryptograficznego.
6. Zaszyfrowanie wygenerowanego klucza symetrycznego kluczem publicznym odbiorcy: openssl pkeyutl -encrypt -pubin -inkey bunkier_pub.pem -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -in sesyjny.key -out sesyjny.key.enc.
7. Zaimplementowanie procedury DEM: strumieniowe zaszyfrowanie wielkiego pliku archiwum za pomocą AES-256-GCM z wygenerowaniem losowego wektora IV (12 bajtów) i tagu autoryzacji (16 bajtów).
8. Zaprojektowanie struktury nagłówka binarnego kontenera hybrydowego: [Magiczne Bajty 'SECP'] [Rozmiar KEM] [Zaszyfrowany Klucz KEM] [IV 12B] [Tag 16B] [Szyfrogram DEM].
9. Złożenie gotowego kontenera archiwum za pomocą skryptu i weryfikacja jego struktury narzędziem hexdump.
10. Zaimplementowanie procedury odwrotnej (deszyfrowanie): odczyt nagłówka, odszyfrowanie klucza sesyjnego kluczem prywatnym bunkra (KEM Decapsulation).
11. Odszyfrowanie właściwego strumienia danych za pomocą odzyskanego klucza sesyjnego i weryfikacja tagu integralności GCM.
12. Zademonstrowanie odporności potoku na modyfikację danych w locie (wykrycie naruszenia integralności przez tag GCM).
13. Przeprowadzenie testu wydajnościowego: pomiar czasu szyfrowania pliku 1 GB w modelu hybrydowym w porównaniu do hipotetycznego RSA.
14. Opracowanie implementacji alternatywnej opartej na krzywych eliptycznych ECIES (Elliptic Curve Integrated Encryption Scheme z X25519 i HKDF).
15. Wdrożenie automatycznego usuwania plików tymczasowych zawierających nieszyfrowany klucz sesyjny z pamięci RAM (Zeroization).
16. Sformułowanie instrukcji stanowiskowej dla operatorów archiwum.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z pełnymi kodami skryptów i diagramem przepływu danych.

W modelu szyfrowania hybrydowym klucz symetryczny musi być wygenerowany całkowicie na nowo (losowo) dla każdego szyfrowanego pliku i nigdy nie może być użyty powtórnie. Zapewnia to pełną izolację kryptograficzną: nawet gdyby napastnikowi udało się w jakiś sposób poznać klucz sesyjny jednego pliku, nie daje mu to żadnej możliwości odszyfrowania jakichkolwiek innych plików w archiwum.

Poniżej przedstawiono kompletny skrypt Bash/OpenSSL realizujący model szyfrowania hybrydowego KEM/DEM (RSA-OAEP + AES-256-GCM):

Wykonanie szyfrowania wielkiego pliku bazy danych za pomocą skryptu hybrydowego:

Odszyfrowanie pakietu w bunkrze danych za pomocą asymetrycznego klucza prywatnego bunkra:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Zasada działania szyfrowania hybrydowego: dekompozycja na mechanizm hermetyzacji klucza (KEM) oraz mechanizm enkapsulacji danych (DEM).
2. Rozwiązanie problemu wydajności kryptografii asymetrycznej i ograniczenia rozmiaru wiadomości poprzez szyfrowanie danych symetrycznym szyfrem AES-256-GCM.
3. Zastosowanie bezpiecznego schematu RSA-OAEP lub ECIES w celu ochrony jednorazowego klucza symetrycznego (Data Encryption Key – DEK).
4. Zapewnienie kryptograficznej integralności i autentyczności szyfrogramu poprzez weryfikację nagłówków oraz tagu AEAD przed odzyskaniem tekstu jawnego.
5. Wymogi dotyczące generowania jednorazowego klucza sesyjnego za pomocą kryptograficznie bezpiecznego generatora liczb pseudolosowych (CSPRNG).
6. Analiza odporności potoku hybrydowego na ataki typu wybranej wiadomości zaszyfrowanej (IND-CCA2) oraz manipulacje metadanymi pliku.

Przykładowe wnioski (wzór do sprawozdania): Implementacja modularnego potoku szyfrowania hybrydowego KEM/DEM pozwoliła na skuteczne połączenie wygody asymetrycznej dystrybucji kluczy z gigantyczną przepustowością symetrycznego szyfru AES-256-GCM. Zastosowanie schematu RSA-OAEP z funkcją skrótu SHA-256 do zabezpieczenia jednorazowego klucza sesyjnego całkowicie wyeliminowało ryzyko ataków wyroczni dopełnienia typowych dla PKCS#1 v1.5. Przesyłanie wielogigabajtowych archiwów danych odbywa się w warstwie DEM z pełną prędkością interfejsu dyskowego, zapewniając jednoczesną weryfikację integralności za pomocą 128-bitowego tagu uwierzytelniającego GCM. Dołączenie identyfikatora klucza publicznego i metadanych do sekcji danych powiązanych AAD zabezpieczyło pakiet przed próbami podstawienia kontekstu transmisji. Opracowana architektura gwarantuje najwyższy poziom bezpieczeństwa semantycznego IND-CCA2 i stanowi fundament nowoczesnych protokołów bezpiecznej archiwizacji danych.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Zarządzanie kluczami kryptograficznymi. Sprzętowe moduły bezpieczeństwa TPM i HSM.

Celem zadania jest zbadanie najsłabszego ogniwa systemów kryptograficznych – problemu bezpiecznego przechowywania kluczy prywatnych (Key Storage Security) – oraz zaprojektowanie wielowarstwowej polityki ochrony kluczy w instytucji zaufania publicznego. Studenci poznają wektory kompromitacji kluczy prywatnych: ekstrakcję z niechronionych plików na dysku, wycieki z pamięci operacyjnej RAM (Memory Dumping / Cold Boot Attack), brak szyfrowania kluczy w spoczynku oraz złośliwe oprogramowanie kradnące tożsamość cyfrową.

W części praktycznej studenci konfigurują potrójną linię ochrony kluczy: 1) Warstwa programowa: silne szyfrowanie kluczy prywatnych hasłami frazowymi przy użyciu pamięciożernych funkcji derywacji klucza (KDF: Argon2id, PBKDF2 z min. 600 000 iteracji), 2) Warstwa uprawnień systemu operacyjnego: restrykcyjne prawa dostępu (chmod 0400, ACL, chattr +i), 3) Warstwa sprzętowa: zapieczętowanie klucza w układzie TPM 2.0 (Trusted Platform Module) z wykorzystaniem mechanizmu tpm2-tss / OpenSSL TPM2 Engine, uniemożliwiające wyciągnięcie klucza prywatnego poza procesor kryptograficzny.

Centrum Usług Zaufania 'e-Podpis Polska' świadczy usługi kwalifikowanego podpisu elektronicznego oraz wydawania znaczników czasu dla administracji publicznej i sądów. Klucz prywatny urzędu certyfikacji (Sub-CA) służący do podpisywania certyfikatów SSL dla stron rządowych .gov.pl był przechowywany na serwerze Linux w pliku /etc/ssl/private/subca.key.

W trakcie audytu bezpieczeństwa okazało się, że plik klucza prywatnego nie posiadał żadnego hasła zabezpieczającego (tzw. unencrypted private key), a uprawnienia do pliku wynosiły chmod 0644 (odczyt dla wszystkich użytkowników systemu). Każdy lokalny proces, aplikacja webowa czy stażysta posiadający konto w systemie mógł bez przeszkód skopiować klucz prywatny urzędu.

Co gorsza, kopia zapasowa tego katalogu trafiła na otwarty serwer developerski, co w sytuacji wykrycia przez obce wywiady mogło doprowadzić do masowego fałszowania certyfikatów rządowych i podsłuchiwania całej komunikacji obywateli z e-administracją (atak Man-in-the-Middle na poziomie krajowym).

Ministerstwo Cyfryzacji nakazało natychmiastowe unieważnienie kompromitującego certyfikatu i wdrożenie bezwzględnych standardów ochrony kluczy kryptograficznych zgodnych z wymogami eIDAS oraz normą FIPS 140-3 Level 2/3.

Zadaniem grupy laboratoryjnej jest skonstruowanie Polityki Zarządzania Kluczami Kryptograficznymi, wdrożenie procedury zabezpieczania kluczy prywatnych silną frazą hasłową z algorytmem Argon2id/PBKDF2, skonfigurowanie restrykcyjnych uprawnień systemowych oraz przetestowanie sprzętowej integracji klucza z modułem TPM 2.0 (gdzie klucz prywatny nigdy nie opuszcza układu krzemowego, a operacje podpisywania wykonuje koprocesor TPM).

• OpenSSL 3.x z silnikiem tpm2-openssl / libtss2-engine
• Pakiet narzędziowy tpm2-tools w systemie Linux
• Emulator modułu TPM 2.0 (swtpm) w środowisku testowym
• Narzędzie gpg / pass / KeePassXC do zarządzania hasłami frazowymi
• Narzędzie auditd do monitorowania prób nieautoryzowanego dostępu do plików kluczy

1. Analiza wektorów ataków na klucze prywatne (kradzież pliku, wyciek z pamięci RAM, ataki na KDF, zrzuty z kopii zapasowych).
2. Zbadanie różnic pomiędzy kluczem niezaszyfrowanym (Traditional OpenSSL RSA Private Key) a kluczem chronionym standardem PKCS#8.
3. Przekształcenie niezaszyfrowanego klucza prywatnego w bezpieczny format PKCS#8 z szyfrowaniem AES-256-CBC i PBKDF2 (min. 600 000 iteracji): openssl pkcs8 -topk8 -v2 aes256 -v2prf hmacWithSHA256 -iter 600000 -in key.pem -out secure_key.pem.
4. Przetestowanie algorytmu Argon2id do zabezpieczenia klucza za pomocą narzędzia GnuPG/cryptsetup.
5. Ustawienie restrykcyjnych uprawnień systemu plików w Linux: chmod 0400 secure_key.pem oraz chown root:root secure_key.pem.
6. Konfiguracja monitorowania dostępu do pliku klucza za pomocą reguły auditd (-w /etc/ssl/private/secure_key.pem -p rwa -k key_access).
7. Zbadanie architektury układu TPM 2.0: hierarchia Storage, klucz główny SRK (Storage Root Key), rejestry PCR.
8. Uruchomienie emulatora swtpm lub połączenie z fizycznym modułem TPM na stacji roboczej.
9. Utworzenie pierwotnego klucza w hierarchii właściciela TPM: tpm2_createprimary -C o -g sha256 -G rsa -c primary.ctx.
10. Wygenerowanie asymetrycznej pary kluczy wewnątrz układu TPM 2.0: tpm2_create -C primary.ctx -g sha256 -G rsa -r key.priv -u key.pub.
11. Zapieczętowanie klucza z powiązaniem do rejestrów PCR 0 i 7 (Platform Integrity Sealing).
12. Załadowanie klucza do TPM i utworzenie pliku uchwytu dla OpenSSL (tpm2-openssl provider).
13. Wykonanie podpisu cyfrowego dokumentu za pomocą klucza zapieczętowanego w TPM: openssl dgst -sha256 -sign handle:0x81010001 -out doc.sig doc.txt.
14. Wykazanie, że plik klucza prywatnego w ogóle nie istnieje w pamięci RAM systemu gospodarza ani na dysku (klucz jest niewyciągalny sprzętowo).
15. Zaprojektowanie procedury awaryjnego odzyskiwania klucza (Key Backup & Escrow) z podziałem sekretu algorytmem Shamira (Shamir's Secret Sharing m-z-n).
16. Opracowanie procedury bezpiecznego niszczenia klucza (Crypto-Shredding) po wygaśnięciu certyfikatu.
17. Skompilowanie raportu laboratoryjnego z opisem konfiguracji TPM i procedurami bezpieczeństwa.

Prawdziwe bezpieczeństwo kluczy kryptograficznych najwyższej wagi (Root CA, certyfikaty produkcyjne) osiąga się tylko wtedy, gdy klucz prywatny jest kryptograficznie niewyciągalny (non-exportable). Oznacza to, że klucz jest generowany wewnątrz bezpiecznego układu sprzętowego (TPM lub HSM) i nigdy, pod żadnym pozorem, nie jest przesyłany na magistralę ani do pamięci operacyjnej komputera. Komputer przesyła do TPM jedynie skrót wiadomości, a układ TPM wewnątrz swojego krzemu składa podpis i zwraca gotową sygnaturę.

Poniżej przedstawiono procedurę bezpiecznej konwersji klucza prywatnego do utwardzonego formatu PKCS#8 z 600 000 iteracji PBKDF2 w OpenSSL:

Konfiguracja reguły demona auditd monitorującej każdą próbę odczytu klucza prywatnego:

Generowanie sprzętowego klucza asymetrycznego wewnątrz modułu TPM 2.0 za pomocą tpm2-tools:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza wektorów kompromitacji kluczy prywatnych przechowywanych na dyskach serwerów (zrzuty pamięci, nieuprawnione uprawnienia plików, kopie zapasowe, luki RCE).
2. Zastosowanie pamięciożernych funkcji derywacji klucza (Argon2id, PBKDF2 z wysoką liczbą iteracji) do szyfrowania kluczy prywatnych hasłem frazowym.
3. Koncepcja szyfrowania kopertowego (Envelope Encryption): hierarchia kluczy nadrzędnych (KEK) oraz lokalnych kluczy danych (DEK).
4. Sprzętowa izolacja kluczy kryptograficznych: rola modułów TPM 2.0, kart inteligentnych oraz sieciowych modułów HSM spełniających normy FIPS 140-2/3.
5. Konfiguracja restrykcyjnych uprawnień systemowych w systemie operacyjnym uniemożliwiających odczyt kluczy przez nieuprawnione procesy i demony.
6. Wytyczne normy ISO/IEC 27001 oraz rekomendacji NIST SP 800-57 w zakresie pełnego cyklu życia kluczy kryptograficznych.

Przykładowe wnioski (wzór do sprawozdania): Audyt procedur przechowywania kluczy prywatnych wykazał, że pozostawienie niezaszyfrowanych plików PEM na systemie plików serwera stwarza natychmiastowe ryzyko kradzieży tożsamości w razie podatności aplikacyjnej. Zaimplementowanie szyfrowania klucza prywatnego algorytmem AES-256-CBC z derywacją hasła frazowego za pomocą PBKDF2 z milionem iteracji skutecznie uniemożliwiło natychmiastowe złamanie pliku w przypadku jego wycieku. Integracja środowiska z kryptoprocesorem TPM 2.0 pozwoliła na powiązanie klucza z rejestrami PCR maszyny, co uniemożliwia jego użycie na innym serwerze lub po nieautoryzowanej modyfikacji jądra systemu. Zastosowanie zasady szyfrowania kopertowego umożliwiło bezpieczną rotację kluczy głównych KEK bez konieczności ponownego szyfrowania terabajtów danych produkcyjnych. Przeprowadzone wdrożenie spełnia najwyższe rygory bezpieczeństwa fizycznego i logicznego określone w normie ISO/IEC 27001 oraz standardzie PCI DSS.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Algorytmy kryptograficzne symetryczne i asymetryczne. Akceleracja sprzętowa i wydajność.

Celem zadania jest przeprowadzenie wszechstronnych, rygorystycznych testów wydajnościowych (Benchmarking) operacji kryptograficznych w systemie operacyjnym Linux przy użyciu wbudowanego podsystemu diagnostycznego OpenSSL speed. Studenci analizują wpływ dedykowanych instrukcji sprzętowych procesora (Intel/AMD AES-NI, CLMUL, ARMv8 Cryptography Extensions) na przepustowość algorytmów symetrycznych (AES-128/256 w trybach CBC, CTR, GCM, ChaCha20-Poly1305) oraz funkcji skrótu (SHA-256, SHA-512, SHA-3) i algorytmów asymetrycznych (RSA, ECDSA, Ed25519).

W ramach laboratorium studenci badają zjawisko narzutu kryptograficznego (Cryptographic Overhead) na serwerach o wysokim natężeniu ruchu (High-Traffic Web Servers / VPN Gateways), przeprowadzają testy porównawcze z włączoną i programowo wyłączoną akceleracją AES-NI (zmienna środowiskowa OPENSSL_ia32cap), analizują optymalizację doboru szyfrów pod kątem architektury klienta (np. ChaCha20 dla smartfonów bez sprzętowego AES) oraz formułują wytyczne wydajnościowe dla klastrów chmurowych.

Operator telekomunikacyjny NetFiber Polska S.A. wdraża centralny węzeł koncentratora tuneli IPsec / WireGuard obsługujący ponad 50 000 równoległych połączeń światłowodowych od klientów korporacyjnych o łącznej przepustowości 40 Gb/s. Węzeł został uruchomiony na klastrze serwerów z wielordzeniowymi procesorami x86_64.

W trakcie pierwszych testów obciążeniowych zaobserwowano niespodziewane dławienie przepustowości: procesory osiągały 100% utylizacji już przy natężeniu ruchu 6 Gb/s, a opóźnienia pakietów (latency) wzrosły z 2 ms do 180 ms. Analiza wykazała, że w konfiguracji jądra Linux oraz biblioteki OpenSSL wyłączone zostało wsparcie dla instrukcji AES-NI, w związku z czym serwery realizowały szyfrowanie AES czysto programowo, zużywając setki cykli procesora na każdy zaszyfrowany bajt danych.

Dodatkowo dla urządzeń mobilnych (smartfony kurierów i serwisantów polowych z tańszymi procesorami ARM Cortex bez sprzętowego wsparcia AES) wymuszono ten sam szyfr AES-256, co powodowało błyskawiczne nagrzewanie się urządzeń i spadek wydajności baterii.

Dyrektor Działu Sieci nakazał natychmiastowe przeprowadzenie pełnego audytu wydajnościowego podsystemu kryptograficznego, zbadanie wpływu instrukcji AES-NI oraz wdrożenie bezpiecznej rekonfiguracji negocjacji szyfrów.

Grupa laboratoryjna przyjmuje zadanie inżynierów wydajności. Studenci muszą przeprowadzić serię benchmarków openssl speed dla różnych rozmiarów bloków (od 16 bajtów do 8192 bajtów), zbadać wpływ flagi OPENSSL_ia32cap wyłączającej akcelerację sprzętową, porównać wydajność AES-GCM z ChaCha20-Poly1305 oraz opracować reguły doboru szyfrów w zależności od architektury procesora.

• Narzędzie OpenSSL 3.x z modułem speed
• Narzędzie lscpu / cat /proc/cpuinfo do weryfikacji flag procesora (aes, pclmulqdq, avx2)
• Python 3 z bibliotekami matplotlib / pandas do generowania wykresów benchmarkowych
• Narzędzie perf / htop do profilowania obciążenia rdzeni procesora podczas szyfrowania
• Środowisko Linux x86_64 oraz emulacja ARM (QEMU / Raspberry Pi) do testów międzyplatformowych

1. Weryfikacja obecności instrukcji akceleracji sprzętowej w procesorze za pomocą lscpu | grep -E 'aes|sse|avx'.
2. Zrozumienie działania zestawu instrukcji AES-NI: AESENC, AESENCLAST, AESDEC, AESDECLAST, AESKEYGENASSIST.
3. Przeprowadzenie pełnego testu bazowego algorytmów symetrycznych za pomocą OpenSSL: openssl speed -evp aes-128-gcm aes-256-gcm chacha20-poly1305.
4. Analiza wyników przepustowości (MB/s) dla bloków danych o rozmiarach: 16, 64, 256, 1024, 8192 bajtów.
5. Wymuszenie wyłączenia akceleracji AES-NI za pomocą zmiennej środowiskowej: OPENSSL_ia32cap="~0x200000200000000".
6. Powtórzenie testu wydajnościowego w trybie czysto programowym (Software Fallback).
7. Wyliczenie współczynnika przyspieszenia sprzętowego (Speedup Ratio = Przepustowość_HW / Przepustowość_SW).
8. Zbadanie wydajności algorytmu ChaCha20-Poly1305 w trybie sprzętowym i programowym (wykazanie, że ChaCha20 jest wielokrotnie szybszy od programowego AES na procesorach bez AES-NI).
9. Przeprowadzenie testu wielowątkowego (Multithreaded Benchmark): openssl speed -multi $(nproc) -evp aes-256-gcm.
10. Analiza skalowalności kryptografii symetrycznej na wielordzeniowych procesorach współczesnych serwerów.
11. Przeprowadzenie benchmarku asymetrycznego: openssl speed rsa2048 rsa4096 ecdsap256 ed25519.
12. Zbadanie wpływu kryptografii na obciążenie procesora serwera WWW za pomocą narzędzia htop / perf stat.
13. Zaprojektowanie polityki doboru szyfrów w protokole TLS (Cipher Suite Preference): preferowanie AES-GCM dla klientów x86 z AES-NI oraz ChaCha20-Poly1305 dla urządzeń mobilnych (RFC 7905).
14. Konfiguracja dyrektywy ssl_prefer_server_ciphers off w Nginx umożliwiającej klientowi wybór szyfru optymalnego dla jego procesora.
15. Analiza zużycia energii i temperatury procesora podczas ciągłego szyfrowania software vs hardware.
16. Opracowanie rekomendacji doboru procesorów i instancji wirtualnych w chmurze (AWS/Azure/GCP) pod kątem obsługi szyfrowania.
17. Podsumowanie testów w sprawozdaniu laboratoryjnym z wykresami przepustowości i interpretacją inżynierską.

Zmienna środowiskowa `OPENSSL_ia32cap` pozwala kontrolować wektory możliwości procesora widziane przez bibliotekę OpenSSL w architekturze x86_64. Ustawienie bitu maskującego pozwala programowo wyłączyć obsługę instrukcji AES-NI bez restartu komputera ani zmian w BIOS. Pozwala to na precyzyjne zmierzenie realnego zysku wydajnościowego oferowanego przez krzemowe akceleratory kryptograficzne.

Poniżej przedstawiono procedurę porównania wydajności AES-256-GCM z aktywną akceleracją AES-NI oraz w trybie emulacji programowej:

Wyłączenie instrukcji AES-NI za pomocą zmiennej OPENSSL_ia32cap i ponowny pomiar wydajności:

Porównanie wydajności algorytmu ChaCha20-Poly1305 w trybie programowym:

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Metodyka rygorystycznego benchmarkingu algorytmów kryptograficznych przy użyciu polecenia openssl speed dla zróżnicowanych rozmiarów bloków danych.
2. Rola i wpływ sprzętowej akceleracji instrukcji AES-NI oraz CLMUL w procesorach x86_64 na przepustowość szyfrowania i obciążenie rdzeni CPU.
3. Porównanie charakterystyk wydajnościowych algorytmów AES-GCM oraz ChaCha20-Poly1305 na platformach bez sprzętowego wsparcia dla AES.
4. Analiza kosztu obliczeniowego operacji asymetrycznych (RSA vs ECDSA vs Ed25519): porównanie przepustowości handshake TLS pod dużym obciążeniem.
5. Wpływ funkcji skrótu (SHA-256, SHA-512, SHA-3, BLAKE2) na wydajność przetwarzania strumieni danych w architekturach 64-bitowych.
6. Dobór zestawów szyfrów w projektowaniu systemów rozproszonych pod kątem optymalizacji zużycia energii oraz minimalizacji opóźnień sieciowych.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzone testy benchmarkingowe za pomocą pakietu OpenSSL wykazały dramatyczny, ponad dziesięciokrotny wzrost wydajności algorytmu AES-GCM po aktywacji sprzętowych instrukcji wektorowych AES-NI i CLMUL na procesorze x86_64. W środowiskach pozbawionych dedykowanych instrukcji kryptograficznych szyfr ChaCha20-Poly1305 okazał się trzykrotnie szybszy od programowej emulacji AES, co czyni go optymalnym wyborem dla urządzeń brzegowych. Zestawienie kosztu operacji asymetrycznych potwierdziło, że weryfikacja podpisów Ed25519 jest nie tylko bezpieczniejsza, ale również drastycznie mniej obciążająca dla CPU niż operacje kluczem RSA-4096. Testy funkcji skrótu wykazały, że 64-bitowy algorytm SHA-512 osiąga zauważalnie wyższą przepustowość niż SHA-256 na nowoczesnych procesorach dzięki lepszemu wykorzystaniu rejestrów procesora. Uzyskane wyniki dostarczają bezcennych danych inżynierskich pozwalających na precyzyjny dobór parametrów kryptograficznych serwera pod kątem maksymalizacji przepustowości przy zerowym kompromisie w dziedzinie bezpieczeństwa.