यह अनुवाद मशीन लर्निंग का उपयोग करके उत्पन्न किया गया था और 100% सटीक नहीं हो सकता है। अंग्रेज़ी संस्करण देखें

PQ Hybrid SSU2

ML-KEM का उपयोग करते हुए SSU2 ट्रांसपोर्ट प्रोटोकॉल का पोस्ट-क्वांटम हाइब्रिड वेरिएंट

Updated: 2026-03 Accurate for: 0.9.70

स्थिति

बीटा Q2 2026, रिलीज़ Q3 2026

अवलोकन

यह SSU2 ट्रांसपोर्ट प्रोटोकॉल का हाइब्रिड पोस्ट-क्वांटम वेरिएंट है, जैसा कि Proposal 169 में डिज़ाइन किया गया है। अतिरिक्त पृष्ठभूमि जानकारी के लिए उस proposal को देखें।

PQ Hybrid SSU2 केवल उसी address और port पर परिभाषित है जहाँ standard SSU2 चलता है। किसी अलग port पर, या standard SSU2 समर्थन के बिना, इसका संचालन अनुमत नहीं है, और कई वर्षों तक अनुमत नहीं होगा, जब तक कि standard SSU2 को deprecated नहीं कर दिया जाता।

यह विशिष्टता केवल उन परिवर्तनों को दस्तावेज़ीकृत करती है जो PQ Hybrid को सपोर्ट करने के लिए मानक SSU2 में आवश्यक हैं। आधारभूत कार्यान्वयन विवरण के लिए SSU2 विशिष्टता देखें।

डिज़ाइन

हम NIST FIPS 203 और 204 मानकों FIPS 203 FIPS 204 का समर्थन करते हैं, जो CRYSTALS-Kyber और CRYSTALS-Dilithium (संस्करण 3.1, 3, और पुराने) पर आधारित हैं, लेकिन उनके साथ संगत (compatible) नहीं हैं।

Key Exchange

PQ KEM केवल ephemeral keys प्रदान करता है, और Noise XK तथा IK जैसे static-key handshakes को सीधे support नहीं करता। encryption types वही हैं जो PQ Hybrid Ratchet में उपयोग की जाती हैं और इन्हें common structures document /docs/specs/common-structures/ में परिभाषित किया गया है, जैसा कि FIPS 203 में है, Hybrid types केवल X25519 के संयोजन में परिभाषित की जाती हैं।

एन्क्रिप्शन के प्रकार हैं:

TypeCodeSSU2 Version
MLKEM512_X2551953
MLKEM768_X2551964
### वैध संयोजन

नए एन्क्रिप्शन प्रकार RouterAddresses में दर्शाए जाते हैं। key certificate में एन्क्रिप्शन प्रकार type 4 ही रहेगा।

विनिर्देश

हैंडशेक पैटर्न

हैंडशेक Noise Protocol हैंडशेक पैटर्न का उपयोग करते हैं।

निम्नलिखित अक्षर मैपिंग का उपयोग किया जाता है:

  • e = एक-बार उपयोग होने वाली ephemeral key
  • s = static key
  • p = message payload
  • e1 = एक-बार उपयोग होने वाली ephemeral PQ key, Alice से Bob को भेजी गई
  • ekem1 = KEM ciphertext, Bob से Alice को भेजा गया

हाइब्रिड फॉरवर्ड सेक्रेसी (hfs) के लिए XK और IK में निम्नलिखित संशोधन Noise HFS spec की धारा 5 में निर्दिष्ट अनुसार हैं:

XK:                       XKhfs:
  <- s                      <- s
  ...                       ...
  -> e, es, p               -> e, es, e1, p
  <- e, ee, p               <- e, ee, ekem1, p
  -> s, se                  -> s, se
  <- p                      <- p
  p ->                      p ->


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

e1 पैटर्न को निम्नानुसार परिभाषित किया गया है, जैसा कि Noise HFS spec के सेक्शन 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)

ekem1 पैटर्न को निम्नानुसार परिभाषित किया गया है, जैसा कि Noise HFS spec के सेक्शन 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)

Noise Handshake KDF

अवलोकन

