क्वांटम के बाद के क्रिप्टो प्रोटोकॉल

स्थिति

अवलोकन

हालांकि उपयुक्त पोस्ट-क्वांटम (PQ) क्रिप्टोग्राफी के लिए एक दशक से अनुसंधान और प्रतिस्पर्धा जारी है, लेकिन विकल्प पिछले समय तक स्पष्ट नहीं हुए हैं।

हमने 2022 में पीक्यू क्रिप्टो के निहितार्थों को देखना शुरू किया zzz.i2p ।

TLS मानकों ने पिछले दो वर्षों में संकर एन्क्रिप्शन समर्थन जोड़ा है और अब Chrome और Firefox में समर्थन के कारण इंटरनेट पर एन्क्रिप्टेड ट्रैफ़िक के एक महत्वपूर्ण हिस्से में इसका उपयोग किया जा रहा है Cloudflare ।

NIST ने हाल ही में संवर्धित क्वांटम क्रिप्टोग्राफी के लिए अनुशंसित एल्गोरिदम को अंतिम रूप दे दिया है और प्रकाशित कर दिया है NIST । कई सामान्य क्रिप्टोग्राफी लाइब्रेरीज अब NIST मानकों का समर्थन करती हैं या निकट भविष्य में समर्थन जारी करने वाली हैं।

Cloudflare और NIST दोनों की सिफारिश है कि पलायन तुरंत शुरू किया जाए। 2022 के एनएसए पीक्यू एफएक्यू NSA भी देखें। आई2पी सुरक्षा और क्रिप्टोग्राफी में अग्रणी होना चाहिए। अब अनुशंसित एल्गोरिदम को लागू करने का समय है। हमारे लचीले क्रिप्टो टाइप और हस्ताक्षर प्रकार प्रणाली का उपयोग करके, हम हाइब्रिड क्रिप्टो और पीक्यू तथा हाइब्रिड हस्ताक्षरों के लिए प्रकार जोड़ेंगे।

लक्ष्य

• पीक्यू-प्रतिरोधी एल्गोरिदम का चयन करें
• उपयुक्त होने पर I2P प्रोटोकॉल में केवल पीक्यू और संकर एल्गोरिदम जोड़ें
• कई विविधताओं को परिभाषित करें
• लागू करने, परीक्षण, विश्लेषण और अनुसंधान के बाद सर्वश्रेष्ठ विविधताओं का चयन करें
• वृद्धि द्वारा और पिछड़ी संगतता के साथ समर्थन जोड़ें

गैर-लक्ष्य

• एक-तरफ़ा (नॉइज़ N) एन्क्रिप्शन प्रोटोकॉल न बदलें
• SHA256 से दूर न जाएँ, क्वांटम कंप्यूटिंग (PQ) द्वारा अल्पकालिक खतरा नहीं
• अभी अंतिम पसंदीदा विविधताओं का चयन न करें

खतरे का मॉडल

• OBEP या IBGW पर राउटर, जो संभवतः षड्यंत्र रच रहे हैं, भविष्य में डिक्रिप्ट करने के लिए गैरिक संदेशों को संग्रहीत करना (फॉरवर्ड सीक्रेसी)
• नेटवर्क निरीक्षक भविष्य में डिक्रिप्ट करने के लिए परिवहन संदेशों को संग्रहीत करना (फॉरवर्ड सीक्रेसी)
• नेटवर्क भागीदार RI, LS, स्ट्रीमिंग, डेटाग्राम, या अन्य संरचनाओं के लिए हस्ताक्षर बनाना

प्रभावित प्रोटोकॉल

हम निम्नलिखित प्रोटोकॉल में संशोधन करेंगे, लगभग विकास के क्रम में। समग्र तदर्थ (रोलआउट) अंतिम 2025 से मध्य 2027 तक होने की संभावना है। विवरण के लिए नीचे प्राथमिकताएँ और तदर्थ (रोलआउट) अनुभाग देखें।

डिजाइन

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

कुंजी विनिमय

हम निम्नलिखित प्रोटोकॉल में हाइब्रिड कुंजी विनिमय का समर्थन करेंगे:

नॉइज़ N द्वि-आयामी कुंजी विनिमय का उपयोग नहीं करता है और इसलिए यह संकर एन्क्रिप्शन के लिए उपयुक्त नहीं है।

इसलिए हम केवल संकर एन्क्रिप्शन का समर्थन करेंगे, एनटीसीपी2, एसएसयू2 और रैचेट के लिए। हम FIPS 203 के अनुसार तीन नए एन्क्रिप्शन प्रकारों के लिए तीन एमएल-केईएम विविधताओं को परिभाषित करेंगे। संकर प्रकारों को केवल एक्स25519 के संयोजन में परिभाषित किया जाएगा।

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

हस्ताक्षर

नोट: एमएलडीएसए हस्ताक्षरों से संबंधित इस प्रस्ताव में दी गई सभी जानकारी प्रारंभिक है। मानक निकायों द्वारा एल्गोरिदम के चयन, संभवतः कुंजी और/या हस्ताक्षर आकार में कमी और उद्योग में अपनाने को बढ़ावा देने के लिए कार्य पूरा होने तक 2027 के अंत या 2028 तक आई2पी में एमएलडीएसए हस्ताक्षर समर्थन पर कार्य रोक दिया गया है। CABFORUM और PLANTS देखें।

हम निम्नलिखित संरचनाओं में PQ और हाइब्रिड हस्ताक्षरों का समर्थन करेंगे:

हम FIPS 204 खंड 3.4 में परिभाषित “निर्धारक” (deterministic) वैरिएंट के बजाय “हेज्ड” या यादृच्छिक हस्ताक्षर वैरिएंट का उपयोग करेंगे। इससे यह सुनिश्चित होता है कि प्रत्येक हस्ताक्षर भले ही एक ही डेटा पर लगाया गया हो, अलग-अलग होगा, और साइड-चैनल हमलों के खिलाफ अतिरिक्त सुरक्षा प्रदान करता है। एन्कोडिंग और संदर्भ सहित एल्गोरिदम चुनाव के बारे में अतिरिक्त जानकारी के लिए नीचे कार्यान्वयन टिप्पणियों के अनुभाग देखें।

नए हस्ताक्षर प्रकार हैं:

ओवरहेड काफी अधिक होगा। विशिष्ट Ed25519 गंतव्य और राउटर पहचान आकार 391 बाइट्स होते हैं। ये एल्गोरिदम के आधार पर 3.5 गुना से 6.8 गुना तक बढ़ जाएंगे। Ed25519 हस्ताक्षर 64 बाइट्स के होते हैं। ये एल्गोरिदम के आधार पर 38 गुना से 76 गुना तक बढ़ जाएंगे। विशिष्ट हस्ताक्षरित RouterInfo, LeaseSet, प्रतिक्रियायोग्य डेटाग्राम और हस्ताक्षरित स्ट्रीमिंग संदेश लगभग 1KB के होते हैं। ये एल्गोरिदम के आधार पर 3 गुना से 8 गुना तक बढ़ जाएंगे।

चूंकि नए गंतव्य और राउटर पहचान प्रकारों में पैडिंग नहीं होगी, इसलिए उन्हें संपीड़ित नहीं किया जा सकेगा। गंतव्यों और राउटर पहचानों के आकार जो ट्रांज़िट में gzip किए गए हैं, एल्गोरिदम के आधार पर 12x से 38x तक बढ़ जाएंगे।

कानूनी संयोजन

गंतव्यों के लिए, लीजसेट में सभी एन्क्रिप्शन प्रकारों के साथ नए हस्ताक्षर प्रकार समर्थित हैं। कुंजी प्रमाणपत्र में एन्क्रिप्शन प्रकार को NONE (255) पर सेट करें।

