AES-GCM – szyfrowanie danych i uwierzytelnianie w jednym

AES-GCM (Galois/Counter Mode) to jeden z najważniejszych współczesnych sposobów wykorzystania AES. Zapewnia jednocześnie:

• poufność – dane są zaszyfrowane,
• integralność – wykrywa modyfikację danych,
• uwierzytelnienie danych – odbiorca wie, że ciphertext nie został zmieniony.

To przykład konstrukcji AEAD — Authenticated Encryption with Associated Data.

                 AES-GCM
                    |
        +-----------+-----------+
        |                       |
    Encryption             Authentication
        |                       |
        v                       v
   Confidentiality          Integrity

Najważniejsze: AES-GCM nie jest zwykle używany sam

W nowoczesnym protokole często wygląda to tak:

X25519
   ↓
Shared Secret
   ↓
KDF
   ↓
AES-GCM Key
   ↓
AES-GCM
   ↓
Encrypted + Authenticated Data

Czyli X25519 uzgadnia sekret, a AES-GCM szyfruje właściwe dane.

Jak działa AES-GCM?

Można uprościć cały proces:

Plaintext
    |
    v
 AES-GCM
    |
    +---- Key
    |
    +---- Nonce
    |
    v
Ciphertext + Authentication Tag

Po drugiej stronie:

Ciphertext + Tag
        |
        v
     AES-GCM
        |
     +--+--+
     |     |
   VALID  INVALID
     |
     v
  Plaintext

Jeżeli ktoś zmieni nawet jeden bit ciphertextu, prawidłowa weryfikacja powinna się nie powieść.

Co oznacza AEAD?

Authenticated Encryption with Associated Data.

To bardzo ważna koncepcja.

AES-GCM może chronić:

1. Dane szyfrowane

Plaintext
   ↓
Encrypted

2. Dane uwierzytelniane, ale nie szyfrowane

Na przykład nagłówki protokołu:

Header
   |
   v
Authenticated
but NOT encrypted

Dzięki temu odbiorca może sprawdzić, czy nagłówek nie został zmieniony.

Przykład

Załóżmy:

message = "Transfer 1000 PLN"

AES-GCM tworzy:

Ciphertext = ...
Tag        = ...

Atakujący zmienia ciphertext:

"Transfer 1000 PLN"
        ↓
"Transfer 9000 PLN"

Przy poprawnym użyciu AES-GCM odbiorca wykryje manipulację:

Authentication Tag
        |
        v
      INVALID
        |
        X
     Reject

To ogromna przewaga nad starszymi konstrukcjami, które wymagały osobnego mechanizmu MAC.

AES-GCM vs zwykły AES

AES jest algorytmem szyfrującym blokowym.

GCM jest trybem pracy:

AES
 +
GCM
 =
AES-GCM

Sam AES nie określa, jak bezpiecznie wykorzystać szyfr do ochrony strumienia danych.

Dlatego:

AES-128-GCM
AES-256-GCM

są kompletnymi konstrukcjami używanymi w protokołach.

AES-128-GCM vs AES-256-GCM

Najczęściej spotkasz:

AES-128-GCM
AES-256-GCM

Różnica dotyczy długości klucza:

AES-256 nie jest automatycznie „lepszy” dla każdego zastosowania. AES-128 już zapewnia bardzo wysoki poziom bezpieczeństwa w klasycznym modelu.

Nonce – krytyczny element AES-GCM

Jedna z najważniejszych zasad:

Nie wolno ponownie używać tego samego nonce z tym samym kluczem.

Schemat:

Key A + Nonce 1
       ↓
    Message 1

Key A + Nonce 2
       ↓
    Message 2

Natomiast:

Key A + Nonce 1
       ↓
    Message 1

Key A + Nonce 1
       ↓
    Message 2

jest bardzo niebezpieczne.

Reuse nonce w GCM może prowadzić do poważnego naruszenia bezpieczeństwa, włącznie z możliwością odzyskania informacji o plaintextach i zagrożeniem dla autentyczności.

Dlaczego nonce jest tak ważny?

Wyobraź sobie:

        SAME KEY
           |
     +-----+-----+
     |           |
 Nonce A       Nonce A
     |           |
Message 1     Message 2

To jest sytuacja, której poprawna implementacja powinna unikać.

