PQ Hybrid ECIES-X25519-AEAD-Ratchet

Poznámka

Implementace, testování a nasazování probíhá v různých implementacích routeru. Zkontrolujte dokumentaci těchto implementací pro aktuální stav.

Přehled

Toto je PQ Hybrid varianta protokolu ECIES-X25519-AEAD-Ratchet ECIES . Je to první fáze celkového PQ návrhu Prop169 , která byla schválena. Podívejte se na tento návrh pro celkové cíle, modely hrozeb, analýzu, alternativy a další informace.

Tato specifikace obsahuje pouze rozdíly oproti standardnímu ECIES a musí být čtena ve spojení s touto specifikací.

Návrh

Používáme standard NIST FIPS 203 FIPS203 , který je založen na algoritmu CRYSTALS-Kyber (verze 3.1, 3 a starší), ale není s ním kompatibilní.

Hybrid handshakes jsou specifikovány v Noise-Hybrid .

Výměna klíčů

Definujeme hybridní výměnu klíčů pro Ratchet. PQ KEM poskytuje pouze dočasné klíče a přímo nepodporuje handshaky se statickými klíči, jako je Noise IK.

Definujeme tři varianty ML-KEM podle FIPS203 , celkem pro 3 nové typy šifrování. Hybridní typy jsou definovány pouze v kombinaci s X25519.

Nové typy šifrování jsou:

Nová kryptografie vyžadována

• ML-KEM (dříve CRYSTALS-Kyber) FIPS203
• SHA3-128 (dříve Keccak-256) FIPS202 Používá se pouze pro SHAKE128
• SHA3-256 (dříve Keccak-512) FIPS202
• SHAKE128 a SHAKE256 (XOF rozšíření pro SHA3-128 a SHA3-256) FIPS202

Testovací vektory pro SHA3-256, SHAKE128 a SHAKE256 jsou dostupné na NIST-VECTORS .

Všimněte si, že Java knihovna bouncycastle podporuje vše výše uvedené. Podpora C++ knihovny je v OpenSSL 3.5 OPENSSL .

Specifikace

Běžné struktury

Viz specifikaci běžných struktur COMMON pro délky klíčů a identifikátory.

Vzory handshake

Handshaky používají Noise handshake vzory.

Používá se následující mapování písmen:

• e = jednorázový dočasný klíč
• s = statický klíč
• p = datová část zprávy
• e1 = jednorázový dočasný PQ klíč, odeslaný od Alice k Bobovi
• ekem1 = šifrovaný text KEM, odeslaný od Boba k Alice

Následující úpravy XK a IK pro hybridní dopřednou bezpečnost (hfs) jsou specifikovány v Noise-Hybrid sekci 5:

IK:                         IKhfs:
<- s                        <- s
...                         ...
-> e, es, s, ss, p          -> e, es, e1, s, ss, p
<- tag, e, ee, se, p        <- tag, e, ee, ekem1, se, p
<- p                        <- p
p ->                        p ->

e1 and ekem1 are encrypted. See pattern definitions below.
NOTE: e1 and ekem1 are different sizes (unlike X25519)

Vzor e1 je definován následovně, jak je specifikováno v Noise-Hybrid sekci 4:

For Alice:
    (encap_key, decap_key) = PQ_KEYGEN()

    // EncryptAndHash(encap_key)
    ciphertext = ENCRYPT(k, n, encap_key, ad)
    n++
    MixHash(ciphertext)

For Bob:
    // DecryptAndHash(ciphertext)
    encap_key = DECRYPT(k, n, ciphertext, ad)
    n++
    MixHash(ciphertext)

Vzor ekem1 je definován následovně, jak je specifikováno v Noise-Hybrid sekci 4:

For Bob:
    (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

    // EncryptAndHash(kem_ciphertext)
    ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)
    MixHash(ciphertext)

    // MixKey
    MixKey(kem_shared_key)

For Alice:
    // DecryptAndHash(ciphertext)
    kem_ciphertext = DECRYPT(k, n, ciphertext, ad)
    MixHash(ciphertext)

    // MixKey
    kem_shared_key = DECAPS(kem_ciphertext, decap_key)
    MixKey(kem_shared_key)

Definované operace ML-KEM

Definujeme následující funkce odpovídající kryptografickým stavebním blokům použitým podle definice v FIPS203 .

(encap_key, decap_key) = PQ_KEYGEN()

Alice vytvoří klíče pro enkapsulaci a dekapsulaci. Klíč pro enkapsulaci je odeslán ve zprávě NS. Velikosti encap_key a decap_key se liší podle varianty ML-KEM.