राउटर पहचानों के लिए, एल-गामल एन्क्रिप्शन प्रकार को अप्रचलित घोषित कर दिया गया है। नए हस्ताक्षर प्रकार केवल X25519 (प्रकार 4) एन्क्रिप्शन के साथ समर्थित हैं। नए एन्क्रिप्शन प्रकार राउटर पतों में दर्शाए जाएंगे। कुंजी प्रमाणपत्र में एन्क्रिप्शन प्रकार अब भी प्रकार 4 ही रहेगा।

नई क्रिप्टो आवश्यक है

• एमएल-केईएम (पूर्व में सीआरवाईएस्टल्स-काइबर) FIPS 203
• एमएल-डीएसए (पूर्व में सीआरवाईएस्टल्स-डिलिथियम) FIPS 204
• एसएचए3-128 (पूर्व में केकाक-256) FIPS 202 केवल SHAKE128 के लिए उपयोग किया जाता है
• एसएचए3-256 (पूर्व में केकाक-512) FIPS 202
• SHAKE128 और SHAKE256 (SHA3-128 और SHA3-256 के एक्सओएफ एक्सटेंशन) FIPS 202

SHA3-256, SHAKE128, और SHAKE256 के लिए परीक्षण वैक्टर NIST पर उपलब्ध हैं।

ध्यान दें कि जावा बाउंसीकैसल लाइब्रेरी उपरोक्त सभी को समर्थन करती है। सी++ लाइब्रेरी समर्थन OpenSSL 3.5 में है OpenSSL ।

विकल्प

हम FIPS 205 (Sphincs+) का समर्थन नहीं करेंगे, यह ML-DSA की तुलना में बहुत धीमा और बड़ा है। हम आगामी FIPS206 (Falcon) का समर्थन नहीं करेंगे, क्योंकि यह अभी तक मानकीकृत नहीं हुआ है। हम NTRU या अन्य PQ उम्मीदवारों का समर्थन नहीं करेंगे जिन्हें NIST द्वारा मानकीकृत नहीं किया गया है।

Rosenpass

Wireguard (IK) को शुद्ध PQ क्रिप्टो के लिए अनुकूलित करने पर कुछ शोध पेपर उपलब्ध हैं, लेकिन उस पेपर में कई खुले प्रश्न हैं। बाद में, PQ Wireguard के लिए इस दृष्टिकोण को रोजेनपास के रूप में लागू किया गया Rosenpass व्हाइटपेपर ।

रोजेनपास क्लासिक मैकेलीस 460896 स्टेटिक कुंजियों (प्रत्येक 500 KB) और काइबर-512 (अर्थात एमएलकेईएम-512) अस्थायी कुंजियों के साथ एक नॉइज़ केके-जैसे हैंडशेक का उपयोग करता है। चूंकि क्लासिक मैकेलीस साइफरटेक्स्ट केवल 188 बाइट्स के होते हैं, और काइबर-512 की सार्वजनिक कुंजियाँ तथा साइफरटेक्स्ट उचित आकार के होते हैं, इसलिए दोनों हैंडशेक संदेश एक मानक UDP MTU में फिट हो जाते हैं। शुद्ध गुणन (PQ) केके हैंडशेक से प्राप्त आउटपुट साझा कुंजी (osk) का उपयोग मानक वायरगार्ड आईके हैंडशेक के लिए इनपुट पूर्वसाझाकृत कुंजी (psk) के रूप में किया जाता है। इस प्रकार कुल मिलाकर दो पूर्ण हैंडशेक होते हैं, एक शुद्ध शुद्ध गुणन (PQ) और एक शुद्ध X25519।

हम अपने XK और IK हैंडशेक को बदलने के लिए इनमें से कुछ भी नहीं कर सकते क्योंकि:

• हम KK नहीं कर सकते, बॉब के पास एलिस की स्थिर कुंजी नहीं है
• 500KB की स्थिर कुंजियाँ बहुत अधिक बड़ी हैं
• हम एक अतिरिक्त चक्र नहीं चाहते

सफेदपत्र में बहुत अच्छी जानकारी है, और हम विचारों और प्रेरणा के लिए इसकी समीक्षा करेंगे। करना है।

विशिष्टता

सामान्य संरचनाएं

आम संरचनाओं दस्तावेज़ /docs/specs/common-structures/ में खंडों और तालिकाओं को निम्नानुसार अपडेट करें:

सार्वजनिक कुंजी

नए पब्लिक कुंजी प्रकार हैं:

MLKEM*_CT कुंजियाँ वास्तव में सार्वजनिक कुंजियाँ नहीं हैं, वे “साइफरटेक्स्ट” हैं जो नॉइज़ हैंडशेक में बॉब से एलिस को भेजे जाते हैं। पूर्णता के लिए यहाँ इनका समावेश किया गया है।

निजी कुंजी

नए निजी कुंजी प्रकार हैं:

SigningPublicKey

नए साइनिंग पब्लिक की प्रकार हैं:

साइनिंगनिजीकुंजी

नए साइनिंग निजी कुंजी प्रकार हैं:

हस्ताक्षर

नए हस्ताक्षर प्रकार हैं:

मुख्य प्रमाणपत्र

नए साइनिंग पब्लिक की प्रकार हैं:

हाइब्रिड या पीक्यू हस्ताक्षर प्रकार वाले गंतव्यों के लिए, एन्क्रिप्शन प्रकार के लिए NONE (प्रकार 255) का उपयोग करें, लेकिन कोई क्रिप्टो कुंजी नहीं होती है, और 384-बाइट का पूरा मुख्य खंड हस्ताक्षर कुंजी के लिए होता है।

गंतव्य आकार

यहाँ नए डिस्टिनेशन प्रकारों की लंबाई दी गई है। सभी के लिए एन्क्रिप्शन प्रकार NONE (प्रकार 255) है और एन्क्रिप्शन कुंजी की लंबाई को 0 माना जाता है। हस्ताक्षर सार्वजनिक कुंजी के पहले भाग के लिए पूरे 384-बाइट खंड का उपयोग किया जाता है। नोट: यह ECDSA_SHA512_P521 और RSA हस्ताक्षर प्रकारों के लिए विनिर्देश से अलग है, जहां हमने डिस्टिनेशन में 256-बाइट एल-गामल कुंजी को बनाए रखा था, भले ही यह उपयोग में न हो।

कोई पैडिंग नहीं। कुल लंबाई 7 + कुल कुंजी लंबाई है। कुंजी प्रमाणपत्र की लंबाई 4 + अतिरिक्त कुंजी लंबाई है।

MLDSA44 के लिए 1319-बाइट गंतव्य बाइट स्ट्रीम का उदाहरण:

skey[0:383] 5 (932 » 8) (932 & 0xff) 00 12 00 255 skey[384:1311]

राउटर आइडेंट के आकार

यहाँ नए Destination प्रकारों की लंबाई दी गई है। सभी के लिए एन्क्रिप्शन प्रकार X25519 (प्रकार 4) है। X28819 सार्वजनिक कुंजी के बाद के 352-बाइट अनुभाग का उपयोग हस्ताक्षर सार्वजनिक कुंजी के पहले भाग के लिए किया जाता है। कोई पैडिंग नहीं। कुल लंबाई 39 + कुल कुंजी लंबाई है। कुंजी प्रमाणपत्र की लंबाई 4 + अतिरिक्त कुंजी लंबाई है।

MLDSA44 के लिए 1351-बाइट राउटर पहचान बाइट स्ट्रीम का उदाहरण:

enckey[0:31] skey[0:351] 5 (960 » 8) (960 & 0xff) 00 12 00 4 skey[352:1311]

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

हैंडशेक नॉइज़ प्रोटोकॉल हैंडशेक पैटर्न का उपयोग करते हैं।

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