हाइब्रिड हैंडशेक Noise HFS spec में परिभाषित किया गया है। Alice से Bob को भेजा जाने वाला पहला संदेश, message payload से पहले e1, यानी encapsulation key को शामिल करता है। इसे एक अतिरिक्त static key के रूप में माना जाता है; Alice की ओर से इस पर EncryptAndHash() या Bob की ओर से DecryptAndHash() को कॉल करें। इसके बाद message payload को सामान्य तरीके से प्रोसेस करें।

Bob से Alice को भेजा गया दूसरा संदेश, message payload से पहले ekem1 (ciphertext) को शामिल करता है। इसे एक अतिरिक्त static key के रूप में माना जाता है; इस पर EncryptAndHash() (Bob के रूप में) या DecryptAndHash() (Alice के रूप में) को कॉल करें। इसके बाद, kem_shared_key की गणना करें और MixKey(kem_shared_key) को कॉल करें। फिर message payload को सामान्य तरीके से प्रोसेस करें।

परिभाषित ML-KEM संचालन

हम निम्नलिखित फ़ंक्शन परिभाषित करते हैं जो FIPS 203 में परिभाषित क्रिप्टोग्राफ़िक बिल्डिंग ब्लॉक्स के अनुरूप हैं।

(encap_key, decap_key) = PQ_KEYGEN()

Alice creates the encapsulation and decapsulation keys
The encapsulation key is sent in message 1.
encap_key and decap_key sizes vary based on ML-KEM variant.

(ciphertext, kem_shared_key) = ENCAPS(encap_key)

Bob calculates the ciphertext and shared key,
using the ciphertext received in message 1.
The ciphertext is sent in message 2.
ciphertext size varies based on ML-KEM variant.
The kem_shared_key is always 32 bytes.

kem_shared_key = DECAPS(ciphertext, decap_key)

Alice calculates the shared key,
using the ciphertext received in message 2.
The kem_shared_key is always 32 bytes.

ध्यान दें कि encap_key और ciphertext दोनों को Noise handshake संदेश 1 और 2 में ChaCha/Poly blocks के अंदर encrypt किया गया है। इन्हें handshake प्रक्रिया के भाग के रूप में decrypt किया जाएगा।

kem_shared_key को MixHash() के साथ chaining key में मिलाया जाता है। विवरण के लिए नीचे देखें।

संदेश 1 के लिए Alice KDF

’es’ मैसेज पैटर्न के बाद और payload से पहले, निम्नलिखित जोड़ें:

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).

Message 1 के लिए Bob KDF

’es’ मैसेज पैटर्न के बाद और payload से पहले, निम्नलिखित जोड़ें:

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).

संदेश 2 के लिए Bob KDF

XK के लिए: ’ee’ message pattern के बाद और payload से पहले, यह जोड़ें:

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 संदेश 2 के लिए

’ee’ मैसेज पैटर्न के बाद, जोड़ें:

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.

संदेश 3 के लिए KDF

अपरिवर्तित

split() के लिए KDF

अपरिवर्तित

हैंडशेक विवरण

Noise पहचानकर्ता

  • “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
  • “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”

ध्यान दें कि MLKEM-1024 SSU2 के लिए समर्थित नहीं है, क्योंकि keys एक मानक 1500 बाइट datagram में फिट होने के लिए बहुत बड़ी हैं।

Long Header

लंबा हेडर 32 बाइट्स का होता है। इसका उपयोग session बनाए जाने से पहले किया जाता है, जैसे Token Request, SessionRequest, SessionCreated, और Retry के लिए। इसका उपयोग session से बाहर के Peer Test और Hole Punch संदेशों के लिए भी किया जाता है।

निम्नलिखित संदेशों में, MLKEM-512 या MLKEM-768 को इंगित करने के लिए long header में ver (version) फ़ील्ड को 3 या 4 पर सेट करें।

  • (0) Session Request (सत्र अनुरोध)
  • (1) Session Created (सत्र निर्मित)
  • (9) Retry (पुनः प्रयास)
  • (10) Token Request (टोकन अनुरोध)
  • (11) Hole Punch (होल पंच)

निम्नलिखित संदेशों में, long header में ver (version) फ़ील्ड को 2 पर सेट करें, जैसा कि सामान्यतः होता है, भले ही MLKEM-512 या MLKEM-768 समर्थित हो। यदि दूसरा छोर इसे समर्थन करता है तो implementations इस मान को 3 या 4 पर भी सेट कर सकते हैं, लेकिन यह आवश्यक नहीं है। Implementations को 2-4 के बीच कोई भी मान स्वीकार करना चाहिए।

  • (7) Peer Test (सत्र से बाहर के संदेश 5-7)

