Poziom: ocena 3.0 - podstawy kryptografii symetrycznej i funkcji skrótu

Zestaw 10 praktycznych zadań laboratoryjnych do wykonania w trakcie zajęć (90–100 minut).
Kierunek: Informatyka, semestr 7, przedmiot: Kryptologia.
Podstawa materiałowa: wykład część 3 (kryptografia symetryczna - nowoczesne algorytmy i funkcje skrótu).

1. 01.Szyfrowanie blokowe DES i Triple DES w konsoli OpenSSL oraz narzędziu CyberChef
2. 02.Weryfikacja podatności wzorca wizualnego w trybie ECB na pliku graficznym BMP
3. 03.Badanie wektora inicjalizacyjnego i dopełnienia PKCS#7 w trybie CBC szyfru AES
4. 04.Przekształcenie szyfru blokowego w strumieniowy w trybie licznika AES-CTR i badanie braku paddingu
5. 05.Nowoczesne szyfrowanie uwierzytelnione AEAD w trybie AES-GCM z danymi stowarzyszonymi
6. 06.Szyfr strumieniowy RC4 – badanie działania generatora PRGA i wycofanie z TLS
7. 07.Nowoczesny szyfr strumieniowy ChaCha20 i konstrukcja AEAD ChaCha20-Poly1305
8. 08.Badanie właściwości funkcji skrótu i pomiar efektu lawinowego dla SHA-256
9. 09.Uwierzytelnianie integralności i pochodzenia wiadomości kodem HMAC-SHA256
10. 10.Bezpieczne haszowanie haseł – podatność prostego SHA-256 a rola soli i KDF PBKDF2

Cel

Celem zadania jest praktyczne przećwiczenie szyfrowania blokowego z wykorzystaniem historycznych standardów DES oraz Triple DES (3DES). Student bada strukturę 64-bitowego bloku danych, narzut dopełnienia PKCS#7 oraz różnice pomiędzy trybami ECB i CBC przy użyciu narzędzia sieciowego CyberChef oraz poleceń narzędzia OpenSSL w emulatorze JSLinux Alpine.

Scenariusz – opis