• e = एक बार का अस्थायी कुंजी (one-time ephemeral key)
• s = स्थिर कुंजी (static key)
• p = संदेश भार (message payload)
• e1 = एक बार का अस्थायी PQ कुंजी, एलिस द्वारा बॉब को भेजा गया
• ekem1 = KEM संदिग्धलेख (ciphertext), बॉब द्वारा एलिस को भेजा गया

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

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


  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)

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)

नॉइज़ हैंडशेक KDF

मुद्दे

• क्या हमें 0-RTT रैचेट डेटा (LS के अलावा) भेजना बंद कर देना चाहिए?
• क्या हमें 0-RTT डेटा न भेजने पर रैचेट को IK से XK में स्विच कर देना चाहिए?

अवलोकन

यह खंड IK और XK दोनों प्रोटोकॉल पर लागू होता है।

हाइब्रिड हैंडशेक को नॉइज़ एचएफएस स्पेक में परिभाषित किया गया है। पहला संदेश, एलिस से बॉब की ओर, संदेश पेलोड से पहले e1, एनकैप्सूलेशन कुंजी, को शामिल करता है। इसे एक अतिरिक्त स्थिर कुंजी के रूप में माना जाता है; इस पर EncryptAndHash() को कॉल करें (एलिस के रूप में) या DecryptAndHash() (बॉब के रूप में)। फिर सामान्य रूप से संदेश पेलोड को प्रोसेस करें।

दूसरा संदेश, बॉब से एलिस को, संदेश पेलोड से पहले ekem1, साइफरटेक्स्ट शामिल करता है। इसे एक अतिरिक्त स्थिर कुंजी के रूप में माना जाता है; इस पर EncryptAndHash() को लागू करें (बॉब के रूप में) या DecryptAndHash() (एलिस के रूप में)। फिर, kem_shared_key की गणना करें और MixKey(kem_shared_key) को कॉल करें। फिर संदेश पेलोड को सामान्य रूप से प्रोसेस करें।

परिभाषित 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.

(साइफरटेक्स्ट, 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 दोनों नॉइज़ हैंडशेक संदेशों 1 और 2 में ChaCha/Poly ब्लॉक्स के अंदर एन्क्रिप्टेड हैं। इन्हें हैंडशेक प्रक्रिया के हिस्से के रूप में डिक्रिप्ट किया जाएगा।

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

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

XK के लिए: ’es’ संदेश पैटर्न के बाद और पेलोड से पहले जोड़ें:

या

आईके के लिए: ’es’ संदेश पैटर्न के बाद और ’s’ संदेश पैटर्न से पहले, जोड़ें:

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

संदेश 1 के लिए बॉब KDF

XK के लिए: ’es’ संदेश पैटर्न के बाद और पेलोड से पहले जोड़ें:

या

आईके के लिए: ’es’ संदेश पैटर्न के बाद और ’s’ संदेश पैटर्न से पहले, जोड़ें:

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 के लिए बॉब KDF

XK के लिए: ’ee’ संदेश पैटर्न के बाद और पेलोड से पहले जोड़ें:

या

IK के लिए: ’ee’ संदेश पैटर्न के बाद और ‘se’ संदेश पैटर्न से पहले, जोड़ें:

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.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

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

’ee’ संदेश पैटर्न के बाद (और IK के लिए ‘ss’ संदेश पैटर्न से पहले), जोड़ें:

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.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

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

अपरिवर्तित

विभाजन() के लिए KDF

अपरिवर्तित

रैचेट

ECIES-Ratchet विनिर्देश को निम्नानुसार अद्यतन करें /docs/specs/ecies/ :

शोर पहचानकर्ता

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

1बी) बाइंडिंग के साथ नया सत्र प्रारूप

परिवर्तन: वर्तमान रैचेट में पहले ChaCha अनुभाग में स्थिर कुंजी और दूसरे अनुभाग में पेलोड शामिल था। ML-KEM के साथ, अब तीन अनुभाग हैं। पहले अनुभाग में एन्क्रिप्टेड PQ सार्वजनिक कुंजी है। दूसरे अनुभाग में स्थिर कुंजी है। तीसरे अनुभाग में पेलोड है।

एन्क्रिप्टेड प्रारूप:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   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                  |
  +----+----+----+----+----+----+----+----+

डिक्रिप्टेड प्रारूप:

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            +
  |                                       |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

आकार:

1g) नए सत्र उत्तर प्रारूप

परिवर्तन: वर्तमान रैचेट में पहले ChaCha अनुभाग के लिए खाली पेलोड होता है, और दूसरे अनुभाग में पेलोड होता है। ML-KEM के साथ, अब तीन अनुभाग हैं। पहले अनुभाग में एन्क्रिप्टेड PQ साइफरटेक्स्ट होता है। दूसरे अनुभाग में खाली पेलोड होता है। तीसरे अनुभाग में पेलोड होता है।

एन्क्रिप्टेड प्रारूप:

  +----+----+----+----+----+----+----+----+
  |       Session Tag   8 bytes           |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Ephemeral Public Key           +
  |                                       |
  +            32 bytes                   +
  |     Encoded with Elligator2           |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  | ChaCha20 encrypted ML-KEM ciphertext  |
  +      (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                  |
  +----+----+----+----+----+----+----+----+

डिक्रिप्टेड प्रारूप:

Payload Part 1:


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

  Payload Part 2:

  empty

  Payload Part 3:

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

आकार:

NTCP2

NTCP2 विनिर्देश को इस प्रकार अद्यतन करें /docs/specs/ntcp2/ :

शोर पहचानकर्ता

• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM1024_ChaChaPoly_SHA256”

1) सत्र अनुरोध

परिवर्तन: वर्तमान NTCP2 में केवल एकल ChaCha अनुभाग में विकल्प होते हैं। ML-KEM के साथ, विकल्पों से पहले एक नया ChaCha अनुभाग होगा, जिसमें एन्क्रिप्टेड PQ सार्वजनिक कुंजी होगी।

ताकि PQ और गैर-PQ NTCP2 को एक ही राउटर पते और पोर्ट पर समर्थित किया जा सके, हम X मान (X25519 अस्थायी सार्वजनिक कुंजी) के सबसे महत्वपूर्ण बिट का उपयोग यह चिह्नित करने के लिए करते हैं कि यह एक PQ कनेक्शन है। गैर-PQ कनेक्शन के लिए यह बिट हमेशा अनसेट रहता है।

एलिस के लिए, नॉइज़ द्वारा संदेश को एन्क्रिप्ट करने के बाद, लेकिन X के AES विकृति से पहले, X[31] |= 0x7f सेट करें।

बॉब के लिए, एक्स के एईएस डी-ऑब्फ़स्केशन के बाद, एक्स[31] & 0x80 का परीक्षण करें। यदि बिट सेट है, तो एक्स[31] &= 0x7f के साथ इसे साफ़ करें, और नॉइज़ के माध्यम से पीक्यू कनेक्शन के रूप में डिक्रिप्ट करें। यदि बिट साफ़ है, तो आम तौर पर नॉइज़ के माध्यम से गैर-पीक्यू कनेक्शन के रूप में डिक्रिप्ट करें।

PQ NTCP2 के लिए जो एक अलग राउटर पते और पोर्ट पर विज्ञापित किया गया है, इसकी आवश्यकता नहीं होती है।

अतिरिक्त जानकारी के लिए, नीचे दिया गया प्रकाशित पते अनुभाग देखें।

मूल सामग्री:

  +----+----+----+----+----+----+----+----+
  |        MS bit set to 1 and then       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted X         |
  +             (32 bytes)                +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly encrypted data (MLKEM)   |
  +      (see table below for length)     +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  ~                                       ~
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  ~         padding (optional)            ~
  |     length defined in options block   |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

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

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