(ciphertext, kem_shared_key) = ENCAPS(encap_key)

Bob vypočítá šifrový text a sdílený klíč pomocí šifrového textu přijatého v NS zprávě. Šifrový text je odeslán v NSR zprávě. Velikost šifrového textu se liší podle varianty ML-KEM. kem_shared_key má vždy 32 bytů.

kem_shared_key = DECAPS(ciphertext, decap_key)

Alice vypočítá sdílený klíč pomocí šifrovaného textu přijatého v NSR zprávě. Kem_shared_key je vždy 32 bajtů.

Všimněte si, že jak encap_key, tak ciphertext jsou šifrovány uvnitř ChaCha/Poly bloků v Noise handshake zprávách 1 a 2. Budou dešifrovány jako součást procesu handshake.

Hodnota kem_shared_key je smíchána do chaining key pomocí MixHash(). Podrobnosti viz níže.

Noise Handshake KDF

Přehled

Hybridní handshake je definován v Noise-Hybrid . První zpráva, od Alice k Bobovi, obsahuje e1, enkapsulační klíč, před užitečným obsahem zprávy. Tento je zpracován jako dodatečný statický klíč; zavolejte na něj EncryptAndHash() (jako Alice) nebo DecryptAndHash() (jako Bob). Poté zpracujte užitečný obsah zprávy jako obvykle.

Druhá zpráva, od Boba k Alici, obsahuje ekem1, šifrovaný text, před payload zprávy. To je považováno za dodatečný statický klíč; zavolejte na něj EncryptAndHash() (jako Bob) nebo DecryptAndHash() (jako Alice). Poté vypočítejte kem_shared_key a zavolejte MixKey(kem_shared_key). Poté zpracujte payload zprávy obvyklým způsobem.

Identifikátory Noise

Toto jsou Noise inicializační řetězce:

• “Noise_IKhfselg2_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM1024_ChaChaPoly_SHA256”

Alice KDF pro NS zprávu

Po vzoru zprávy ’es’ a před vzorem zprávy ’s’ přidejte:

This is the "e1" message pattern:

    (encap_key, decap_key) = PQ_KEYGEN()

    // EncryptAndHash(encap_key)
    // AEAD parameters
    k = keydata[32:63]
    n = 0
    ad = h
    ciphertext = ENCRYPT(k, n, encap_key, ad)
    n++

    // MixHash(ciphertext)
    h = SHA256(h || ciphertext)

End of "e1" message pattern.

NOTE: For the next section (payload for XK or static key for IK),
the keydata and chain key remain the same, and n now equals 1
(instead of 0 for non-hybrid).

Bob KDF pro NS zprávu

Po vzoru zprávy ’es’ a před vzorem zprávy ’s’ přidejte:

This is the "e1" message pattern:

    // DecryptAndHash(encap_key_section)
    // AEAD parameters
    k = keydata[32:63]
    n = 0
    ad = h
    encap_key = DECRYPT(k, n, encap_key_section, ad)
    n++

    // MixHash(encap_key_section)
    h = SHA256(h || encap_key_section)

End of "e1" message pattern.

NOTE: For the next section (payload for XK or static key for IK),
the keydata and chain key remain the same, and n now equals 1
(instead of 0 for non-hybrid).

Bob KDF pro NSR zprávu

Po vzoru zprávy ’ee’ a před vzorem zprávy ‘se’ přidejte:

This is the "ekem1" message pattern:

    (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

    // EncryptAndHash(kem_ciphertext)
    // AEAD parameters
    k = keydata[32:63]
    n = 0
    ad = h
    ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)

    // MixHash(ciphertext)
    h = SHA256(h || ciphertext)

    // MixKey(kem_shared_key)
    keydata = HKDF(chainKey, kem_shared_key, "", 64)
    chainKey = keydata[0:31]

End of "ekem1" message pattern.

Alice KDF pro NSR zprávu

Po vzoru zprávy ’ee’ a před vzorem zprávy ‘ss’ přidejte:

This is the "ekem1" message pattern:

    // DecryptAndHash(kem_ciphertext_section)
    // AEAD parameters
    k = keydata[32:63]
    n = 0
    ad = h
    kem_ciphertext = DECRYPT(k, n, kem_ciphertext_section, ad)

    // MixHash(kem_ciphertext_section)
    h = SHA256(h || kem_ciphertext_section)

    // MixKey(kem_shared_key)
    kem_shared_key = DECAPS(kem_ciphertext, decap_key)
    keydata = HKDF(chainKey, kem_shared_key, "", 64)
    chainKey = keydata[0:31]