Zadanie rozpoczynasz od przygotowania dwóch narzędzi laboratoryjnych: serwisu CyberChef oraz wirtualnej konsoli JSLinux z biblioteką OpenSSL. W przeglądarce otwierasz CyberChef pod adresem gchq.github.io/CyberChef, a w sąsiedniej karcie terminal JSLinux Alpine pod adresem bellard.org/jslinux. Pierwszym celem jest zrozumienie, jak szyfry blokowe operują na stałych porcjach danych o długości 64 bitów (8 bajtów). Przygotowujesz krótki tekst testowy o długości dokładnie 8 znaków, na przykład hasło KRYPTO01, oraz tekst o długości 11 znaków, na przykład KRYPTOLOGIA. W serwisie CyberChef konfigurujesz operację DES Encrypt, wybierając tryb ECB oraz zapis klucza w formacie szesnastkowym. Badany klucz DES ma długość 8 bajtów (64 bity), z czego najmniej znaczący bit każdego bajtu stanowi bit parzystości, co daje faktyczną siłę 56 bitów.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz w przeglądarce serwis CyberChef (gchq.github.io/CyberChef).
2. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256).
3. W CyberChef wprowadź tekst jawny KRYPTO01 (8 bajtów) i dodaj operację DES Encrypt w trybie ECB.
4. Ustaw format klucza na Hex i wpisz 16 cyfr szesnastkowych, np. 0123456789ABCDEF.
5. Zaobserwuj wyjściowy szyfrogram i zbadaj jego długość w bajtach (16 bajtów z paddingiem PKCS#7).
6. W CyberChef zmień tryb na CBC i zdefiniuj 8-bajtowy wektor IV: 1122334455667788.
7. W terminalu JSLinux utwórz plik testowy: echo -n 'KRYPTO01' > jawny.txt.
8. Zaszyfruj plik w JSLinux: openssl enc -des-cbc -in jawny.txt -out szyfr_des.bin -K 0123456789ABCDEF -iv 1122334455667788 -p.
9. Porównaj zrzut szesnastkowy pliku szyfr_des.bin (hexdump -C szyfr_des.bin) z wyjściem w CyberChef.
10. Odszyfruj plik w JSLinux: openssl enc -d -des-cbc -in szyfr_des.bin -out odzysk.txt -K 0123456789ABCDEF -iv 1122334455667788.
11. Sprawdź tożsamość odszyfrowanego pliku: diff jawny.txt odzysk.txt.
12. Zaszyfruj plik za pomocą 3DES: openssl enc -des-ede3-cbc -in jawny.txt -out szyfr_3des.bin -K 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF -iv 1122334455667788.
13. Przetestuj deszyfrowanie ze złym kluczem i zarejestruj komunikat błędu 'bad decrypt'.
14. Wykonaj zrzuty ekranu konfiguracji w CyberChef oraz poleceń konsoli JSLinux.
15. Sporządź tabelę porównawczą parametrów DES i 3DES (rozmiar bloku, długość klucza, liczba rund, podatności).
16. Odnotuj w tabeli status standardów: 3DES jest wycofywany (NIST SP 800-131A dopuszcza go tylko do odczytu starszych danych; nowe systemy stosują AES) - sam fakt „działa w OpenSSL" nie oznacza „wolno stosować".
17. Zmierz narzut 3DES względem AES jednym poleceniem: openssl speed -evp des-ede3 -evp aes-128-cbc -seconds 3; zanotuj krotność różnicy przepustowości i wyjaśnij, dlaczego potrojony DES płaci potrójny koszt czasu przy bloku tylko 64-bitowym.
18. Sformułuj wnioski dotyczące bezpieczeństwa przestrzeni kluczy 56 bitów w kontekście historycznego projektu EFF Deep Crack.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Jak 64-bitowy rozmiar bloku wymusza dopełnianie danych do wielokrotności 8 bajtów w schemacie PKCS#7.
• Dlaczego efektywny klucz DES ma tylko 56 bitów pomimo 64-bitowej długości rejestru (obecność bitów parzystości).
• W jaki sposób schemat EDE (Encrypt-Decrypt-Encrypt) w 3DES zapewnia kompatybilność wsteczną z pojedynczym DES.
• Student potrafi przeprowadzić szyfrowanie i deszyfrowanie DES i 3DES w konsoli OpenSSL oraz zweryfikować zgodność z CyberChef.

Cel

Celem zadania jest empiryczne wykazanie fundamentalnej wady bezpieczeństwa trybu ECB (Electronic Codebook). Student przeprowadza szyfrowanie pliku graficznego BMP algorytmem AES w trybach ECB oraz CBC, a następnie dokonuje analizy wizualnej odszyfrowanego nagłówka, udowadniając przetrwanie wzorców danych w trybie ECB.

Scenariusz – opis

W tym zadaniu zbadasz najprostszy i najbardziej niebezpieczny tryb pracy szyfrów blokowych, czyli tryb ECB. W trybie ECB każdy 128-bitowy blok tekstu jawnego jest szyfrowany całkowicie niezależnie od pozostałych za pomocą tego samego klucza. Oznacza to, że dwa identyczne bloki tekstu jawnego P1 = P2 zawsze generują dwa identyczne bloki szyfrogramu C1 = C2. Aby unaocznić ten problem, posłużysz się nieskompresowanym plikiem graficznym w formacie BMP (ang. Bitmap). Plik BMP składa się ze stałego nagłówka o długości 54 bajtów oraz sekwencji pikseli tworzących właściwy obraz rastrowy. Ćwiczenie wykonujesz równolegle w terminalu JSLinux Alpine oraz przy pomocy serwisu CyberChef.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Uruchom maszynę JSLinux Alpine w oknie przeglądarki.
2. Otwórz w drugiej karcie serwis CyberChef (gchq.github.io/CyberChef).
3. W JSLinux wygeneruj testowy plik BMP za pomocą prostego skryptu Pythona lub polecenia dd z powtarzalnym wzorcem.
4. Sprawdź właściwości pliku: ls -l test.bmp oraz file test.bmp.
5. Wyodrębnij 54-bajtowy nagłówek: dd if=test.bmp of=header.bmp bs=1 count=54. Najpierw potwierdź poleceniem file test.bmp, że to 24-bitowy BMP (tylko wtedy nagłówek ma 54 bajty); nagłówka nigdy nie szyfrujesz - szyfrowany jest wyłącznie body.bin, a na końcu składasz sprawny plik graficzny. Finalne zrzuty mają pokazywać tux_ecb.bmp i tux_cbc.bmp obok siebie z podpisem, który tryb zachował kontury.
6. Wyodrębnij dane pikseli: dd if=test.bmp of=body.bin bs=1 skip=54.
7. Zaszyfruj piksele w trybie ECB: openssl enc -aes-128-ecb -in body.bin -out body_ecb.bin -K 00112233445566778899AABBCCDDEEFF -nopad.
8. Zaszyfruj piksele w trybie CBC: openssl enc -aes-128-cbc -in body.bin -out body_cbc.bin -K 00112233445566778899AABBCCDDEEFF -iv 0102030405060708090A0B0C0D0E0F10 -nopad.
9. Scal nagłówek z szyfrogramem ECB: cat header.bmp body_ecb.bin > tux_ecb.bmp.
10. Scal nagłówek z szyfrogramem CBC: cat header.bmp body_cbc.bin > tux_cbc.bmp.
11. W JSLinux zbadaj rozkład powtarzających się bloków za pomocą polecenia xxd body_ecb.bin | uniq -c | head -n 20.
12. W CyberChef wgraj tux_ecb.bmp oraz tux_cbc.bmp i użyj operacji Render Image lub zapisz je lokalnie.
13. Porównaj wizualną czytelność konturów na obrazie zaszyfrowanym w trybie ECB i CBC.
14. Wykonaj zrzuty ekranu prezentujące oba obrazy oraz powtarzalność bloków szesnastkowych.
15. Sporządź tabelę zestawiającą cechy ECB i CBC w kontekście zachowania relacji strukturalnych danych.
16. Sformułuj techniczne uzasadnienie, dlaczego standardy bezpieczeństwa zabraniają używania ECB do danych strukturalnych.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Dlaczego deterministyczny charakter trybu ECB prowadzi do ujawnienia struktury i konturów danych jawnych.
• W jaki sposób łańcuchowanie bloków w trybie CBC (operacja XOR z poprzednim szyfrogramem) niszczy wszelkie powtarzalne wzorce.
• Rola nagłówka pliku BMP i znaczenie zachowania jego integralności przy podglądzie zaszyfrowanych danych graficznych.
• Student potrafi samodzielnie przeprowadzić separację nagłówka pliku binarnego, szyfrowanie w OpenSSL i analizę podatności wzorca.

Cel

Celem zadania jest szczegółowa analiza roli wektora inicjalizacyjnego (IV) oraz mechanizmu dopełniania danych PKCS#7 w trybie Cipher Block Chaining (CBC) algorytmu AES-128. Student bada determinizm szyfrowania przy stałym IV, zróżnicowanie szyfrogramów przy losowym IV oraz strukturę bajtów paddingu w narzędziach CyberChef i OpenSSL.

Scenariusz – opis

W tym laboratorium skupiasz się na dwóch kluczowych elementach trybu CBC: wektorze początkowym IV oraz dopełnieniu bloków. W trybie CBC pierwszy blok tekstu jawnego jest sumowany modulo dwa (XOR) z wektorem IV przed poddaniem transformacji AES. Wektor IV nie musi być tajny, ale musi być unikalny i nieprzewidywalny dla każdej operacji szyfrowania wykonywanej tym samym kluczem. Jeśli dwa identyczne komunikaty zostaną zaszyfrowane z tym samym kluczem i tym samym IV, ich szyfrogramy będą całkowicie identyczne. Ponadto AES operuje na sztywnych 128-bitowych blokach (16 bajtów), dlatego wiadomości o innej długości wymagają standaryzowanego dopełnienia. Standard PKCS#7 definiuje, że jeśli brakuje N bajtów do pełnego bloku (gdzie 1 <= N <= 16), dopisuje się N bajtów o wartości N.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz w przeglądarce CyberChef oraz konsolę JSLinux Alpine.
2. W CyberChef skonfiguruj AES Encrypt: tryb CBC, klucz hex 000102030405060708090a0b0c0d0e0f, IV hex 00000000000000000000000000000000.
3. Wpisz tekst KRYPTOWIEC (10 znaków) i włącz widok wyjścia w formacie Hex.
4. Zanotuj 16-bajtowy szyfrogram i zidentyfikuj 6 bajtów paddingu 06.
5. Zmień tekst na ciąg 16-znakowy i sprawdź, czy szyfrogram powiększył się do 32 bajtów (blok 16x 0x10).
6. Zmień pierwszy bajt IV z 00 na 01 i porównaj wygenerowany szyfrogram z poprzednim.
7. W JSLinux utwórz plik 10-bajtowy: echo -n '1234567890' > p10.txt.
8. Zaszyfruj plik: openssl enc -aes-128-cbc -in p10.txt -out c10.bin -K 000102030405060708090a0b0c0d0e0f -iv 00000000000000000000000000000000.
9. Sprawdź rozmiar pliku: ls -l c10.bin (dokładnie 16 bajtów).
10. Odszyfruj plik bez usuwania paddingu: openssl enc -d -aes-128-cbc -nopad -in c10.bin -out p10_raw.txt -K 000102030405060708090a0b0c0d0e0f -iv 00000000000000000000000000000000.
11. Wyświetl surową zawartość p10_raw.txt w formacie hex: xxd p10_raw.txt lub hexdump -C p10_raw.txt.
12. Zidentyfikuj końcowe 6 bajtów o wartości 0x06.
13. Mini-demonstracja zalążka ataku: skopiuj szyfrogram (cp c10.bin c10_bad.bin), nadpisz jego ostatni bajt dowolną wartością (printf '\x41' | dd of=c10_bad.bin bs=1 seek=15 conv= notrunc) i spróbuj odszyfrować z tymi samymi -K i -iv; zanotuj komunikat błędu weryfikacji dopełnienia OpenSSL. To jest dokładnie ten kanał „padding OK / błąd", który w Zadaniu 2 z poziomu 5.0 zamienia się w pełny atak wyroczni dopełnienia - zapamiętaj treść komunikatu.
14. Utwórz plik 16-bajtowy i powtórz operację z -nopad, weryfikując obecność 16 bajtów o wartości 0x10.
15. Wykonaj zrzuty ekranu z konsoli JSLinux oraz panelu CyberChef z widocznym paddingiem.
16. Zestaw w tabeli rozmiar wejścia, brakujące bajty i wartości dodawane przez PKCS#7.
17. Sformułuj wnioski dotyczące bezpieczeństwa generowania wektorów IV za pomocą generatora CSPRNG.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• W jaki sposób reguła PKCS#7 jednoznacznie określa liczbę dodanych bajtów i eliminuje niejednoznaczność przy odcinaniu dopełnienia.
• Dlaczego tekst o długości równej wielokrotności rozmiaru bloku musi otrzymać dodatkowy pełny blok dopełnienia.
• Rola wektora IV w zapobieganiu atakom słownikowym i uniemożliwianiu wykrycia identycznych początków wiadomości.
• Student potrafi odczytać surowy padding za pomocą opcji -nopad w OpenSSL oraz uzasadnić wymóg losowości wektora IV.

Cel

Celem ćwiczenia jest zbadanie specyfiki trybu licznika AES-CTR, w którym szyfr blokowy funkcjonuje jako generator ciągu pseudolosowego (keystream). Student weryfikuje brak konieczności stosowania paddingu, idealną symetrię operacji szyfrowania i deszyfrowania oraz bada katastrofalne skutki kryptoanalityczne powtórzenia wartości licznika i Nonce.

Scenariusz – opis

W tym zadaniu analizujesz tryb licznika CTR (ang. Counter Mode), który jest powszechnie stosowany w protokołach o wysokiej wydajności. W trybie CTR sam algorytm AES nie szyfruje bezpośrednio tekstu jawnego, lecz ciąg kolejnych wartości licznika. Blok wejściowy dla AES składa się z unikalnej wartości jednorazowej Nonce oraz inkrementowanego rejestru licznika Counter. Wynik szyfrowania AES(Nonce || Counter) tworzy blok strumienia klucza (ang. keystream), który jest sumowany bitowo XOR z tekstem jawnym. Dzięki temu szyfr blokowy zostaje przekształcony w deterministyczny szyfr strumieniowy o dowolnej ziarnistości bajtowej. Oznacza to, że tekst jawny nie musi być uzupełniany do wielokrotności 16 bajtów – długość szyfrogramu jest dokładnie równa długości wejścia.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz serwis CyberChef w przeglądarce internetowej.
2. Uruchom maszynę wirtualną JSLinux Alpine.
3. W CyberChef wybierz operację AES Encrypt, ustaw tryb CTR, klucz hex 0102030405060708090a0b0c0d0e0f10 i IV/Nonce hex a0a1a2a3a4a5a6a7a8a9aaabacadaeaf.
4. Wpisz tekst SEKRET1 (7 bajtów) i sprawdź w formacie Hex długość wyjścia (7 bajtów).
5. Skopiuj szyfrogram do Input i użyj ponownie AES Encrypt (nie Decrypt) z tymi samymi parametrami, odzyskując SEKRET1.
6. W JSLinux utwórz plik o długości 13 bajtów: echo -n 'TAJNY_PROJEKT' > m1.txt.
7. Zaszyfruj plik: openssl enc -aes-128-ctr -in m1.txt -out c1.bin -K 0102030405060708090a0b0c0d0e0f10 -iv a0a1a2a3a4a5a6a7a8a9aaabacadaeaf.
8. Zweryfikuj rozmiar pliku wyjściowego: ls -l c1.bin (dokładnie 13 bajtów).
9. Odszyfruj plik poleceniem openssl enc -d -aes-128-ctr i porównaj z oryginałem.
10. Utwórz drugi plik o długości 13 bajtów: echo -n 'JAWNY_KOMUNIK' > m2.txt.
11. Zaszyfruj m2.txt z identycznym kluczem i IV do pliku c2.bin.
12. W JSLinux uruchom jednolinijkowy skrypt w Pythonie obliczający XOR szyfrogramów: python3 -c "c1=open('c1.bin','rb').read(); c2=open('c2.bin','rb').read(); print(bytes(a^b for a,b in zip(c1,c2)).hex())".
13. Oblicz w Pythonie XOR tekstów jawnych m1 i m2 i potwierdź identyczność ciągów szesnastkowych. Obowiązkowy wynik negatywny do raportu: nałóż na C1 XOR C2 znane słowo (crib), np. pierwsze 5 liter m1, i pokaż odsłonięty fragment m2 - ten jeden odczyt dowodzi, że przy powtórzonym nonce poufność obu wiadomości pada jednocześnie.
14. Wykonaj zrzuty ekranu z CyberChef oraz terminala JSLinux.
15. Sporządź tabelę porównującą tryb CBC i CTR pod kątem paddingu, zrównoleglenia i podatności na powtórzenie IV/Nonce.
16. Sformułuj wnioski techniczne dotyczące zakazu ponownego użycia pary (Klucz, Nonce) w trybie CTR.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• W jaki sposób inkrementacja licznika pozwala na generowanie nieograniczonego strumienia klucza z szyfru blokowego.
• Dlaczego brak dopełnienia w trybie CTR eliminuje narzut pasma i podatności typu Padding Oracle.
• Dlaczego powtórzenie wartości Nonce przy tym samym kluczu prowadzi do całkowitej kompromitacji poufności transmisji.
• Student potrafi wykazać symetrię operacji XOR w CTR oraz zaimplementować test kolizji Nonce w środowisku Linux.

Cel

Celem zadania jest praktyczne zapoznanie się ze standardem szyfrowania uwierzytelnionego z danymi stowarzyszonymi (AEAD) na przykładzie trybu AES-GCM. Student bada jednoczesne zapewnienie poufności i integralności, generowanie 128-bitowego tagu GMAC, weryfikację nagłówków AAD oraz zachowanie algorytmu w przypadku manipulacji pojedynczym bitem szyfrogramu.

Scenariusz – opis

We współczesnej kryptografii sama poufność jest niewystarczająca; konieczne jest zagwarantowanie autentyczności i nienaruszalności danych. Tryb GCM (Galois/Counter Mode) jest wiodącym standardem AEAD wykorzystywanym w protokołach TLS 1.3, IPsec oraz SSH. GCM łączy szyfrowanie danych tekstu jawnego w trybie CTR z generowaniem tagu uwierzytelniającego w ciele Galois GF(2^128) za pomocą funkcji GHASH. Dodatkowo GCM pozwala na dołączenie danych stowarzyszonych AAD (ang. Additional Authenticated Data), takich jak nagłówki pakietu sieciowego. Dane AAD są chronione przed modyfikacją (są uwierzytelnione), ale nie podlegają szyfrowaniu (pozostają jawne). Do przeprowadzenia eksperymentów wykorzystasz serwis CyberChef oraz narzędzia konsoli OpenSSL w środowisku JSLinux.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz stronę CyberChef w przeglądarce.
2. Uruchom emulator JSLinux Alpine.
3. W CyberChef dodaj operację AES GCM Encrypt.
4. Wprowadź klucz hex: 00112233445566778899aabbccddeeff.
5. Wprowadź 96-bitowy IV hex: 102030405060708090a0b0c0.
6. Wpisz w polu AAD nagłówek: ID=1024;ROLA=ADMIN.
7. Wpisz w polu Input tekst: TRANSAKCJA_ZATWIERDZONA_1000.
8. Odczytaj i zanotuj zaszyfrowany ciąg oraz 16-bajtowy Authentication Tag.
9. Skonfiguruj recepturę AES GCM Decrypt z poprawnymi danymi i potwierdź odzyskanie tekstu.
10. Zmień ostatnią cyfrę szyfrogramu i zarejestruj komunikat błędu 'Authentication tag mismatch'.
11. Przywróć szyfrogram, zmień literę w polu AAD i zaobserwuj ten sam błąd integralności.
12. W JSLinux utwórz plik jawny i zaszyfruj go z tagiem: openssl enc -aes-128-gcm -in jawny.txt -out gcm_szyfr.bin -K 00112233445566778899aabbccddeeff -iv 102030405060708090a0b0c0.
13. Zbadaj wygenerowany tag w OpenSSL i spróbuj odszyfrować plik ze zmodyfikowaną zawartością.
14. Ostrzeżenie krytyczne do raportu: nigdy nie używaj ponownie pary (klucz, IV) w GCM - powtórzony nonce w GCM jest groźniejszy niż w CTR, bo oprócz utraty poufności umożliwia odtworzenie klucza funkcji GHASH i fałszowanie tagów dla dowolnych wiadomości (szczegóły ataku: Zadanie 2 z poziomu 4.0 o manipulacji bitowej).
15. Wykonaj zrzuty ekranu prezentujące odrzucenie sfałszowanej wiadomości w CyberChef i JSLinux.
16. Sporządź tabelę porównującą tryby ECB, CBC, CTR i GCM pod kątem poufności, integralności i odporności na manipulacje.
17. Sformułuj wnioski podsumowujące rolę schematów AEAD w nowoczesnych protokołach kryptograficznych.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• W jaki sposób schemat AEAD eliminuje potrzebę ręcznego łączenia szyfru blokowego z odrębną funkcją MAC.
• Rola danych stowarzyszonych AAD w uwierzytelnianiu metadanych protokołów sieciowych bez ich utajniania.
• Dlaczego jakakolwiek próba manipulacji bitem w szyfrogramie lub AAD unieważnia 128-bitowy tag GMAC.
• Student potrafi skonfigurować i przetestować szyfrowanie uwierzytelnione AES-GCM oraz wykazać mechanizm ochrony integralności.

Cel

Celem zadania jest przeanalizowanie budowy i działania klasycznego szyfru strumieniowego RC4 (Rivest Cipher 4). Student bada fazę inicjalizacji tablicy S (KSA), fazę generowania strumienia (PRGA), operację bitowego XOR oraz zapoznaje się z powodami definitywnego wycofania RC4 z nowoczesnych protokołów (m.in. zakaz w RFC 7465) ze względu na obciążenia statystyczne pierwszych bajtów.

Scenariusz – opis

Szyfr RC4, opracowany w 1987 roku przez Rona Rivesta, był przez dekady najpopularniejszym szyfrem strumieniowym na świecie. Wykorzystywano go w standardzie zabezpieczeń sieci bezprzewodowych WEP, protokole WPA oraz we wczesnych wersjach protokołu SSL/TLS. Serce algorytmu stanowi wewnętrzny stan pamięci reprezentowany przez 256-bajtową tablicę permutacji S oraz dwa wskaźniki i oraz j. Algorytm składa się z dwóch faz: KSA (Key Scheduling Algorithm) mieszającego stan za pomocą klucza oraz PRGA generującego kolejne bajty pseudolosowe. Kolejne wygenerowane bajty strumienia są bezpośrednio łączone z tekstem jawnym za pomocą operacji bitowej XOR. W tym zadaniu sprawdzisz działanie RC4 w serwisach CyberChef i Cryptii oraz przeanalizujesz przyczyny jego podatności.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Wejdź na stronę CyberChef (gchq.github.io/CyberChef).
2. Otwórz stronę Cryptii (cryptii.com) i terminal JSLinux Alpine.
3. W CyberChef dodaj operację RC4 z kluczem tekstowym 'SekretnyKlucz2026'.
4. Wprowadź tekst jawny: 'To jest poufny komunikat badawczy w laboratorium kryptologii'.
5. Zanotuj wygenerowany szyfrogram w formacie Hex.
6. W Cryptii wybierz szyfr RC4, wprowadź ten sam klucz i tekst, i zweryfikuj zgodność wyniku.
7. W CyberChef wprowadź ciąg 32 bajtów zerowych (0x00) i odczytaj pierwsze 32 bajty strumienia keystream.
8. W JSLinux utwórz plik testowy: echo -n 'PoufnyKomunikat' > rc4_in.txt.
9. Zaszyfruj plik w JSLinux: openssl enc -rc4 -in rc4_in.txt -out rc4_out.bin -k 'SekretnyKlucz2026' -nosalt.
10. Wyświetl zawartość szesnastkową pliku rc4_out.bin: hexdump -C rc4_out.bin.
11. Odszyfruj plik i potwierdź integralność odzyskanych danych.
12. Zbadaj dokumentację RFC 7465 dotyczącą zakazu stosowania RC4 w TLS ze względu na ataki Bar Mitzvah i Fluhrera.
13. Sporządz tabelę porównawczą stanów wewnętrznych RC4 (256 bajtów) i AES (16 bajtów).
14. Wykonaj zrzuty ekranu konfiguracji w CyberChef oraz wyniku w JSLinux.
15. Zapisz otrzymane ciągi keystream i przeanalizuj ich pseudolosowość.
16. Zmierz obciążenie drugiego bajtu liczbą, nie deklaracją: wklej do JSLinux skrypt rc4_bias.py (def rc4(key,n): S=list(range(256)); j=0; [KSA: for i in range(256): j=(j+S[i]+key[i%len(key)])%256; S[i],S[ j]=S[ j],S[ i]]; [PRGA] i=j=0; out=[]; [pętla n razy:] i=(i+1)%256; j=(j+S[i])%256; S[i],S[ j]=S[ j],S[ i]; out.append(S[(S[ i]+S[j])%256]); return bytes(out)) i dla N = 20000 losowych 16-bajtowych kluczy policz, ile razy drugi bajt strumienia wynosi 0x00. Wynik ma oscylować wokół 2/256 (≈156/20000) zamiast 1/256 (≈78/20000) - to jest mierzalny powód wycofania RC4, wpisz obie liczby do raportu.
17. Sformułuj wnioski wyjaśniające, dlaczego brak odporności na ataki korelacyjne zdyskwalifikował RC4.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• W jaki sposób prosta tablica permutacji S i dodawanie modulo 256 tworzyły wydajny generator strumieniowy.
• Dlaczego operacja szyfrowania strumieniowego jest tożsama z sumowaniem XOR tekstu z bajtami wyjściowymi PRGA.
• Jakie wady fazy KSA (słabe klucze, korelacja pierwszych bajtów) doprowadziły do złamania WEP i wycofania z TLS (RFC 7465).
• Student potrafi wygenerować strumień klucza RC4, porównać implementacje i uzasadnić historyczny upadek tego algorytmu.

Cel

Celem zadania jest zapoznanie się z architekturą nowoczesnego szyfru strumieniowego ChaCha20 oraz powiązanego schematu uwierzytelnionego ChaCha20-Poly1305 (RFC 8439). Student weryfikuje odporność ChaCha20 na ataki czasowe (brak tablic S-box), bada budowę 512-bitowego stanu oraz testuje generowanie i weryfikację tagu Poly1305 w konsoli OpenSSL i CyberChef.

Scenariusz – opis

Szyfr ChaCha20, opracowany przez Daniela J. Bernsteina, jest współczesnym następcą szyfrów strumieniowych i konkurentem AES. W przeciwieństwie do AES, ChaCha20 nie wymaga tablic przeglądowych (S-boksów), lecz opiera się wyłącznie na operacjach ARX (dodawanie 32-bitowe, rotacja bitowa, XOR). Dzięki architekturze ARX algorytm wykonuje się w stałym czasie, co całkowicie eliminuje ataki czasowe z kanałów bocznych w implementacjach programowych. Wewnętrzny stan algorytmu stanowi macierz 4x4 słów 32-bitowych (łącznie 64 bajty / 512 bitów), zawierająca stałe, klucz 256-bitowy, licznik i Nonce. Standard RFC 8439 łączy ChaCha20 z szybkim kodem uwierzytelniania wiadomości Poly1305, tworząc kompletny i bezpieczny szyfr AEAD. W zadaniu przetestujesz zarówno czysty szyfr ChaCha20, jak i schemat ChaCha20-Poly1305 w konsoli JSLinux oraz w CyberChef.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz serwis CyberChef w przeglądarce.
2. Uruchom konsolę JSLinux Alpine z biblioteką OpenSSL.
3. W CyberChef dodaj operację ChaCha z 20 rundami.
4. Wprowadź 32-bajtowy klucz hex: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f.
5. Wprowadź 12-bajtowy Nonce hex: 000000000000004a00000000.
6. Wprowadź tekst jawny i zbadaj długość szyfrogramu.
7. Zmień recepturę na ChaCha20-Poly1305 i zaobserwuj wygenerowanie 128-bitowego tagu Poly1305.
8. W JSLinux utwórz plik wejściowy: echo -n 'Test_ChaCha20_Poly1305' > test_cc.txt.
9. Zaszyfruj plik czystym ChaCha20: openssl enc -chacha20 -in test_cc.txt -out test_cc.enc -K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f -iv 000000000000004a00000000.
10. Sprawdź rozmiar pliku wyjściowego i porównaj z rozmiarem pliku wejściowego.
11. Odszyfruj plik poleceniem openssl enc -d -chacha20 i potwierdź zgodność.
12. Zaszyfruj plik za pomocą ChaCha20-Poly1305 i zbadaj procedurę generowania tagu.
13. Dokonaj celowego przekłamania jednego bajtu w zaszyfrowanym pliku i spróbuj odszyfrować. Kluczowy kontrast do raportu: to samo przekłamanie wykonaj dwukrotnie - raz na pliku z czystego ChaCha20 (odszyfrowanie przejdzie bez ostrzeżenia i po cichu zwróci zmieniony tekst!) oraz raz na pliku ChaCha20-Poly1305 (natychmiastowy błąd tagu). Ten jeden eksperyment A/B dowodzi, po co istnieje Poly1305.
14. Zarejestruj błąd autoryzacji zgłoszony przez silnik kryptograficzny.
15. Wykonaj zrzuty ekranu z CyberChef oraz terminala JSLinux.
16. Sporządź raport techniczny opisujący architekturę ARX i uzasadniający popularność ChaCha20 w TLS 1.3 i VPN WireGuard.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• W jaki sposób architektura ARX zapewnia odporność na ataki czasowe z kanałów bocznych (brak tablic S-box w pamięci cache).
• Rola macierzy stanu 4x4 słów 32-bitowych i funkcja stałej 'expand 32-byte k'.
• Jak połączenie ChaCha20 z Poly1305 tworzy kompletny i wydajny szyfr AEAD zgodny z RFC 8439.
• Student potrafi posługiwać się poleceniami ChaCha20 i ChaCha20-Poly1305 w OpenSSL oraz interpretować rolę tagu integralności.

Cel

Celem zadania jest empiryczne zbadanie kluczowych właściwości kryptograficznych funkcji skrótu na przykładzie algorytmu SHA-256. Student bada determinizm, jednokierunkowość oraz przeprowadza ilościowy pomiar efektu lawinowego (Avalanche Effect), zliczając liczbę zmienionych bitów skrótu przy modyfikacji pojedynczego bitu danych wejściowych.

Scenariusz – opis

Kryptograficzna funkcja skrótu przekształca dowolny ciąg danych o zmiennej długości w unikalny skrót o stałym rozmiarze. W przypadku algorytmu SHA-256 (Secure Hash Algorithm 256-bit) wyjście ma zawsze dokładnie 256 bitów, czyli 32 bajty (64 znaki szesnastkowe). Bezpieczna funkcja skrótu musi spełniać trzy postulaty: odporność na przeciwobraz, odporność na drugi przeciwobraz oraz odporność na kolizje. Fundamentalną cechą dobrej funkcji skrótu jest efekt lawinowy (ang. Avalanche Effect). Efekt lawinowy oznacza, że nawet najmniejsza możliwa zmiana danych wejściowych (odwrócenie pojedynczego bitu) powinna skutkować drastyczną zmianą skrótu. W idealnym przypadku losowej zmiany powinno ulec około 50% wszystkich bitów wyjściowych (czyli około 128 bitów w SHA-256).

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz CyberChef w przeglądarce internetowej.
2. Uruchom emulator JSLinux Alpine.
3. W CyberChef dodaj operację SHA2 z rozmiarem 256 bitów.
4. Wpisz tekst 'BezpieczenstwoSystemowIT2026' i zanotuj 64-znakowy hash hex.
5. Zmień ostatnią cyfrę z 6 na 7 i zanotuj nowy hash hex.
6. W CyberChef zbadaj hash pustego wejścia i sprawdź zgodność ze standardem NIST.
7. W JSLinux utwórz dwa pliki z różnicą 1 bitu: echo -n 'Test1' > f1.txt; echo -n 'Test0' > f2.txt.
8. Wygeneruj skróty SHA-256: sha256sum f1.txt f2.txt.
9. Napisz w JSLinux skrypt Pythona obliczający odległość Hamminga między hashami obu plików.
10. Uruchom skrypt: python3 -c "import hashlib; h1=hashlib.sha256(b'Test1').digest(); h2=hashlib.sha256(b'Test0').digest(); diff=sum(bin(b1^b2).count('1') for b1,b2 in zip(h1,h2)); print(f'Roznice bitowe: {diff}/256 ({diff/256*100:.2f}%)')".
11. Zanotuj liczbę zmienionych bitów oraz wartość procentową.
12. Przeprowadź 4 dodatkowe próby z różnymi danymi wejściowymi o różnicy 1 bitu.
13. Pokaż skalę jednokierunkowości: znajdź drugi przeciwobraz dla skrótu obciętego do 16 bitów (brute force w Pythonie po hashlib znajduje go w ułamku sekundy), a obok wylicz, ile czasu zajęłoby to samo dla pełnych 256 bitów przy 10^9 hashy/s (2^256/10^9 s, czyli około 10^60 lat wobec 10^10 lat wieku wszechświata). Obie liczby - sekundy i 10^60 lat - trafiają do raportu jako dowód, że „odwracalny w teorii" nie znaczy „odwracalny w praktyce".
14. Oblicz średnią liczbę zmienionych bitów dla wszystkich 5 prób.
15. Zestaw wyniki w tabeli z kolumnami: Próba, Tekst 1, Tekst 2, Odległość Hamminga, Udział procentowy.
16. Wykonaj zrzuty ekranu konsoli JSLinux z wykonanym skryptem pomiarowym.
17. Sformułuj wnioski potwierdzające spełnienie ścisłego kryterium lawinowego (SAC).

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Dlaczego bezpieczna funkcja skrótu musi charakteryzować się pseudolosowością rozkładu bitów wyjściowych.
• W jaki sposób zmiana pojedynczego bitu wejścia propaguje się na około 50% bitów wyjścia (odległość Hamminga bliska 128 bitów).
• Znaczenie determinizmu funkcji skrótu przy weryfikacji integralności danych i oprogramowania.
• Student potrafi zautomatyzować pomiar odległości Hamminga w Pythonie i ilościowo ocenić jakość efektu lawinowego.

Cel

Celem zadania jest praktyczne zrozumienie konstrukcji kodu uwierzytelniania wiadomości opartego na funkcji skrótu (HMAC). Student bada, dlaczego prosty skrót H(Klucz || Wiadomość) jest podatny na atak dołączenia długości, jak dwuetapowa konstrukcja HMAC z dopełnieniami ipad i opad rozwiązuje ten problem oraz weryfikuje generowanie HMAC-SHA256 w CyberChef i konsoli OpenSSL.

Scenariusz – opis

Sama funkcja skrótu gwarantuje wykrycie przypadkowych błędów transmisji, lecz nie chroni przed aktywnym adwersarzem, który może podmienić zarówno treść, jak i jej skrót. Aby zapewnić autentyczność pochodzenia i nienaruszalność wiadomości, stosuje się kody MAC (Message Authentication Code) wykorzystujące tajny klucz współdzielony. Naiwna próba skonstruowania kodu MAC poprzez sklejenie klucza z wiadomością Hash(K || M) okazała się krytycznie podatna na ataki typu Length Extension Attack. W 1996 roku Bellare, Canetti i Krawczyk zaproponowali konstrukcję HMAC, ustandaryzowaną w dokumencie RFC 2104. HMAC stosuje bezpieczną dwuprzebiegową procedurę: HMAC(K, M) = H((K XOR opad) || H((K XOR ipad) || M)), gdzie ipad to powtórzony bajt 0x36, a opad to 0x5c. W tym laboratorium zbadasz działanie HMAC-SHA256 oraz sprawdzisz jego odporność na manipulacje danymi.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz CyberChef w przeglądarce internetowej.
2. Uruchom maszynę wirtualną JSLinux Alpine.
3. W CyberChef dodaj operację HMAC z funkcją skrótu SHA256.
4. Wprowadź klucz tajny: 'SuperTajneHasloHMAC789' i tekst: 'PRZELEW: 1000 PLN NA KONTO 1234'.
5. Zanotuj wyjściowy 64-znakowy kod HMAC w formacie Hex.
6. Zmień kwotę na 9000 PLN i zaobserwuj wygenerowanie zupełnie nowego kodu.
7. Zbuduj w CyberChef ręczny schemat HMAC: utwórz blok klucza (64B), połącz z ipad (XOR 0x36), doklej tekst i policz SHA256.
8. Policz drugi etap: blok klucza z opad (XOR 0x5c), doklej wynik pierwszego etapu i policz końcowy SHA256.
9. Porównaj wyjście ręcznego potoku z operacją wbudowaną HMAC i potwierdź zgodność co do bita.
10. W JSLinux utwórz plik z wiadomością: echo -n 'PRZELEW: 1000 PLN NA KONTO 1234' > msg.txt.
11. Wygeneruj kod HMAC w JSLinux: openssl dgst -sha256 -hmac 'SuperTajneHasloHMAC789' msg.txt.
12. Porównaj wyjście z konsoli JSLinux z kodem z CyberChef.
13. Demonstracja, dlaczego HMAC istnieje: w Pythonie zaimplementuj naiwny tag T = SHA256(K || M) dla krótkiego K, dopisz do M własny sufiks z poprawnym dopełnieniem Merkle-Damgårda (własna funkcja md_pad, wzór z Zadania 7 poziomu 4.0) i pokaż, że sfałszowany tag przechodzi weryfikację naiwną; ten sam sufiks doklejony do komunikatu z HMAC weryfikacji nie przechodzi. Oba wyniki (fałszerstwo działa / fałszerstwo odrzucone) dokumentujesz zrzutami.
14. Zmień zawartość pliku msg.txt i zaobserwuj zmianę wygenerowanego kodu.
15. Wykonaj zrzuty ekranu z ręcznej konstrukcji HMAC w CyberChef oraz polecenia openssl dgst.
16. Sporządź tabelę porównującą funkcje skrótu, kody MAC oraz podpisy cyfrowe.
17. Sformułuj wnioski techniczne wyjaśniające, w jaki sposób zagnieżdżenie H(K xor opad || H(...)) blokuje ataki dołączenia długości.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Dlaczego prosty skrót kryptograficzny bez klucza nie zabezpiecza przed celową modyfikacją treści przez aktywnego intruza.
• W jaki sposób wewnętrzne i zewnętrzne dopełnienie (ipad i opad) chroni konstrukcję HMAC przed atakiem Length Extension Attack.
• Różnica w zastosowaniach pomiędzy symetrycznym kodem HMAC a asymetrycznym podpisem cyfrowym.
• Student potrafi ręcznie zrekonstruować algorytm HMAC w CyberChef oraz wygenerować kody uwierzytelniające w konsoli OpenSSL.

Cel

Celem zadania jest praktyczne wykazanie, dlaczego szybkie funkcje skrótu (takie jak MD5 czy SHA-256) są niebezpieczne w zastosowaniu do ochrony haseł. Student bada mechanizm ataków słownikowych i tablic tęczowych, rolę unikalnej soli w unieważnianiu prekomputacji oraz testuje działanie funkcji derywacji klucza PBKDF2 z regulowaną liczbą iteracji w konsoli Linux i CyberChef.

Scenariusz – opis

Powszechnym błędem początkujących programistów jest przechowywanie haseł użytkowników w postaci czystego skrótu SHA-256(hasło). Funkcje skrótu z rodziny SHA zostały zaprojektowane z myślą o maksymalnej szybkości przetwarzania dużych wolumenów danych. Współczesna karta graficzna może przeliczać dziesiątki miliardów skrótów SHA-256 na sekundę, co czyni ataki siłowe i słownikowe trywialnymi. Ponadto identyczne hasła użytkowników dają identyczne skróty, co umożliwia stosowanie tablic tęczowych (ang. rainbow tables). Rozwiązaniem pierwszego problemu jest dodanie kryptograficznej soli (losowego ciągu dopisywanego do hasła przed haszowaniem). Rozwiązaniem drugiego problemu są wyspecjalizowane, celowo spowolnione funkcje wyprowadzania klucza (KDF), takie jak PBKDF2, bcrypt czy Argon2.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz serwis CyberChef w oknie przeglądarki.
2. Uruchom emulator JSLinux Alpine.
3. W CyberChef wprowadź słabe hasło tekstowe (np. 'student123') i oblicz jego skrót SHA-256.
4. Sprawdź uzyskany hash w darmowej bazie rainbow tables (np. crackstation.net) i odnotuj natychmiastowe złamanie.
5. Dodaj do hasła losową 16-znakową sól i zaobserwuj zmianę hasha na nieobecny w bazie.
6. W CyberChef dodaj operację Derive PBKDF2 Key z funkcją skrótu SHA256.
7. Ustaw sól szesnastkową i przetestuj generowanie klucza dla liczby iteracji równej 1000, 10000 oraz 100000.
8. W JSLinux utwórz plik testowy: echo 'Dane weryfikacyjne konta' > konto.txt.
9. Zaszyfruj plik z użyciem PBKDF2: openssl enc -aes-256-cbc -pbkdf2 -iter 10000 -in konto.txt -out konto.enc -pass pass:student123 -p.
10. Zwróć uwagę na wypisane przez OpenSSL wartości Salt, Key i IV wygenerowane przez PBKDF2.
11. Zmierz czas wykonania deszyfrowania dla 10 000 iteracji: time openssl enc -d -aes-256-cbc -pbkdf2 -iter 10000 -in konto.enc -out /dev/null -pass pass:student123.
12. Powtórz pomiar czasu dla 100 000 oraz 300 000 iteracji, rejestrując czas w sekundach.
13. Odszyfruj plik z błędnym hasłem i zarejestruj reakcję OpenSSL.
14. Wykonaj zrzuty ekranu prezentujące operację PBKDF2 w CyberChef oraz pomiary czasu w JSLinux.
15. Sporządź tabelę zestawiającą liczbę iteracji, czas operacji oraz szacowany koszt ataku brute force na 1 milion haseł.
16. Sformułuj wnioski techniczne opierając się na wytycznych OWASP Password Storage Cheat Sheet. Obowiązkowe liczby: aktualne zalecenie OWASP dla PBKDF2-HMAC-SHA-256 to 600 000 iteracji - przelicz koszt złamania słownikowego 8-znakowego hasła dla 1 iteracji i dla 600 000 iteracji przy 10^9 hashy/s atakującego. Dopisz zastrzeżenie, że PBKDF2 spowalnia atak tylko liniowo (bez kosztu pamięci), więc pełną odpowiedź dają KDF-y pamięciochłonne (scrypt, Argon2id - Zadanie 10 z poziomu 5.0).

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Dlaczego wysoka wydajność prostych funkcji skrótu (SHA-256) stanowi krytyczne zagrożenie przy przechowywaniu haseł.
• Jak unikalna sól dla każdego konta zapobiega atakom z użyciem prekomputowanych tablic tęczowych.
• Rola parametru iteracji (work factor) w PBKDF2 jako mechanizmu wyrównującego szanse obrońcy w starciu z akceleratorami sprzętowymi.
• Student potrafi poprawnie zastosować mechanizm PBKDF2 w OpenSSL oraz CyberChef i zinterpretować wyniki pomiaru czasu.