चर्चा: सभी message types के लिए version field को 3 या 4 पर सेट करना सख्त रूप से आवश्यक नहीं हो सकता, लेकिन ऐसा करने से unsupported post-quantum connections के लिए पहले ही विफलता का पता लगाने में सहायता मिलती है। Token Request और Retry (types 9 और 10) में consistency के लिए versions 3/4 होने चाहिए। Hole Punch messages (type 11) के लिए इस treatment की आवश्यकता नहीं हो सकती, लेकिन एकरूपता के लिए हम उसी pattern का पालन करेंगे। Peer Test messages (type 7) out-of-session होते हैं और session शुरू करने के इरादे का संकेत नहीं देते।

हेडर एन्क्रिप्शन से पहले:


  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 0, 1, 7, 9, 10, or 11

  ver :: The protocol version = 2, 3, or 4 for non-PQ, MLKEM512, MLKEM768

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: 8 bytes, unsigned big endian integer

  Token :: 8 bytes, unsigned big endian integer

शॉर्ट हेडर

अपरिवर्तित

SessionRequest (प्रकार 0)

परिवर्तन: वर्तमान SSU2 में ChaCha सेक्शन में केवल block data होता है। ML-KEM के साथ, ChaCha सेक्शन में encrypted PQ public key भी शामिल होगी।

Spoof Protection के लिए KDF परिवर्तन: Proposal 165 [Prop165]_ में उठाए गए मुद्दों को हल करने के लिए, लेकिन एक अलग समाधान के साथ, हम Session Request के लिए KDF को संशोधित करते हैं। यह केवल PQ sessions के लिए है। Non-PQ sessions के लिए KDF अपरिवर्तित रहता है।


// End of KDF for initial chain key (unchanged)
  // Bob static key
  // MixHash(bpk)
  h = SHA256(h || bpk);

  // Start of KDF for session request
  // NEW for PQ only
  // bhash = Bob router hash (32 bytes)
  // MixHash(bhash)
  h = SHA256(h || bhash);

  // Rest of KDF for session request, unchanged, as in SSU2 spec
  // MixHash(header)
  h = SHA256(h || header)

  ...

कच्ची सामग्री:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |    See Header Encryption KDF          |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key n=0     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X, ChaCha20 encrypted           +
  |       with Bob intro key n=0          |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (MLKEM)     |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (payload)   |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

अनएन्क्रिप्टेड डेटा (Poly1305 प्रमाणीकरण टैग नहीं दिखाया गया):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |     see below for allowed blocks      |
  +----+----+----+----+----+----+----+----+

आकार, IP ओवरहेड को छोड़कर:

TypeType CodeX lenMsg 1 lenMsg 1 Enc lenMsg 1 Dec lenPQ key lenpl len
X2551943280+pl16+plpl–pl
MLKEM512_X25519532896+pl832+pl800+pl800pl
MLKEM768_X255196321280+pl1216+pl1184+pl1184pl
MLKEM1024_X255197n/atoo big
नोट: Type codes केवल आंतरिक उपयोग के लिए हैं। Routers type 4 ही रहेंगे, और समर्थन router addresses में इंगित किया जाएगा।

MLKEM768_X25519 के लिए न्यूनतम MTU: IPv4 के लिए 1318 और IPv6 के लिए 1338। नीचे देखें।

SessionCreated (प्रकार 1)

परिवर्तन: वर्तमान SSU2 में ChaCha सेक्शन में केवल block data होता है। ML-KEM के साथ, ChaCha सेक्शन में encrypted PQ public key भी शामिल होगी।

कच्ची सामग्री:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with derived key n=0       +
  |  See Header Encryption KDF            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       Y, ChaCha20 encrypted           +
  |       with derived key n=0            |
  +              (32 bytes)               +
  |       See Header Encryption KDF       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data (MLKEM)               |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data (payload)             |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

अनएन्क्रिप्टेड डेटा (Poly1305 auth tag नहीं दिखाया गया):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |      see below for allowed blocks     |
  +----+----+----+----+----+----+----+----+