नोट: संदेश 1 के विकल्प ब्लॉक में संस्करण फ़ील्ड को PQ कनेक्शन के लिए भी 2 पर सेट किया जाना चाहिए।

आकार:

2) सत्रनिर्मित

परिवर्तन: वर्तमान NTCP2 में केवल एकल ChaCha अनुभाग में विकल्प होते हैं। ML-KEM के साथ, विकल्पों से पहले एक नया ChaCha अनुभाग होगा, जिसमें एन्क्रिप्टेड PQ साइफरटेक्स्ट होगा।

मूल सामग्री:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted Y         |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (MLKEM)     |
  -      (see table below for length)     -
  +   k defined in KDF for message 2      +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  +   k defined in KDF for message 2      +
  |  (after mixKey)                       |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

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

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

आकार:

3) सत्र की पुष्टि की गई

अपरिवर्तित

कुंजी व्युत्पत्ति फ़ंक्शन (KDF) (डेटा चरण के लिए)

अपरिवर्तित

प्रकाशित पते

सभी मामलों में, सामान्य रूप से NTCP2 ट्रांसपोर्ट नाम का उपयोग करें।

गैर-पीक्यू, गैर-फायरवॉल वाले के समान ही पता/पोर्ट का उपयोग करें। केवल एक पीक्यू संस्करण समर्थित है। राउटर पते में, एमएलकेकेएम 512/768/1024 को इंगित करने के लिए v=2 (सामान्य रूप से) और नया पैरामीटर pq=[3|4|5] प्रकाशित करें। एलिस सत्र अनुरोध में अस्थायी कुंजी के एमएसबी (key[31] & 0x80) को सेट करती है ताकि यह इंगित किया जा सके कि यह एक संकर कनेक्शन है। ऊपर देखें। पुराने राउटर pq पैरामीटर को अनदेखा कर देंगे और सामान्य रूप से गैर-पीक्यू के रूप में कनेक्ट हो जाएंगे।

गैर-PQ या केवल PQ, गैर-फ़ायरवॉल्ड के रूप में अलग पता/पोर्ट का समर्थन नहीं किया जाता है। गैर-PQ NTCP2 को अक्षम करने तक, जो कई वर्षों बाद होगा, इसे लागू नहीं किया जाएगा। जब गैर-PQ को अक्षम कर दिया जाता है, तो कई PQ प्रकारों का समर्थन किया जा सकता है, लेकिन प्रति-पते केवल एक का ही। राउटर पते में, MLKEM 512/768/1024 को इंगित करने के लिए v=[3|4|5] प्रकाशित करें। एलिस अस्थायी कुंजी के MSB को सेट नहीं करती है। पुराने राउटर v पैरामीटर की जांच करेंगे और इस पते को असमर्थित के रूप में छोड़ देंगे।

फ़ायरवॉल युक्त पते (कोई IP प्रकाशित नहीं): राउटर पते में, v=2 प्रकाशित करें (जैसा कि सामान्यतः होता है)। pq पैरामीटर प्रकाशित करने की कोई आवश्यकता नहीं है।

एलिस बॉब द्वारा प्रकाशित पीक्यू संस्करण का उपयोग करके पीक्यू बॉब से जुड़ सकती है, चाहे एलिस अपने राउटर जानकारी में पीक्यू समर्थन का विज्ञापन करे या न करे, या चाहे वह उसी संस्करण का विज्ञापन करे।

अधिकतम पैडिंग

वर्तमान विनिर्देश में, संदेश 1 और 2 को “उचित” मात्रा में पैडिंग होने के लिए परिभाषित किया गया है, जिसमें 0-31 बाइट्स की सिफारिश की गई है, और कोई अधिकतम निर्दिष्ट नहीं है।

API 0.9.68 तक (रिलीज 2.11.0), जावा I2P ने गैर-PQ कनेक्शन के लिए अधिकतम 256 बाइट्स पैडिंग लागू की, हालांकि इसे पहले दस्तावेजीकृत नहीं किया गया था। API 0.9.69 (रिलीज 2.12.0) से, जावा I2P MLKEM-512 के लिए जैसी अधिकतम पैडिंग लागू करता है, वैसी ही गैर-PQ कनेक्शन के लिए लागू करता है। नीचे तालिका देखें।

पीक्यू कनेक्शन के लिए संदेश आकार को अधिकतम पैडिंग के रूप में परिभाषित करें, अर्थात अधिकतम पैडिंग संदेश आकार को दोगुना कर देगी, निम्नानुसार:

SSU2

SSU2 विनिर्देश को इस प्रकार अद्यतन करें /docs/specs/ssu2/ :

शोर पहचानकर्ता

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

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

लंबा शीर्षक

लंबा हेडर 32 बाइट्स होता है। इसका उपयोग सत्र बनाने से पहले, टोकन अनुरोध, सत्र अनुरोध, सत्र बनाया गया और पुन: प्रयास के लिए किया जाता है। इसका उपयोग बाहर-के-सत्र समकक्ष परीक्षण और होल पंच संदेशों के लिए भी किया जाता है।

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

• (0) सत्र अनुरोध
• (1) सत्र बनाया गया
• (9) पुनः प्रयास (नोट: समाप्ति के साथ पुनः प्रयास में कोई भी संस्करण 2-4 शामिल हो सकता है)
• (10) टोकन अनुरोध
• (11) होल पंच

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

• (7) पीयर परीक्षण (सत्र के बाहर संदेश 5-7)

चर्चा: सभी संदेश प्रकारों के लिए संस्करण फ़ील्ड को 3 या 4 पर सेट करना जरूरी नहीं हो सकता, लेकिन इससे क्वांटम के बाद के असमर्थित कनेक्शन के लिए जल्दी विफलता का पता लगाने में मदद मिलती है। सुसंगतता के लिए टोकन अनुरोध और पुनः प्रयास (प्रकार 9 और 10) के संस्करण 3/4 होने चाहिए। होल पंच संदेशों (प्रकार 11) के लिए इस व्यवहार की आवश्यकता नहीं हो सकती, लेकिन एकरूपता के लिए हम इसी पैटर्न का पालन करेंगे। पीयर परीक्षण संदेश (प्रकार 7) सत्र के बाहर होता है और सत्र आरंभ करने के इरादे को इंगित नहीं करता।

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

  +----+----+----+----+----+----+----+----+
  |      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

लघु शीर्षक

अपरिवर्तित

सत्र अनुरोध (प्रकार 0)

परिवर्तन: वर्तमान SSU2 में केवल एकल ChaCha अनुभाग में ब्लॉक डेटा होता है। ML-KEM के साथ, ब्लॉक डेटा से पहले एक नया ChaCha अनुभाग होगा, जिसमें एन्क्रिप्टेड PQ सार्वजनिक कुंजी होगी।

नकली संरक्षण के लिए KDF में बदलाव: प्रस्ताव 165 [Prop165]_ में उठाए गए मुद्दों को संबोधित करने के लिए, लेकिन एक अलग समाधान के साथ, हम सत्र अनुरोध के लिए KDF में संशोधन करते हैं। यह केवल PQ सत्रों के लिए है। गैर-PQ सत्रों के लिए 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          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   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      |
  +----+----+----+----+----+----+----+----+

आकार, आईपी ओवरहेड सहित नहीं:

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

सत्रनिर्मित (प्रकार 1)

परिवर्तन: वर्तमान SSU2 में केवल एकल ChaCha अनुभाग में पेलोड होता है। ML-KEM के साथ, पेलोड से पहले एक नया ChaCha अनुभाग होगा, जिसमें एन्क्रिप्टेड PQ साइफरटेक्स्ट होगा।

मूल सामग्री:

  +----+----+----+----+----+----+----+----+
  |  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 encrypted data (MLKEM)     |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (payload)   |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (after mixKey)                       |
  +  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                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |      see below for allowed blocks     |
  +----+----+----+----+----+----+----+----+