Dlatego biblioteki kryptograficzne powinny zarządzać nonce w sposób bezpieczny dla konkretnego protokołu.

Nonce ≠ Secret Key

To również częste nieporozumienie.

Key
→ tajny

Nonce
→ nie musi być tajny

Nonce może być przesyłany razem z ciphertextem:

Nonce + Ciphertext + Tag

Bezpieczeństwo wynika z tego, że przeciwnik nie zna klucza, a nonce jest odpowiednio unikalny dla danego klucza.

Authentication Tag

AES-GCM generuje również tag uwierzytelniający.

Uproszczony schemat:

Plaintext
   |
   v
AES-GCM
   |
   +--> Ciphertext
   |
   +--> Authentication Tag

Odbiorca sprawdza:

Ciphertext
+
Tag
+
Key
+
Nonce

Jeśli tag jest nieprawidłowy:

INVALID
   |
   X
Nie odszyfrowuj / odrzuć dane

AES-GCM + X25519

To jeden z najważniejszych zestawów do zapamiętania.

Alice                         Bob
  |                             |
  |------ X25519 -------------->|
  |                             |
  |<----- X25519 ---------------|
  |                             |
  +------ Shared Secret --------+
                |
                v
               KDF
                |
                v
          AES-GCM Key
                |
                v
         Encrypted Session

Czyli:

X25519 → uzgadnia sekret

KDF → wyprowadza klucz

AES-GCM → szyfruje dane

AES-GCM vs ChaCha20-Poly1305

To bardzo ważne porównanie.

Oba są współczesnymi konstrukcjami AEAD.

W uproszczeniu:

AES-GCM
→ świetny, szczególnie z hardware AES acceleration

ChaCha20-Poly1305
→ świetny wybór na urządzeniach bez szybkiego AES hardware

AES-GCM w TLS

TLS 1.3 bardzo często wykorzystuje:

TLS 1.3
   |
   +--> AES-128-GCM
   |
   +--> AES-256-GCM
   |
   +--> ChaCha20-Poly1305

Przykładowy model:

Client                         Server
  |                              |
  |       Key Exchange           |
  |----------------------------->|
  |                              |
  |       Session Keys           |
  |<---------------------------->|
  |                              |
  |==== AES-GCM encrypted ======>|
  |<==== AES-GCM encrypted ======|

AES-GCM w VPN

W zależności od protokołu i konfiguracji AES-GCM może być wykorzystywany do szyfrowania ruchu VPN.

Przykładowo:

Computer
   |
   v
VPN Tunnel
   |
AES-GCM
   |
   v
Internet

Warto jednak pamiętać, że WireGuard standardowo korzysta z ChaCha20-Poly1305, a nie AES-GCM.

AES-GCM w HTTPS

HTTPS opiera się na TLS, a TLS może używać AES-GCM:

Browser
   |
   | HTTPS
   v
TLS
   |
AES-GCM
   |
   v
Web Server

Czyli AES-GCM może być jednym z mechanizmów chroniących dane przesyłane przez HTTPS.

AES-GCM w aplikacjach

Może być używany do ochrony:

API
Files
Databases
Tokens
Messages
Backups
Configuration
Sensitive application data

Ale kluczowa jest prawidłowa implementacja.

Największe błędy często dotyczą nie samego AES, lecz:

❌ nonce reuse
❌ słabe zarządzanie kluczami
❌ hardcoded keys
❌ niewłaściwa obsługa błędów
❌ brak rotacji kluczy
❌ własna implementacja kryptografii

AES-GCM nie rozwiązuje problemu zarządzania kluczami

To bardzo ważne.

Możemy mieć idealnie zaszyfrowane dane:

AES-GCM
   |
   v
Secure ciphertext

ale jeśli klucz leży:

config.json

jako:

"secret_key": "123456..."

to cała kryptografia niewiele pomaga.

Dlatego w produkcji klucze powinny być odpowiednio chronione, np. przez:

KMS
HSM
Secrets Manager
Hardware-backed storage
Secure key vault

AES-GCM i Docker Secrets

W kontekście wcześniejszych tematów:

Docker Secret
      |
      v
Application
      |
      v
AES-GCM Key
      |
      v
Encrypted Data

Docker Secrets nie szyfrują automatycznie Twoich danych za pomocą AES-GCM.