आकार, IP ओवरहेड को छोड़कर:

TypeType CodeY lenMsg 2 lenMsg 2 Enc lenMsg 2 Dec lenPQ CT lenpl len
X2551943280+pl16+plpl–pl
MLKEM512_X25519532864+pl800+pl768+pl768pl
MLKEM768_X255196321184+pl1118+pl1088+pl1088pl
MLKEM1024_X255197n/atoo big
नोट: Type codes केवल आंतरिक उपयोग के लिए हैं। Routers type 4 ही रहेंगे, और समर्थन router addresses में इंगित किया जाएगा।

MLKEM768_X25519 के लिए न्यूनतम MTU: IPv4 के लिए 1318 और IPv6 के लिए 1338। नीचे देखें।

SessionConfirmed (टाइप 2)

अपरिवर्तित

डेटा चरण के लिए KDF

अपरिवर्तित

Relay और Peer Test

निम्नलिखित ब्लॉक में version फ़ील्ड हैं। ये version 2 पर ही रहेंगे (non-PQ Bob के साथ compatibility बनाए रखने के लिए), और PQ के लिए version 3/4 में नहीं बदलेंगे।

  • Relay Request
  • Relay Response
  • Relay Intro
  • Peer Test

PQ Signatures: Relay blocks, Peer Test blocks, और Peer Test messages सभी में signatures होते हैं। दुर्भाग्यवश, PQ signatures MTU से बड़े होते हैं। वर्तमान में Relay या Peer Test blocks या messages को एकाधिक UDP packets में fragment करने का कोई तंत्र उपलब्ध नहीं है। Protocol को fragmentation के समर्थन के लिए विस्तारित करना होगा। यह एक अलग proposal (प्रस्ताव) में किया जाएगा जो अभी निर्धारित किया जाना है। जब तक यह पूरा नहीं हो जाता, Relay और Peer Test समर्थित नहीं होंगे।

प्रकाशित पते

सभी मामलों में, SSU2 transport का नाम सामान्य रूप से उपयोग करें। MLKEM-1024 समर्थित नहीं है।

non-PQ, non-firewalled के समान address/port का उपयोग करें। एक या दोनों PQ variants समर्थित हैं। router address में, v=2 (सामान्य की तरह) और नया parameter pq=[3|4|3,4|4,3] प्रकाशित करें जो MLKEM 512/768/दोनों को इंगित करता है। जिन routers का MTU नीचे निर्दिष्ट न्यूनतम से कम है, उन्हें “4” युक्त “pq” parameter प्रकाशित नहीं करना चाहिए। MLKEM-768 की प्राथमिकता दर्शाने के लिए 4,3 और MLKEM-512 की प्राथमिकता दर्शाने के लिए 3,4 प्रकाशित करें। वास्तविक version initiator (कनेक्शन शुरू करने वाला) पर निर्भर है, और प्राथमिकता का पालन नहीं भी किया जा सकता है। जिन routers का MTU नीचे निर्दिष्ट न्यूनतम से कम है, उन्हें MLKEM768 का उपयोग करके कनेक्ट नहीं करना चाहिए। पुराने routers pq parameter को अनदेखा करेंगे और सामान्य की तरह non-pq के रूप में कनेक्ट होंगे।

अलग address/port का non-PQ की तरह उपयोग, या PQ-only, non-firewalled समर्थित नहीं है। इसे तब तक लागू नहीं किया जाएगा जब तक non-PQ SSU2 को अक्षम नहीं किया जाता, जो अभी से कई वर्ष दूर है। जब non-PQ अक्षम हो जाएगा, तब एक या दोनों PQ variants समर्थित होंगे। Router address में, MLKEM 512/768/दोनों को इंगित करने के लिए v=[3|4|3,4|4,3] प्रकाशित करें। पुराने routers v parameter की जांच करेंगे और इस address को असमर्थित मानकर छोड़ देंगे।

Firewalled पते (कोई IP प्रकाशित नहीं): router address में, v=2 प्रकाशित करें (सामान्य रूप से)। relay को सपोर्ट करने के लिए, firewalled पतों में pq parameter अवश्य प्रकाशित किया जाना चाहिए।