आकार, आईपी ओवरहेड सहित नहीं:

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

सत्रपुष्टि (प्रकार 2)

अपरिवर्तित

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

अपरिवर्तित

रिले और पीयर परीक्षण

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

• रिले अनुरोध
• रिले प्रतिक्रिया
• रिले परिचय
• पीयर परीक्षण

पीक्यू हस्ताक्षर: रिले ब्लॉक, पीयर टेस्ट ब्लॉक और पीयर टेस्ट संदेश सभी में हस्ताक्षर होते हैं। दुर्भाग्यवश, पीक्यू हस्ताक्षर एमटीयू से बड़े होते हैं। वर्तमान में रिले या पीयर टेस्ट ब्लॉक या संदेशों को एकाधिक यूडीपी पैकेट्स में विभाजित करने की कोई तंत्र उपलब्ध नहीं है। प्रोटोकॉल में विभाजन के लिए समर्थन जोड़ने की आवश्यकता होगी। इसे एक अलग प्रस्ताव (TBD) में किया जाएगा। जब तक यह पूरा नहीं हो जाता, तब तक रिले और पीयर टेस्ट का समर्थन नहीं किया जाएगा।

प्रकाशित पते

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

गैर-PQ, गैर-फ़ायरवॉल्ड के समान ही एड्रेस/पोर्ट का उपयोग करें। एक या दोनों PQ प्रकार समर्थित हैं। राउटर एड्रेस में, v=2 (सामान्य रूप से) और नया पैरामीटर pq=[3|4|3,4|4,3] प्रकाशित करें जो MLKEM 512/768/दोनों को इंगित करता है। जिन राउटर्स का MTU नीचे निर्दिष्ट न्यूनतम से कम है, उन्हें “4” युक्त “pq” पैरामीटर प्रकाशित नहीं करना चाहिए। MLKEM-768 की पसंद दर्शाने के लिए 4,3 और MLKEM-512 की पसंद दर्शाने के लिए 3,4 प्रकाशित करें। वास्तविक संस्करण प्रारंभकर्ता पर निर्भर करता है, और पसंद का पालन नहीं किया जा सकता है। जिन राउटर्स का MTU नीचे निर्दिष्ट न्यूनतम से कम है, उन्हें MLKEM768 का उपयोग करके कनेक्ट नहीं होना चाहिए। पुराने राउटर pq पैरामीटर को अनदेखा कर देंगे और सामान्य रूप से गैर-pq के रूप में कनेक्ट हो जाएंगे।

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

फ़ायरवॉल्ड पते (कोई IP प्रकाशित नहीं): राउटर पते में, v=2 प्रकाशित करें (सामान्य रूप से)। रिले का समर्थन करने के लिए pq पैरामीटर को फ़ायरवॉल्ड पतों में प्रकाशित किया जाना चाहिए।

एलिस बॉब द्वारा प्रकाशित पीक्यू संस्करण का उपयोग करके पीक्यू बॉब से जुड़ सकती है, चाहे एलिस अपने राउटर जानकारी में पीक्यू समर्थन का विज्ञापन करे या न करे, या चाहे वह उसी संस्करण का विज्ञापन करे।

MTU

MLKEM768 के साथ MTU से अधिक नहीं जाने का सावधानी बरतें। MLKEM768_X25519 के लिए न्यूनतम MTU IPv4 के लिए 1318 और IPv6 के लिए 1338 है (मानते हुए कि DateTime और Padding या RelayTagRequest ब्लॉक के साथ न्यूनतम पेलोड 10 बाइट्स है)। SSU2 के लिए सामान्य रूप से न्यूनतम MTU 1280 है, इसलिए सभी पीयर MLKEM768 का उपयोग नहीं कर सकते। यदि वास्तविक MTU स्थानीय रूप से या पीयर द्वारा विज्ञापित न्यूनतम से कम है, तो MLKEM768 प्रकाशित या उपयोग न करें। इस बात का ध्यान रखें कि पैडिंग के आकार को ऐसे शामिल न करें कि संदेश 1 या 2 स्थानीय या दूरस्थ MTU से अधिक हो जाए।

स्ट्रीमिंग

TODO: क्या सिग्नेचर को कॉपी किए बिना साइनिंग/सत्यापन को परिभाषित करने का कोई अधिक कुशल तरीका है?

SU3 फ़ाइलें

बनाना है

IETF ड्राफ्ट के अनुभाग 8.1 में हैशएमएल-डीएसए को एक्स.509 प्रमाणपत्रों में लागू करने की अनुमति नहीं है और हैशएमएल-डीएसए के लिए ओआईडी (OID) नहीं दिए गए हैं, क्योंकि इसके कार्यान्वयन की जटिलता और कम सुरक्षा के कारण।

SU3 फ़ाइलों के केवल PQ हस्ताक्षरों के लिए, प्रमाणपत्रों के लिए गैर-प्रीहैश संस्करणों में IETF ड्राफ्ट में परिभाषित OIDs का उपयोग करें। हम SU3 फ़ाइलों के संकर हस्ताक्षर परिभाषित नहीं करते हैं, क्योंकि हमें फ़ाइलों को दो बार हैश करना पड़ सकता है (हालाँकि HashML-DSA और X2559 एक ही हैश फ़ंक्शन SHA512 का उपयोग करते हैं)। इसके अलावा, एक X.509 प्रमाणपत्र में दो कुंजियों और हस्ताक्षरों को जोड़ना पूरी तरह से गैरमानक होगा।

ध्यान दें कि हम SU3 फ़ाइलों के Ed25519 हस्ताक्षर करने की अनुमति नहीं देते हैं, और हालांकि हमने Ed25519ph हस्ताक्षर को परिभाषित किया है, लेकिन हम कभी इसके लिए एक OID पर सहमत नहीं हुए हैं, या इसका उपयोग नहीं किया है।

SU3 फ़ाइलों के लिए सामान्य sig प्रकारों की अनुमति नहीं है; ph (पूर्व-हैश) विविधताओं का उपयोग करें।

अन्य विशेषताएँ

नए अधिकतम गंतव्य आकार 2599 होगा (आधार 64 में 3468)।

डेस्टिनेशन आकार पर मार्गदर्शन देने वाले अन्य दस्तावेजों को अपडेट करें, जिनमें शामिल हैं:

• SAMv3
• बिटटॉरेंट
• डेवलपर दिशानिर्देश
• नामकरण / एड्रेसबुक / जंप सर्वर
• अन्य दस्तावेज़

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

कुंजी विनिमय

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

Cloudflare द्वारा बताई गई गति:

हस्ताक्षर

आकार:

आम तौर पर कुंजी, हस्ताक्षर, RIdent, Dest के आकार या आकार में वृद्धि (Ed25519 को संदर्भ के लिए शामिल किया गया है), RIs के लिए X25519 एन्क्रिप्शन प्रकार मानते हुए। एक राउटर जानकारी, लीजसेट, उत्तर योग्य डेटाग्राम और सूचीबद्ध दो स्ट्रीमिंग (SYN और SYN ACK) पैकेट में से प्रत्येक के लिए जोड़ा गया आकार। वर्तमान गंतव्य और लीजसेट में दोहराया गया पैडिंग होता है और ट्रांजिट के दौरान संपीड़ित किया जा सकता है। नए प्रकार में पैडिंग नहीं होता है और संपीड़ित नहीं किया जाएगा, जिसके परिणामस्वरूप ट्रांजिट के दौरान आकार में काफी वृद्धि होगी। डिज़ाइन अनुभाग ऊपर देखें।

Cloudflare द्वारा बताई गई गति:

सुरक्षा विश्लेषण

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

हैंडशेक

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

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