End of "ekem1" message pattern.

KDF pro split()

nezměněno

Formát zprávy

Formát NS

Změny: Současný ratchet obsahoval statický klíč v první ChaCha sekci a payload ve druhé sekci. S ML-KEM jsou nyní tři sekce. První sekce obsahuje šifrovaný PQ veřejný klíč. Druhá sekce obsahuje statický klíč. Třetí sekce obsahuje payload.

Šifrovaný formát:

+----+----+----+----+----+----+----+----+
|                                       |
+         New Session Ephemeral         +
|            Public Key                 |
+            32 bytes                   +
|      Encoded with Elligator2          |
+----+----+----+----+----+----+----+----+
|                                       |
+         ML-KEM encap_key              +
|       ChaCha20 encrypted data         |
+   (see table below for length)        +
|                                       |
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+      (MAC) for encap_key Section      +
|              16 bytes                 |
+----+----+----+----+----+----+----+----+
|                                       |
+         X25519 Static Key             +
|       ChaCha20 encrypted data         |
+            32 bytes                   +
|                                       |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+     (MAC) for Static Key Section      +
|              16 bytes                 |
+----+----+----+----+----+----+----+----+
|                                       |
+          Payload Section              +
|       ChaCha20 encrypted data         |
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+      (MAC) for Payload Section        +
|              16 bytes                 |
+----+----+----+----+----+----+----+----+

Dešifrovaný formát:

Payload Part 1:

+----+----+----+----+----+----+----+----+
|                                       |
+         ML-KEM encap_key              +
|                                       |
+   (see table below for length)        +
|                                       |
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

Payload Part 2:

+----+----+----+----+----+----+----+----+
|                                       |
+         X25519 Static Key             +
|            (32 bytes)                 |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

Payload Part 3:

+----+----+----+----+----+----+----+----+
|                                       |
+          Payload Section              +
|                                       |
~                                       ~
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

Velikosti:

Formát NSR

Změny: Současný ratchet má prázdný payload pro první ChaCha sekci a payload ve druhé sekci. S ML-KEM jsou nyní tři sekce. První sekce obsahuje šifrovaný PQ ciphertext. Druhá sekce má prázdný payload. Třetí sekce obsahuje payload.

Šifrovaný formát:

+----+----+----+----+----+----+----+----+
|       Session Tag 8 bytes             |
+----+----+----+----+----+----+----+----+
|                                       |
+       Ephemeral Public Key            +
|            32 bytes                   |
+      Encoded with Elligator2          +
|                                       |
+----+----+----+----+----+----+----+----+
|                                       |
+         ML-KEM ciphertext             +
|       ChaCha20 encrypted data         |
+   (see table below for length)        +
|                                       |
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+     (MAC) for ciphertext Section      +
|              16 bytes                 |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+   (MAC) for key Section (no data)     +
|              16 bytes                 |
+----+----+----+----+----+----+----+----+
|                                       |
+          Payload Section              +
|       ChaCha20 encrypted data         |
~                                       ~
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+      (MAC) for Payload Section        +
|              16 bytes                 |
+----+----+----+----+----+----+----+----+

Dešifrovaný formát:

Payload Part 1:

+----+----+----+----+----+----+----+----+
|                                       |
+         ML-KEM ciphertext             +
|                                       |
+   (see table below for length)        +
|                                       |
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

Payload Part 2:

empty

Payload Part 3:

+----+----+----+----+----+----+----+----+
|                                       |
+          Payload Section              +
|                                       |
~                                       ~
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

Velikosti:

Analýza režie

Výměna klíčů

Nárůst velikosti (bajty):

Rychlosti podle CLOUDFLARE :

Bezpečnostní kategorie NIST jsou shrnuty v NIST-PQ-END snímek 10. Předběžná kritéria: Naša minimální bezpečnostní kategorie NIST by měla být 2 pro hybridní protokoly a 3 pro pouze PQ.

Všechny tyto protokoly jsou hybridní. Pravděpodobně bude třeba upřednostnit MLKEM768; MLKEM512 není dostatečně bezpečný.

Bezpečnostní kategorie NIST FIPS203 :

Doporučený typ pro počáteční podporu, založený na kategorii zabezpečení a délce klíče, je:

MLKEM768_X25519 (typ 6)

Poznámky k implementaci

Podpora knihoven