Alice किसी PQ Bob से जुड़ने के लिए उस PQ variant का उपयोग कर सकती है जिसे Bob प्रकाशित करता है, चाहे Alice अपनी router info में pq support का विज्ञापन करे या न करे, या चाहे वह समान variant का विज्ञापन करे या न करे।

MTU

MLKEM768 के साथ MTU (Maximum Transmission Unit) से अधिक न होने का ध्यान रखें। IPv4 के लिए MLKEM768_X25519 का न्यूनतम MTU 1318 है और IPv6 के लिए 1338 है (यह मानते हुए कि DateTime और Padding या RelayTagRequest block के साथ न्यूनतम payload 10 bytes है)। SSU2 के लिए सामान्यतः न्यूनतम MTU 1280 है, इसलिए सभी peers MLKEM768 का उपयोग नहीं कर सकते। यदि वास्तविक MTU न्यूनतम से कम है — चाहे स्थानीय रूप से हो या peer द्वारा advertised हो — तो MLKEM768 को publish या उपयोग न करें। इस बात का ध्यान रखें कि padding का आकार इतना न हो कि message 1 या 2 स्थानीय या remote MTU से अधिक हो जाए।

ओवरहेड विश्लेषण

Key Exchange

आकार वृद्धि (बाइट्स):

TypePubkey (Msg 1)Ciphertext (Msg 2)
MLKEM512_X25519+816+784
MLKEM768_X25519+1200+1104
## सुरक्षा विश्लेषण

NIST सुरक्षा श्रेणियों का सारांश NIST presentation के स्लाइड 10 में दिया गया है। प्रारंभिक मानदंड: hybrid protocols के लिए हमारी न्यूनतम NIST सुरक्षा श्रेणी 2 और PQ-only के लिए 3 होनी चाहिए।

CategoryAs Secure As
1AES128
2SHA256
3AES192
4SHA384
5AES256
### हैंडशेक

ये सभी हाइब्रिड प्रोटोकॉल हैं। कार्यान्वयन को MLKEM768 को प्राथमिकता देनी चाहिए; MLKEM512 पर्याप्त रूप से सुरक्षित नहीं है।

NIST सुरक्षा श्रेणियाँ FIPS 203 :

AlgorithmSecurity Category
MLKEM5121
MLKEM7683
## कार्यान्वयन नोट्स

लाइब्रेरी समर्थन

Bouncycastle, BoringSSL, और WolfSSL लाइब्रेरी अब MLKEM और MLDSA को सपोर्ट करती हैं। OpenSSL का सपोर्ट उनके 3.5 रिलीज़ में 8 अप्रैल, 2025 को आएगा OpenSSL ।

इनबाउंड ट्रैफ़िक पहचान

हम session request में ephemeral key का MSB (key[31] & 0x80) सेट करते हैं ताकि यह इंगित किया जा सके कि यह एक hybrid connection है। इससे हम एक ही port पर standard NTCP और hybrid NTCP दोनों चला सकते हैं। inbound के लिए केवल एक hybrid variant समर्थित है, और इसे router address में advertise किया जाता है। उदाहरण के लिए, pq=3 या pq=4।

अस्पष्टीकरण (Obfuscation)

Alice के रूप में, एक PQ कनेक्शन के लिए, obfuscation से पहले, X[31] |= 0x80 सेट करें। इससे X एक अमान्य X25519 public key बन जाती है। Obfuscation के बाद, AES-CBC इसे randomize कर देगा। Obfuscation के बाद X का MSB (Most Significant Bit) random होगा।

Bob के रूप में, de-obfuscation के बाद जाँचें कि (X[31] & 0x80) != 0 है या नहीं। यदि हाँ, तो यह एक PQ कनेक्शन है।

NTCP2-PQ के लिए आवश्यक न्यूनतम router संस्करण TBD है।

नोट: Type codes केवल आंतरिक उपयोग के लिए हैं। Routers type 4 ही रहेंगे, और समर्थन router addresses में इंगित किया जाएगा।

Router संगतता

Transport Names

सभी मामलों में, NTCP2 transport नाम का उपयोग सामान्य रूप से करें। पुराने router pq पैरामीटर को अनदेखा कर देंगे और सामान्य रूप से standard NTCP2 के साथ कनेक्ट होंगे।

संदर्भ

Was this page helpful?