HPKE – Hybrid Public Key Encryption (hybrydowe szyfrowanie kluczem publicznym)

HPKE (Hybrid Public Key Encryption) to nowoczesny standard szyfrowania hybrydowego, który łączy kryptografię asymetryczną (np. X25519) z wydajnym szyfrowaniem symetrycznym (np. AES-GCM lub ChaCha20-Poly1305).

Jego główny cel:

Umożliwić bezpieczne szyfrowanie wiadomości dla odbiorcy posiadającego klucz publiczny, bez konieczności wcześniejszego ustanawiania wspólnej sesji.

Schemat:

                 HPKE

       +----------+----------+
       |                     |
 Key Encapsulation      AEAD Encryption
       |                     |
    X25519              AES-GCM
    DHKEM               ChaCha20-Poly1305
       |                     |
       +----------+----------+
                  |
            Encrypted Message

Dlaczego powstało HPKE?

Klasyczny problem:

Alice chce wysłać zaszyfrowaną wiadomość do Boba.

Bob ma:

Bob Public Key
Bob Private Key

Alice zna tylko:

Bob Public Key

Jak zaszyfrować dane?

Stare podejście:

RSA Encryption

Problemy:

• duże klucze,
• ograniczona wydajność,
• brak nowoczesnego modelu AEAD,
• brak eleganckiej obsługi forward secrecy.

HPKE rozwiązuje to inaczej:

Public Key Crypto
        +
Symmetric Encryption
        |
        v
Hybrid Encryption

Idea szyfrowania hybrydowego

Najważniejsza zasada współczesnej kryptografii:

Nie szyfrujemy dużych danych kryptografią asymetryczną.

Dlaczego?

Bo algorytmy asymetryczne są wolniejsze.

Dlatego:

Asymmetric Crypto

       |
       v

  Exchange Secret Key

       |
       v

Symmetric Crypto

       |
       v

 Encrypt Data

Czyli:

• X25519 → ustala sekret,
• KDF → tworzy klucz,
• AES-GCM / ChaCha20-Poly1305 → szyfruje dane.

Architektura HPKE

HPKE składa się z kilku elementów:

HPKE

KEM
 |
 |-- Key Encapsulation Mechanism
 |
 v

KDF
 |
 |-- Key Derivation Function
 |
 v

AEAD
 |
 |-- AES-GCM / ChaCha20-Poly1305

1. KEM – Key Encapsulation Mechanism

KEM odpowiada za stworzenie wspólnego sekretu.

Przykład:

X25519

Alice
 |
 | Ephemeral Key
 |
 v

Bob Public Key

       |
       v

Shared Secret

Najczęściej spotykane:

DHKEM(X25519, HKDF-SHA256)

2. KDF – Key Derivation Function

Surowy sekret z X25519 nie jest używany bezpośrednio.

Najpierw:

Shared Secret
       |
       v
      HKDF
       |
       v
Session Key

Dlaczego?

Ponieważ KDF:

• normalizuje sekret,
• generuje odpowiednią długość klucza,
• umożliwia separację różnych zastosowań.

3. AEAD – szyfrowanie danych

Ostatnia warstwa:

Session Key
      |
      v
+-------------+
|             |
AES-GCM   ChaCha20-Poly1305
|             |
+-------------+
      |
      v
Encrypted Data

Przykład działania HPKE

Załóżmy:

Bob publikuje:

Bob Public Key

Alice chce wysłać:

"tajna wiadomość"

Proces:

1. Alice generuje efemeryczny klucz

Alice Ephemeral Key

2. Robi wymianę klucza

Alice Ephemeral Private Key
+
Bob Public Key

        |
        v

Shared Secret

3. Tworzy klucz sesyjny

Shared Secret

      |
     HKDF

      |
      v

AES Key

4. Szyfruje wiadomość

Message

   +
AES-GCM

   |

Ciphertext

5. Bob odszyfrowuje

Bob używa:

Bob Private Key
+
Ciphertext

i odzyskuje:

Plaintext

HPKE i X25519

To bardzo naturalne połączenie:

             HPKE

              |
              |
            X25519
              |
              v
       Shared Secret
              |
              v
             HKDF
              |
              v
        AES-GCM / ChaCha20

Czyli:

X25519
→ uzgadnia sekret

HPKE
→ kompletny schemat szyfrowania

AES-GCM
→ chroni dane

HPKE vs TLS

To ważne rozróżnienie.

TLS:

Client
  |
Handshake
  |
Server
  |
Session

TLS tworzy cały kanał komunikacyjny.

HPKE:

Message
    |
    v
Encrypted
    |
    v
Send anywhere

HPKE szyfruje konkretną wiadomość lub obiekt.

HPKE vs HTTPS

HTTPS:

Browser
   |
 TLS Tunnel
   |
Server

HPKE:

Application

Message A
   |
 HPKE
   |
Encrypted Object

Można powiedzieć:

TLS
→ zabezpiecza połączenie

HPKE
→ zabezpiecza dane niezależnie od kanału

HPKE vs PGP

HPKE jest często porównywany do klasycznego PGP.

PGP:

RSA/ECC
+
Symmetric Encryption