Knihovny Bouncycastle, BoringSSL a WolfSSL nyní podporují MLKEM. Podpora OpenSSL je v jejich vydání 3.5 z 8. dubna 2025 OPENSSL .

Sdílené tunnely

Automatická klasifikace/detekce více protokolů na stejných tunelech by měla být možná na základě kontroly délky zprávy 1 (New Session Message). Použijeme-li jako příklad MLKEM512_X25519, délka zprávy 1 je o 816 bajtů větší než současný ratchet protokol a minimální velikost zprávy 1 (pouze s DateTime payload) je 919 bajtů. Většina velikostí zpráv 1 se současným ratchet má payload menší než 816 bajtů, takže mohou být klasifikovány jako non-hybrid ratchet. Velké zprávy jsou pravděpodobně POST požadavky, které jsou vzácné.

Doporučená strategie je tedy:

• Pokud je zpráva 1 menší než 919 bajtů, jedná se o aktuální ratchet protokol.
• Pokud je zpráva 1 větší nebo rovna 919 bajtům, pravděpodobně se jedná o MLKEM512_X25519. Zkuste nejprve MLKEM512_X25519, a pokud selže, zkuste aktuální ratchet protokol.

To nám umožní efektivně podporovat standardní ratchet a hybridní ratchet na stejné destinaci, stejně jako jsme dříve podporovali ElGamal a ratchet na stejné destinaci. Proto můžeme migrovat na hybridní protokol MLKEM mnohem rychleji, než kdybychom nemohli podporovat duální protokoly pro stejnou destinaci, protože můžeme přidat podporu MLKEM do existujících destinací.

Požadované podporované kombinace jsou:

• X25519 + MLKEM512
• X25519 + MLKEM768
• X25519 + MLKEM1024

Následující kombinace mohou být složité a NENÍ vyžadováno, aby byly podporovány, ale mohou být, v závislosti na implementaci:

• Více než jeden MLKEM
• ElG + jeden nebo více MLKEM
• X25519 + jeden nebo více MLKEM
• ElG + X25519 + jeden nebo více MLKEM

Není požadována podpora více MLKEM algoritmů (například MLKEM512_X25519 a MLKEM_768_X25519) na stejné destinaci. Vyberte jen jeden. Závisí na implementaci.

Není nutné podporovat tři algoritmy (například X25519, MLKEM512_X25519 a MLKEM769_X25519) na stejné destinaci. Klasifikace a strategie opakování může být příliš složitá. Konfigurace a konfigurační rozhraní může být příliš složité. Závisí na implementaci.

Není vyžadováno podporovat ElGamal a hybridní algoritmy na stejné destinaci. ElGamal je zastaralý a ElGamal + hybridní pouze (bez X25519) nedává příliš smysl. Také ElGamal a Hybrid New Session Messages jsou obě velké, takže klasifikační strategie by často musely vyzkoušet obě dešifrování, což by bylo neefektivní. Závisí na implementaci.

Klienti mohou používat stejné nebo různé statické klíče X25519 pro protokoly X25519 a hybridní protokoly na stejných tunnelech, závisí na implementaci.

Forward Secrecy

Specifikace ECIES umožňuje Garlic Messages v payloadu New Session Message, což umožňuje 0-RTT doručení počátečního streamovacího paketu, obvykle HTTP GET, společně s leaseset klienta. Nicméně payload New Session Message nemá forward secrecy. Jelikož tento návrh zdůrazňuje vylepšené forward secrecy pro ratchet, implementace mohou nebo by měly odložit zahrnutí streamovacího payloadu, nebo celé streamovací zprávy, až do první Existing Session Message. To by bylo na úkor 0-RTT doručení. Strategie mohou také záviset na typu provozu nebo typu tunelu, nebo například na GET vs. POST. Závisí na implementaci.

Velikost nové relace

MLKEM dramaticky zvětší velikost New Session Message, jak je popsáno výše. To může výrazně snížit spolehlivost doručování New Session Message skrze tunnely, kde musí být fragmentovány do několika 1024bajtových tunnel zpráv. Úspěšnost doručení je úměrná exponenciálnímu počtu fragmentů. Implementace mohou použít různé strategie pro omezení velikosti zprávy na úkor 0-RTT doručení. Závisí na implementaci.

Reference

• CLOUDFLARE
• COMMON
• ECIES
• FIPS202
• FIPS203
• FORUM
• NIST-PQ-END
• NIST-VECTORS
• Noise
• Noise-Hybrid
• OPENSSL
• PQ-WIREGUARD
• Prop169