हस्ताक्षर

यह प्रस्ताव हाइब्रिड और केवल पीक्यू (PQ-only) हस्ताक्षर प्रकार दोनों को परिभाषित करता है। एमएलडीएसए65 पीक्यू-केवल की तुलना में एमएलडीएसए44 हाइब्रिड को वरीयता दी जाती है। एमएलडीएसए65 और एमएलडीएसए87 के लिए कुंजी और हस्ताक्षर आकार हमारे लिए शायद बहुत बड़े हैं, कम से कम अभी के लिए।

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

प्रकार वरीयताएं

हालांकि हम 3 क्रिप्टो और 9 हस्ताक्षर प्रकारों को परिभाषित और लागू करेंगे, हम विकास के दौरान प्रदर्शन को मापने और बढ़ी हुई संरचना के आकार के प्रभावों का आगे विश्लेषण करने की योजना बना रहे हैं। हम अन्य परियोजनाओं और प्रोटोकॉल में विकास पर शोध और निगरानी भी जारी रखेंगे।

विकास और परीक्षण के बाद, हम प्रत्येक उपयोग के मामले के लिए एक पसंदीदा प्रकार या डिफ़ॉल्ट तय करेंगे। चयन के लिए बैंडविड्थ, सीपीयू और अनुमानित सुरक्षा स्तर के व्यापार को बनाने की आवश्यकता होगी। सभी प्रकार सभी उपयोग के मामलों के लिए उपयुक्त या अनुमत नहीं हो सकते हैं।

प्रारंभिक वरीयताएँ निम्नलिखित हैं, जिनमें परिवर्तन की संभावना है:

एन्क्रिप्शन: MLKEM768_X25519

हस्ताक्षर: MLDSA44_EdDSA_SHA512_Ed25519

प्रारंभिक प्रतिबंध निम्नलिखित हैं, जो परिवर्तन के अधीन हैं:

हस्ताक्षर: MLDSA87 और संकर संस्करण शायद बहुत बड़े हैं; MLDSA65 और संकर संस्करण बहुत बड़े हो सकते हैं

लागूकरण नोट्स

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

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

जावा I2P द्वारा अनुकूलित साउथर्नस्टॉर्म.कॉम नॉइज लाइब्रेरी में हाइब्रिड हैंडशेक के लिए प्रारंभिक समर्थन शामिल था, लेकिन हमने इसे अप्रयुक्त होने के कारण हटा दिया था; हमें इसे वापस जोड़ना होगा और नॉइज HFS स्पेस के अनुरूप अपडेट करना होगा।

हस्ताक्षर विविधताएँ

हम “हेज़्ड” या यादृच्छिक हस्ताक्षर प्रकार का उपयोग करेंगे, “निर्धारक” प्रकार का नहीं, जैसा कि FIPS 204 खंड 3.4 में परिभाषित है। इससे यह सुनिश्चित होता है कि प्रत्येक हस्ताक्षर भले ही एक ही डेटा पर किया गया हो, अलग-अलग होगा, और साइड-चैनल हमलों के खिलाफ अतिरिक्त सुरक्षा प्रदान करता है। जबकि FIPS 204 यह विनिर्देश करता है कि “हेज़्ड” प्रकार डिफ़ॉल्ट है, विभिन्न लाइब्रेरी में यह सत्य हो भी सकता है या नहीं भी। लागू करने वालों को यह सुनिश्चित करना चाहिए कि हस्ताक्षर के लिए “हेज़्ड” प्रकार का उपयोग किया जा रहा है।

हम सामान्य हस्ताक्षर प्रक्रिया का उपयोग करते हैं (जिसे प्योर एमएल-डीएसए हस्ताक्षर उत्पादन कहा जाता है) जो संदेश को आंतरिक रूप से 0x00 || len(ctx) || ctx || message के रूप में एन्कोड करती है, जहाँ ctx आकार 0x00..0xFF का एक वैकल्पिक मान है। हम कोई वैकल्पिक संदर्भ नहीं उपयोग कर रहे हैं। len(ctx) == 0। इस प्रक्रिया को FIPS 204 एल्गोरिथ्म 2 चरण 10 और एल्गोरिथ्म 3 चरण 5 में परिभाषित किया गया है। ध्यान दें कि कुछ प्रकाशित परीक्षण वैक्टर में संदेश को एन्कोड न करने की अनुमति देने वाले मोड को सेट करने की आवश्यकता हो सकती है।

विश्वसनीयता

आकार में वृद्धि के कारण नेटडीबी (NetDB) स्टोर, स्ट्रीमिंग हैंडशेक और अन्य संदेशों के लिए टनल फ्रैगमेंटेशन काफी अधिक होगा। प्रदर्शन और विश्वसनीयता में परिवर्तन की जाँच करें।

संरचना के आकार

राउटर इन्फो और लीजसेट्स के बाइट आकार को सीमित करने वाले किसी भी कोड को खोजें और जांचें।

NetDB

संग्रहण वृद्धि को सीमित करने के लिए RAM या डिस्क पर संग्रहीत अधिकतम LS/RI की समीक्षा करें और संभवतः कम करें। फ्लडफिल के लिए न्यूनतम बैंडविड्थ आवश्यकताओं में वृद्धि करें?

रैचेट

साझा सुरंगें

एक ही टनल पर एकाधिक प्रोटोकॉल का स्वचालित वर्गीकरण/पता लगाना संदेश 1 (नया सत्र संदेश) की लंबाई की जांच के आधार पर संभव होना चाहिए। उदाहरण के लिए MLKEM512_X25519 का उपयोग करते हुए, संदेश 1 की लंबाई वर्तमान रैचेट प्रोटोकॉल से 816 बाइट अधिक है, और न्यूनतम संदेश 1 आकार (केवल DateTime पेलोड सहित) 919 बाइट है। वर्तमान रैचेट के साथ अधिकांश संदेश 1 आकारों में 816 बाइट से कम पेलोड होता है, इसलिए उन्हें गैर-संकर रैचेट के रूप में वर्गीकृत किया जा सकता है। बड़े संदेश शायद POST हैं जो दुर्लभ हैं।

इसलिए अनुशंसित रणनीति है:

• यदि संदेश 1, 919 बाइट्स से कम है, तो यह वर्तमान रैचेट प्रोटोकॉल है।
• यदि संदेश 1, 919 बाइट्स से अधिक या बराबर है, तो शायद यह MLKEM512_X25519 है। पहले MLKEM512_X25519 का प्रयास करें, और यदि विफल होता है, तो वर्तमान रैचेट प्रोटोकॉल का प्रयास करें।

इससे हमें एक ही गंतव्य पर मानक रैचेट और संकर रैचेट का कुशलता से समर्थन करने में सक्षम बनाया जाएगा, जिस तरह हम पहले एक ही गंतव्य पर ElGamal और रैचेट का समर्थन करते थे। इसलिए, हम MLKEM संकर प्रोटोकॉल पर उस स्थिति की तुलना में बहुत तेजी से परिवर्तित हो सकते हैं जहाँ हम एक ही गंतव्य के लिए दोहरे प्रोटोकॉल का समर्थन नहीं कर पाएंगे, क्योंकि हम मौजूदा गंतव्यों में MLKEM समर्थन जोड़ सकते हैं।

आवश्यक समर्थित संयोजन हैं:

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

निम्नलिखित संयोजन जटिल हो सकते हैं, और इन्हें समर्थित होने की आवश्यकता नहीं है, लेकिन कार्यान्वयन-परतंत्र होने के कारण हो सकते हैं:

• एक से अधिक MLKEM
• ElG + एक या अधिक MLKEM
• X25519 + एक या अधिक MLKEM
• ElG + X25519 + एक या अधिक MLKEM