HPKE:

X25519
+
HKDF
+
AES-GCM/ChaCha20

HPKE jest bardziej zgodne z nowoczesnym projektowaniem protokołów.

HPKE vs RSA Encryption

Stare podejście:

RSA Public Key
        |
        v
Encrypt Message

HPKE:

X25519
        |
        v
Create Secret
        |
        v
ChaCha20/AES
        |
        v
Encrypt Data

Zaletą HPKE jest m.in.:

• mniejsze klucze,
• lepsza wydajność,
• łatwiejsze wykorzystanie AEAD,
• możliwość wykorzystania forward secrecy.

HPKE i Forward Secrecy

Bardzo ważna cecha.

HPKE może wykorzystywać efemeryczne klucze:

Alice

Ephemeral Key
      |
      v
One Message

Delete Key

Jeżeli później ktoś zdobędzie klucz prywatny Boba:

Bob Private Key leaked

nie musi to oznaczać możliwości odszyfrowania wszystkich wcześniejszych wiadomości.

HPKE w MLS (Messaging Layer Security)

Jednym z ważnych zastosowań HPKE jest:

IETF MLS (Messaging Layer Security).

MLS jest standardem projektowanym dla bezpiecznej komunikacji grupowej.

Schemat:

Users
 |
 v
MLS
 |
 v
HPKE
 |
 v
Encrypted Group Messages

HPKE w aplikacjach

Może być używany do:

Secure messaging

API encryption

Cloud secrets

End-to-end encryption

Secure file sharing

Zero-trust systems

Encrypted tokens

HPKE i Cloud Security

Przykład:

Firma przechowuje dane w chmurze.

Zamiast:

Cloud Provider
      |
      v
Plain Data

może być:

Application
      |
      v
HPKE Encryption
      |
      v
Cloud Storage

Dostawca chmury widzi:

Ciphertext

a nie:

Sensitive Data

HPKE i Zero Trust

W modelu Zero Trust:

Never Trust
Always Verify

HPKE może pomóc zabezpieczać:

• komunikację między usługami,
• dane między mikroserwisami,
• wymianę sekretów.

Przykład:

Service A

    |
    | HPKE
    v

Service B

HPKE i Kubernetes

Przykład architektury:

Application Pod
        |
        |
      HPKE
        |
        v
Encrypted Secret
        |
        v
Another Service

Może być wykorzystywany do ochrony danych aplikacyjnych między usługami.

HPKE a Post-Quantum Cryptography

To bardzo interesujący temat.

Obecne HPKE często bazuje na:

X25519

czyli klasycznej kryptografii.

Ale przyszłość może wyglądać tak:

              HPKE

                |
       +--------+--------+
       |                 |
    X25519             ML-KEM
       |                 |
       +--------+--------+
                |
              Hybrid
                |
                v
          AEAD Encryption

Czyli:

Classical KEM
+
Post Quantum KEM

HPKE a ML-KEM

ML-KEM (wcześniej znany jako CRYSTALS-Kyber) jest mechanizmem post-quantum key encapsulation.

Porównanie:

HPKE w całej architekturze kryptograficznej

Połączmy wszystkie wcześniejsze elementy:

                    SECURE COMMUNICATION

                            |
          +-----------------+-----------------+
          |                                   |
    Identity / Signing                 Key Exchange
          |                                   |
       Ed25519                            X25519
          |                                   |
          +-----------------+-----------------+
                            |
                         HPKE
                            |
              +-------------+-------------+
              |                           |
             KDF                         AEAD
              |                           |
            HKDF              AES-GCM / ChaCha20
              |                           |
              +-------------+-------------+
                            |
                    Encrypted Data

Najważniejsze do zapamiętania

Ed25519
→ podpis cyfrowy
→ "kto podpisał?"

X25519
→ wymiana klucza
→ "jak uzyskać wspólny sekret?"

HPKE
→ kompletny schemat szyfrowania kluczem publicznym

AES-GCM
→ szyfrowanie + uwierzytelnienie

ChaCha20-Poly1305
→ szyfrowanie + uwierzytelnienie

HPKE jest więc brakującym elementem pomiędzy samą wymianą klucza (X25519) a szyfrowaniem danych (AES-GCM/ChaCha20-Poly1305). To nowoczesny sposób budowania bezpiecznych systemów, w których pojedyncze wiadomości lub obiekty mogą być szyfrowane niezależnie od istniejącego połączenia sieciowego.

Polecane wpisy

Zarządzanie kluczami kryptograficznymi: najlepsze praktyki i wyzwania

🔐 Zarządzanie kluczami kryptograficznymi: najlepsze praktyki i wyzwania W dzisiejszym świecie cyfrowym, bezpieczeństwo danych jest priorytetem. Jednym z kluczowych elementów Czytaj dalej

Szyfrowanie oparte na tożsamości (Identity-Based Encryption – IBE): uproszczone zarządzanie kluczami

🔐 Szyfrowanie oparte na tożsamości (Identity-Based Encryption - IBE): uproszczone zarządzanie kluczami W świecie rosnącej liczby zagrożeń i złożoności systemów Czytaj dalej