Ich rolą jest bezpieczniejsze dostarczanie sekretów do kontenera.

To aplikacja może następnie wykorzystać sekret jako klucz kryptograficzny.

AES-GCM i Kubernetes Secrets

Analogicznie:

Kubernetes Secret
       |
       v
Application
       |
       v
Encryption Key

Sam fakt użycia Kubernetes Secret nie oznacza, że dane aplikacji są chronione AES-GCM.

Trzeba rozróżniać:

Secret Management
        ≠
Data Encryption

AES-GCM a hashing

Nie należy mylić:

AES-GCM
→ szyfrowanie + uwierzytelnienie

SHA-256
→ funkcja hashująca

Argon2
→ password hashing / KDF

HMAC
→ message authentication

To różne narzędzia.

AES-GCM a hasła

Nie używamy AES-GCM do przechowywania haseł użytkowników w bazie.

Nie:

password
   ↓
AES-GCM
   ↓
database

Lepiej:

password
   ↓
Argon2id / odpowiedni password hashing
   ↓
database

Hasło powinno być przechowywane jako odpowiednio zabezpieczony hash, a nie jako szyfrowalny sekret.

Czy AES-GCM jest post-quantum?

Tutaj sytuacja jest ciekawsza niż w przypadku Ed25519 i Curve25519.

AES jest algorytmem symetrycznym i nie jest łamany przez algorytm Shora w taki sam sposób jak ECC/RSA.

Algorytm Grovera teoretycznie zmniejsza efektywną siłę klucza symetrycznego mniej więcej o połowę.

W uproszczeniu:

AES-128
   ↓
~64-bit security against idealized Grover search

AES-256
   ↓
~128-bit security

Dlatego w kontekście długoterminowej odporności kwantowej AES-256 jest często preferowany nad AES-128.

Nie oznacza to jednak, że AES-GCM sam rozwiązuje problem post-quantum — jeśli klucz sesyjny został uzgodniony przez klasyczne X25519, nadal mamy problem z warstwą key exchange.

Bardzo ważna układanka PQC

Możemy mieć:

             Classical
                 |
              X25519
                 |
                 v
           Shared Secret

oraz:

             Post-Quantum
                 |
               ML-KEM
                 |
                 v
           Shared Secret

A następnie:

X25519 Secret
      +
ML-KEM Secret
      |
      v
Hybrid KDF
      |
      v
AES-256-GCM
      |
      v
Encrypted Data

To jest bardzo ciekawy kierunek rozwoju nowoczesnych protokołów.

Najważniejsza układanka

Po naszych poprzednich tematach można już zbudować cały łańcuch:

                    CRYPTOGRAPHY
                         |
          +--------------+--------------+
          |                             |
      KEY EXCHANGE                  SIGNATURE
          |                             |
       X25519                        Ed25519
          |                             |
          v                             v
    Shared Secret                  Authentication
          |
          v
         KDF
          |
          v
     Session Key
          |
          v
      AES-GCM
          |
          v
 Encrypted + Authenticated Data

A w przypadku nowoczesnego podejścia post-quantum:

X25519 + ML-KEM
       |
       v
  Hybrid Key Exchange
       |
       v
     KDF
       |
       v
  AES-256-GCM

Zapamiętaj trzy rzeczy:

X25519 → uzgadniamy wspólny sekret

Ed25519 → podpisujemy i uwierzytelniamy

AES-GCM → szyfrujemy dane i wykrywamy ich modyfikację

To razem tworzy bardzo typowy zestaw elementów spotykanych w nowoczesnych protokołach bezpieczeństwa.

Polecane wpisy

Algorytmy kompresji wideo (H.264, H.265): optymalizacja przepustowości sieci

Algorytmy kompresji wideo (H.264, H.265): optymalizacja przepustowości sieci W erze cyfrowej transmisji danych, algorytmy kompresji wideo odgrywają kluczową rolę w Czytaj dalej

Szyfrowanie atrybutowe (Attribute-Based Encryption – ABE): kontrola dostępu oparta na atrybutach

🔒 Szyfrowanie atrybutowe (Attribute-Based Encryption - ABE): kontrola dostępu oparta na atrybutach W dobie cyfrowej transformacji tradycyjne systemy zabezpieczeń stają Czytaj dalej