हम एक ही गंतव्य पर एकाधिक MLKEM एल्गोरिदम (उदाहरण के लिए, MLKEM512_X25519 और MLKEM_768_X25519) का समर्थन करने का प्रयास नहीं कर सकते। केवल एक का चयन करें; हालाँकि, यह हमारे द्वारा एक वरीयता प्राप्त MLKEM संस्करण के चयन पर निर्भर करता है, ताकि HTTP क्लाइंट टनल इसका उपयोग कर सकें। लागूकरण-निर्भर।

हम एक ही गंतव्य पर तीन एल्गोरिदम (उदाहरण के लिए X25519, MLKEM512_X25519, और MLKEM769_X25519) का समर्थन करने का प्रयास कर सकते हैं। वर्गीकरण और पुनः प्रयास रणनीति बहुत जटिल हो सकती है। विन्यास और विन्यास यूआई बहुत जटिल हो सकता है। लागूकरण-निर्भर।

हम संभवतः एक ही गंतव्य पर ElGamal और हाइब्रिड एल्गोरिदम का समर्थन करने का प्रयास नहीं करेंगे। ElGamal अप्रचलित है, और केवल ElGamal + हाइब्रिड (X25519 के बिना) का कोई खास अर्थ नहीं है। इसके अलावा, ElGamal और Hybrid New Session Messages दोनों का आकार बड़ा होता है, इसलिए वर्गीकरण रणनीतियों को अक्सर दोनों डिक्रिप्शन का प्रयास करना पड़ सकता है, जो अक्षम होगा। यह लागूकरण-निर्भर है।

क्लाइंट एक ही टनल पर X25519 और हाइब्रिड प्रोटोकॉल के लिए समान या भिन्न X25519 स्थिर कुंजियों का उपयोग कर सकते हैं, जो लागूकरण पर निर्भर करता है।

फॉरवर्ड सीक्रेसी

ECIES विनिर्देश में न्यू सेशन मैसेज पेलोड में गैर्लिक मैसेज की अनुमति देता है, जिससे प्रारंभिक स्ट्रीमिंग पैकेट, आमतौर पर एक HTTP GET, को क्लाइंट के लीजसेट के साथ 0-RTT डिलीवरी की अनुमति मिलती है। हालाँकि, न्यू सेशन मैसेज पेलोड में फॉरवर्ड सीक्रेसी नहीं होती। चूंकि यह प्रस्ताव रैचेट के लिए बढ़ी हुई फॉरवर्ड सीक्रेसी पर जोर देता है, इसलिए लागूकरण या तो स्ट्रीमिंग पेलोड या पूरे स्ट्रीमिंग संदेश को पहले एक्ज़िस्टिंग सेशन मैसेज तक स्थगित कर सकते हैं या करना चाहिए। इससे 0-RTT डिलीवरी के लाभ की कीमत चुकानी पड़ेगी। रणनीतियाँ ट्रैफ़िक प्रकार या टनल प्रकार, या उदाहरण के लिए GET बनाम POST के आधार पर भी निर्भर कर सकती हैं। लागूकरण-निर्भर।

नया सत्र आकार

एमएलकेईएम, एमएलडीएसए, या एक ही गंतव्य पर दोनों, ऊपर वर्णित के अनुसार नए सत्र संदेश के आकार में भारी वृद्धि करेंगे। इससे टनल के माध्यम से नए सत्र संदेश के वितरण की विश्वसनीयता में महत्वपूर्ण कमी आ सकती है, जहां उन्हें कई 1024 बाइट टनल संदेशों में विखंडित करना पड़ता है। वितरण की सफलता विखंडों की घातीय संख्या के अनुपातिक होती है। लागूकरण 0-आरटीटी वितरण के नुकसान में संदेश के आकार को सीमित करने के लिए विभिन्न रणनीतियों का उपयोग कर सकते हैं। लागूकरण पर निर्भर।

NTCP2

हम सत्र अनुरोध में अस्थायी कुंजी के MSB (key[31] & 0x80) को सेट करते हैं ताकि यह इंगित किया जा सके कि यह एक हाइब्रिड कनेक्शन है। इससे हमें एक ही पोर्ट पर मानक NTCP और हाइब्रिड NTCP दोनों चलाने की अनुमति मिलती है। केवल एक हाइब्रिड संस्करण समर्थित होगा, और राउटर पते में इसका प्रचार किया जाएगा। उदाहरण के लिए, v=2,3 या v=2,4 या v=2,5।

विकृतिकरण

एलिस के रूप में, पीक्यू कनेक्शन के लिए, ऑब्फस्केशन से पहले, X[31] |= 0x80 सेट करें। इससे X एक अमान्य X25519 सार्वजनिक कुंजी बन जाती है। ऑब्फस्केशन के बाद, AES-CBC इसे यादृच्छिक कर देगा। ऑब्फस्केशन के बाद X का MSB यादृच्छिक होगा।

बॉब के रूप में, विघटन के बाद जांचें कि क्या (X[31] & 0x80) != 0। यदि हां, तो यह एक PQ कनेक्शन है।

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

नोट: प्रकार कोड केवल आंतरिक उपयोग के लिए हैं। राउटर प्रकार 4 बने रहेंगे, और समर्थन राउटर पतों में दर्शाया जाएगा।

SSU2

हम लॉन्ग हेडर में संस्करण फ़ील्ड का उपयोग करते हैं और इसे MLKEM512 के लिए 3 और MLKEM768 के लिए 4 पर सेट करते हैं। पते में v=2,3,4 पर्याप्त होगा।

जांचें और सत्यापित करें कि क्या SSU2 मल्टीपल पैकेट्स (6-8?) में विभाजित MLDSA-हस्ताक्षरित RI को संभाल सकता है।

नोट: प्रकार कोड केवल आंतरिक उपयोग के लिए हैं। राउटर प्रकार 4 बने रहेंगे, और समर्थन राउटर पतों में दर्शाया जाएगा।

राउटर संगतता

ट्रांसपोर्ट नाम

सभी मामलों में, आम तौर पर की तरह NTCP2 और SSU2 ट्रांसपोर्ट नामों का उपयोग करें।

राउटर एन्क्रिप्शन प्रकार

हमारे विचार करने के लिए कई विकल्प हैं:

प्रकार 5/6/7 राउटर

अनुशंसित नहीं है। केवल ऊपर सूचीबद्ध नए ट्रांसपोर्ट का उपयोग करें जो राउटर प्रकार से मेल खाते हों। पुराने राउटर कनेक्ट नहीं कर सकते, उनके माध्यम से टनल नहीं बना सकते या उन्हें netdb संदेश नहीं भेज सकते। डिफ़ॉल्ट रूप से सक्षम करने से पहले डिबग करने और समर्थन सुनिश्चित करने में कई रिलीज़ चक्र लग सकते हैं। नीचे दिए गए विकल्पों की तुलना में रोलआउट में एक वर्ष या उससे अधिक का विस्तार हो सकता है।

टाइप 4 राउटर

अनुशंसित। चूंकि PQ X25519 स्थिर कुंजी या N हैंडशेक प्रोटोकॉल को प्रभावित नहीं करता है, हम राउटर्स को प्रकार 4 के रूप में छोड़ सकते हैं और केवल नए ट्रांसपोर्ट को विज्ञापित कर सकते हैं। पुराने राउटर्स अभी भी कनेक्ट हो सकते हैं, उनके माध्यम से टनल बना सकते हैं, या नेटडीबी संदेश भेज सकते हैं।

सिफारिशें

MLKEM-768 को Ratchet, NTCP2, और SSU2 के लिए सुरक्षा और कुंजी लंबाई के सर्वोत्तम संतुलन के रूप में अनुशंसित किया गया है।

राउटर सिग। प्रकार

प्रकार 12-17 राउटर

पुराने राउटर RI को सत्यापित करते हैं और इसलिए उनसे कनेक्ट होने, उनके माध्यम से टनल बनाने या उन्हें netdb संदेश भेजने में असमर्थ होते हैं। डिबग करने और समर्थन सुनिश्चित करने में कई रिलीज चक्र लग सकते हैं, इससे पहले कि इसे डिफ़ॉल्ट रूप से सक्षम किया जा सके। यह एन्क्रिप्शन प्रकार 5/6/7 के रोलआउट के समान ही समस्याएं होंगी; ऊपर सूचीबद्ध टाइप 4 एन्क्रिप्शन प्रकार रोलआउट विकल्प की तुलना में रोलआउट में एक वर्ष या अधिक का विस्तार हो सकता है।

कोई विकल्प नहीं।

LS एन्क्रिप्शन प्रकार

प्रकार 5-7 LS कुंजियाँ

ये पुरानी प्रकार 4 X25519 कुंजियों के साथ LS में मौजूद हो सकते हैं। पुराने राउटर अज्ञात कुंजियों को नजरअंदाज कर देंगे।

गंतव्य एकाधिक कुंजी प्रकारों का समर्थन कर सकते हैं, लेकिन केवल प्रत्येक कुंजी के साथ संदेश 1 के प्रयासरत डिक्रिप्ट करके ही। प्रत्येक कुंजी के लिए सफल डिक्रिप्ट की गणना बनाए रखकर, और सबसे अधिक उपयोग की गई कुंजी को पहले आज़माकर, इस ओवरहेड को कम किया जा सकता है। एक ही गंतव्य पर ElGamal+X25519 के लिए जावा I2P इस रणनीति का उपयोग करता है।

गंतव्य हस्ताक्षर प्रकार

प्रकार 12-17 गंतव्य

राउटर लीजसेट हस्ताक्षरों को सत्यापित करते हैं और इसलिए प्रकार 12-17 के गंतव्यों के लिए कनेक्ट नहीं कर सकते या उनके लिए लीजसेट प्राप्त नहीं कर सकते। इसे डिफ़ॉल्ट रूप से सक्षम करने से पहले डिबग करने और समर्थन सुनिश्चित करने में कई रिलीज चक्र लग सकते हैं।

कोई विकल्प नहीं।

प्राथमिकताएँ और रोलआउट

सबसे मूल्यवान डेटा एंड-टू-एंड ट्रैफ़िक है, जिसे रैचेट के साथ एन्क्रिप्ट किया गया है। टनल हॉप्स के बीच एक बाहरी पर्यवेक्षक के रूप में, इसे टनल एन्क्रिप्शन और ट्रांसपोर्ट एन्क्रिप्शन के साथ दो बार और एन्क्रिप्ट किया गया है। OBEP और IBGW के बीच एक बाहरी पर्यवेक्षक के रूप में, इसे केवल एक बार और एन्क्रिप्ट किया गया है, ट्रांसपोर्ट एन्क्रिप्शन के साथ। एक OBEP या IBGW भागीदार के रूप में, केवल रैचेट एन्क्रिप्शन है। हालाँकि, चूँकि टनल एकदिश प्रवाह होते हैं, रैचेट हैंडशेक में दोनों संदेशों को पकड़ने के लिए राउटर्स के षड्यंत्र की आवश्यकता होगी, जब तक कि टनल OBEP और IBGW को एक ही राउटर पर रखकर न बनाए गए हों।

अभी के लिए सबसे चिंताजनक पीक्यू (PQ) खतरे का मॉडल आगे के वर्षों में डिक्रिप्शन के लिए आज के ट्रैफ़िक को स्टोर करना है (फॉरवर्ड सीक्रेसी)। एक संकर दृष्टिकोण इसकी सुरक्षा करेगा।

कुछ उचित समयावधि (मान लीजिए कुछ महीने) में प्रमाणीकरण कुंजियों को तोड़कर प्रमाणीकरण की नकल करने या लगभग वास्तविक समय में डिक्रिप्ट करने का पीक्यू (PQ) खतरा मॉडल, अभी बहुत दूर है? और उस समय हमें पीक्यूसी (PQC) स्थिर कुंजियों पर जाना चाहिए।

तो, सबसे पहले का PQ खतरा मॉडल OBEP/IBGW द्वारा भविष्य में डिक्रिप्शन के लिए ट्रैफ़िक संग्रहीत करना है। हमें सबसे पहले हाइब्रिड रैचेट लागू करना चाहिए।

रैचेट सबसे अधिक प्राथमिकता वाला है। ट्रांसपोर्ट इसके बाद आते हैं। हस्ताक्षर सबसे कम प्राथमिकता वाले हैं।

हस्ताक्षर रोलआउट एन्क्रिप्शन रोलआउट की तुलना में एक वर्ष या उससे अधिक समय बाद होगा, क्योंकि कोई पिछड़ी संगतता संभव नहीं है।

I2P में MLDSA हस्ताक्षर समर्थन पर कार्य मानक निकायों द्वारा एल्गोरिदम के चयन, संभवतः कुंजी और/या हस्ताक्षर आकार में कमी और उद्योग अपनाने को बढ़ावा देने के लिए कार्य पूरा होने तक लेट 2027 या 2028 तक रोक दिया गया है। देखें CABFORUM और PLANTS । इसके अलावा, उद्योग में MLDSA के अपनाने को CA/ब्राउज़र फोरम और प्रमाणपत्र अधिकारियों द्वारा मानकीकृत किया जाएगा। सीए को पहले हार्डवेयर सुरक्षा मॉड्यूल (HSM) समर्थन की आवश्यकता है, जो वर्तमान में उपलब्ध नहीं है CA/Browser Forum । हम उम्मीद करते हैं कि विशिष्ट पैरामीटर चयन पर निर्णय CA/ब्राउज़र फोरम द्वारा लिए जाएंगे, जिसमें संयुक्त हस्ताक्षरों को समर्थन या आवश्यकता शामिल हो सकती है IETF ड्राफ्ट ।

माइग्रेशन

यदि हम एक ही टनल पर पुराने और नए रैचेट प्रोटोकॉल दोनों का समर्थन नहीं कर सकते हैं, तो माइग्रेशन कहीं अधिक कठिन हो जाएगा।

हमें बस एक-फिर-दूसरे का प्रयास करने में सक्षम होना चाहिए, जैसा कि हमने X25519 के साथ किया था, जिसे साबित करना है।

मुद्दे

• नॉइज़ हैश चयन - SHA256 के साथ रहें या अपग्रेड करें? SHA256 अगले 20-30 वर्षों तक अच्छा रहने की संभावना है, और पोस्ट-क्वांटम (PQ) द्वारा खतरे में नहीं है, देखें NIST प्रस्तुति और NCCOE प्रस्तुति । यदि SHA256 टूट जाता है, तो हमारे पास और भी बड़ी समस्याएँ होंगी (netdb)।
• NTCP2 अलग पोर्ट, अलग राउटर पता
• SSU2 रिले / पीयर परीक्षण
• SSU2 संस्करण फ़ील्ड
• SSU2 राउटर पता संस्करण

संदर्भ

• CABFORUM
• Choosing-Hash
• CLOUDFLARE
• COMMON
• COMPOSITE-SIGS
• ECIES
• FORUM
• FIPS202
• FIPS203
• FIPS204
• FIPS205
• MLDSA-OIDS
• NIST-PQ
• NIST-PQ-UPDATE
• NIST-PQ-END
• NIST-VECTORS
• Noise
• Noise-Hybrid
• NSA-PQ
• NTCP2
• OPENSSL
• PLANTS
• Prop165
• PQ-WIREGUARD
• RFC-2104
• Rosenpass
• Rosenpass-Whitepaper
• SSH-HYBRID
• SSU2
• TLS-HYBRID