ECIES गंतव्यों से डेटाबेस लुकअप्स | I2P - अदृश्य इंटरनेट परियोजना

नोट

ECIES से ElG को 0.9.46 में लागू किया गया है और प्रस्ताव चरण बंद है। आधिकारिक विनिर्देश के लिए I2NP देखें। यह प्रस्ताव पृष्ठभूमि जानकारी के लिए संदर्भ के रूप में उपयोग किया जा सकता है। पिछले कुंजियों के साथ ECIES से ECIES को 0.9.48 से लागू किया गया है। ECIES-to-ECIES (उत्पन्न कुंजियों के साथ) अनुभाग को भविष्य में किसी प्रस्ताव में फिर से खोला या शामिल किया जा सकता है।

अवलोकन

परिभाषाएँ

AEAD: ChaCha20/Poly1305
DLM: I2NP डेटाबेस लुकअप संदेश
DSM: I2NP डेटाबेस स्टोर संदेश
DSRM: I2NP डेटाबेस खोज उत्तर संदेश
ECIES: ECIES-X25519-AEAD-Ratchet (प्रस्ताव 144)
ElG: ElGamal
ENCRYPT(k, n, payload, ad): जैसा कि ECIES में परिभाषित किया गया है
LS: लीज़सेट
लुकअप: I2NP DLM
उत्तर: I2NP DSM या DSRM

सारांश

जब फ्लडफिल के लिए एक लीज़सेट के लिए DLM भेजते हैं, तो DLM आमतौर पर निर्दिष्ट करता है कि उत्तर को टैग किया गया, AES एन्क्रिप्ट किया गया और लक्ष्य तक एक सुरंग में भेजा जाए। AES-एन्क्रिप्टेड उत्तरों के लिए समर्थन 0.9.7 में जोड़ा गया था।

AES-एन्क्रिप्टेड उत्तरों को 0.9.7 में निर्दिष्ट किया गया था ताकि ElG के बड़े क्रिप्टो ओवरहेड को कम किया जा सके, और क्योंकि इसने ElGamal/AES+SessionTags में टैग्स/AES सुविधा का पुन: उपयोग किया। हालाँकि, उत्तरों के साथ IBEP पर छेड़छाड़ हो सकती है क्योंकि कोई प्रमाणीकरण नहीं है, और उत्तर पूर्व गोपनीय नहीं हैं।

ECIES गंतव्यों के साथ, प्रस्ताव 144 का उद्देश्य यह है कि गंतव्य अब 32-बाइट टैग और AES डिक्रिप्शन का समर्थन नहीं करेंगे। विशेषताएँ जानबूझकर उस प्रस्ताव में शामिल नहीं की गई थीं।

यह प्रस्ताव एक नए विकल्प को DLM में दस्तावेज करता है ताकि ECIES-एन्क्रिप्टेड उत्तरों का अनुरोध किया जा सके।

लक्ष्य

एक सुरंग के माध्यम से ECIES गंतव्य तक एन्क्रिप्टेड उत्तर का अनुरोध करने के लिए DLM के नए ध्वज
उत्तर के लिए, फॉरवर्ड सिक्रेसी और आवेदक की (गंतव्य) कुंजी के समझौते के विरोध में प्रेषक प्रमाणीकरण जोड़ें।
आवेदक की अनामिता बनाए रखें
क्रिप्टो ओवरहेड को न्यूनतम करें

गैर-लक्ष्य

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

विकल्प

ECIES गंतव्यों के लिए उत्तरों को एन्क्रिप्ट करने का कोई परिभाषित तरीका न होने की स्थिति में, कई विकल्प हैं:

एन्क्रिप्टेड उत्तर न मांगें। उत्तर बिना एन्क्रिप्ट किए होंगे। Java I2P वर्तमान में इस दृष्टिकोण का उपयोग करता है।
केवल 32-बाइट टैग्स और AES-एन्क्रिप्टेड उत्तरों के लिए ECIES-केवल गंतव्यों के लिए समर्थन जोड़ें, और सामान्य रूप से AES-एन्क्रिप्टेड उत्तरों का अनुरोध करें। i2pd वर्तमान में इस दृष्टिकोण का उपयोग करता है।
सामान्य रूप से AES-एन्क्रिप्टेड उत्तरों का अनुरोध करें, लेकिन उन्हें राउटर पर वापस पूछताछ सुरंगों के माध्यम से भेजें। Java I2P वर्तमान में कुछ मामलों में इस दृष्टिकोण का उपयोग करता है।
दोहरे ElG और ECIES गंतव्यों के लिए, सामान्य रूप से AES-एन्क्रिप्टेड उत्तरों का अनुरोध करें। Java I2P वर्तमान में इस दृष्टिकोण का उपयोग करता है। i2pd ने अभी तक दोहरे-क्रिप्टो गंतव्यों को लागू नहीं किया है।

डिज़ाइन

नए DLM प्रारूप में ध्वज फ़ील्ड में एक बिट जोड़ें ताकि ECIES-एन्क्रिप्टेड उत्तरों को निर्दिष्ट किया जा सके। ECIES-एन्क्रिप्टेड उत्तर ECIES मौजूदा सत्र संदेश प्रारूप का उपयोग करेंगे, एक प्रीपेंड किए गए टैग और एक ChaCha/Poly पेलोड और MAC के साथ।
दो प्रकारों को परिभाषित करें। ElG राउटर्स के लिए एक, जहां DH ऑपरेशन संभव नहीं है, और भविष्य के ECIES राउटर्स के लिए एक, जहां DH ऑपरेशन संभव है और अतिरिक्त सुरक्षा प्रदान कर सकता है। आगे के अध्ययन के लिए।

ElG राउटर्स से उत्तरों के लिए DH संभव नहीं है क्योंकि वे X25519 सार्वजनिक कुंजी प्रकाशित नहीं करते हैं।

विनिर्देश

I2NP DLM (डेटाबेस लुकअप) विनिर्देश में, निम्नलिखित परिवर्तन करें।

नए एन्क्रिप्शन विकल्पों के लिए ध्वज बिट 4 “ECIESFlag” जोड़ें।

flags ::
       bit 4: ECIESFlag
               रिलीज़ 0.9.46 से पहले उपेक्षित
               रिलीज़ 0.9.46 के रूप में:
               0  => बिना एन्क्रिप्शन या ElGamal उत्तर भेजें
               1  => समाविष्ट कुंजी का उपयोग करके ChaCha/Poly एन्क्रिप्टेड उत्तर भेजें
                     (क्या टैग समाविष्ट है, यह बिट 1 पर निर्भर करता है)

उत्तर एन्क्रिप्शन मोड निर्धारित करने के लिए ध्वज बिट्स 4 और 1 का संयोजन में उपयोग किया गया है। राउटर्स के लिए केवल तब ध्वज बिट 4 सेट किया जाना चाहिए जब 0.9.46 या उच्चतर संस्करण के साथ भेजा जा रहा हो।

नीचे दी गई तालिका में, “DH n/a” का मतलब है कि उत्तर एन्क्रिप्टेड नहीं है। “DH no” का मतलब है कि उत्तर कुंजियाँ अनुरोध में शामिल होती हैं। “DH yes” का मतलब है कि उत्तर कुंजियाँ DH ऑपरेशन से उत्पन्न होती हैं।

============= ========= ========= ====== === ======= Flag bits 4,1 From Dest To Router Reply DH? टिप्पणियाँ ============= ========= ========= ====== === ======= 0 0 कोई भी कोई भी नहीं n/a वर्तमान 0 1 ElG ElG AES नहीं वर्तमान 0 1 ECIES ElG AES नहीं i2pd वर्कअराउंड 1 0 ECIES ElG AEAD नहीं यह प्रस्ताव 1 0 ECIES ECIES AEAD नहीं 0.9.49 1 1 ECIES ECIES AEAD हाँ भविष्य ============= ========= ========= ====== === =======

ElG से ElG

ElG गंतव्य एक लुकअप एक ElG राउटर को भेजता है।

नए बिट 4 को जांचने के लिए विनिर्देशन में मामूली परिवर्तन। मौजूदा बाइनरी प्रारूप में कोई परिवर्तन नहीं।

आवेदक कुंजी पीढ़ी (स्पष्टीकरण):

reply_key :: CSRNG(32) 32 बाइट्स यादृच्छिक डेटा
  reply_tags :: प्रत्येक CSRNG(32) 32 बाइट्स यादृच्छिक डेटा है

संदेश प्रारूप (ECIESFlag की जाँच जोड़ें):

reply_key ::
       32 बाइट `SessionKey` बिग-एंडियन
       केवल तभी समाविष्ट होता है जब encryptionFlag == 1 और ECIESFlag == 0 हो, 0.9.7 के रूप में

  tags ::
       1 बाइट `Integer`
       मान्य सीमा: 1-32 (आमतौर पर 1)
       कितने उत्तर टैग अनुसरण करते हैं
       केवल तभी समाविष्ट होता है जब encryptionFlag == 1 और ECIESFlag == 0 हो, 0.9.7 के रूप में

  reply_tags ::
       एक या अधिक 32 बाइट `SessionTag`s (आमतौर पर एक)
       केवल तभी समाविष्ट होता है जब encryptionFlag == 1 और ECIESFlag == 0 हो, 0.9.7 के रूप में

ECIES से ElG

ECIES गंतव्य एक लुकअप एक ElG राउटर को भेजता है। 0.9.46 के रूप में समर्थित।

उत्तर कुंजी और उत्तर टैग क्षेत्र ECIES-एन्क्रिप्टेड उत्तर के लिए पुन: परिभाषित किए गए हैं।

आवेदक कुंजी पीढ़ी:

reply_key :: CSRNG(32) 32 बाइट्स यादृच्छिक डेटा
  reply_tags :: प्रत्येक CSRNG(8) 8 बाइट्स यादृच्छिक डेटा है

संदेश प्रारूप: उत्तर कुंजी और उत्तर टैग क्षेत्र को इस प्रकार पुनर्परिभाषित करें:

reply_key ::
       32 बाइट ECIES `SessionKey` बिग-एंडियन
       केवल तभी समाविष्ट होता है जब encryptionFlag == 0 और ECIESFlag == 1 हो, 0.9.46 के रूप में

  tags ::
       1 बाइट `Integer`
       आवश्यक मान: 1
       कितने उत्तर टैग अनुसरण करते हैं
       केवल तभी समाविष्ट होता है जब encryptionFlag == 0 और ECIESFlag == 1 हो, 0.9.46 के रूप में

  reply_tags ::
       एक 8 बाइट ECIES `SessionTag`
       केवल तभी समाविष्ट होता है जब encryptionFlag == 0 और ECIESFlag == 1 हो, 0.9.46 के रूप में

उत्तर एक ECIES मौजूदा सत्र संदेश है, जैसा कि ECIES में परिभाषित है।

tag :: 8 बाइट reply_tag

  k :: 32 बाइट सत्र कुंजी
     उत्तर कुंजी।

  n :: 0

  ad :: 8 बाइट reply_tag

  payload :: प्लेनटेक्स्ट डेटा, DSM या DSRM।

  ciphertext = ENCRYPT(k, n, payload, ad)

ECIES से ECIES (0.9.49)

ECIES गंतव्य या राउटर एक ECIES राउटर को एक लुकअप भेजता है, जिसमें उत्तर कुंजियाँ शामिल होती हैं। 0.9.49 के रूप में समर्थित।

ECIES राउटर 0.9.48 में परिचय हुआ, देखें Prop156। 0.9.49 के रूप में, ECIES गंतव्यों और राउटर एक ही प्रारूप का उपयोग कर सकते हैं जैसा कि “ECIES से ElG” अनुभाग में, उत्तर कुंजियों के साथ अनुरोध में शामिल होता है। लुकअप “एक बार का प्रारूप” का उपयोग करेगा ECIES में जैसा कि आवेदक गुमनाम है।

नई विधि के लिए उत्पन्न कुंजियों के साथ, अगला अनुभाग देखें।

ECIES से ECIES (भविष्य)

ECIES गंतव्य या राउटर एक ECIES राउटर को एक लुकअप भेजता है, और उत्तर कुंजियाँ DH से उत्पन्न होती हैं। पूरी तरह से परिभाषित नहीं है या समर्थित नहीं है, कार्यान्वयन TBD है।

लुकअप “एक बार का प्रारूप” का उपयोग करेगा ECIES में जैसा कि आवेदक गुमनाम है।

उत्तर कुंजी फ़ील्ड को इस प्रकार पुनर्परिभाषित करें। कोई संबद्ध टैग नहीं हैं। टैग नीचे दिए गए KDF में उत्पन्न होंगे।

यह अनुभाग अधूरा है और इसे और अधिक अध्ययन की आवश्यकता है।

reply_key ::
       32 बाइट X25519 अस्थायी `PublicKey` आवेदक का, लिटिल-एंडियन
       केवल तब शामिल होता है, जब encryptionFlag == 1 और ECIESFlag == 1, केवल रिलीज़ 0.9.TBD के रूप में

उत्तर एक ECIES मौजूदा सत्र संदेश है, जैसा कि ECIES में परिभाषित है। सभी परिभाषाओं के लिए ECIES देखें।

// Alice के X25519 अस्थायी कुंजी
  // aesk = Alice अस्थायी निजी कुंजी
  aesk = GENERATE_PRIVATE()
  // aepk = Alice अस्थायी सार्वजनिक कुंजी
  aepk = DERIVE_PUBLIC(aesk)
  // Bob के X25519 स्थैतिक कुंजी
  // bsk = Bob निजी स्थैतिक कुंजी
  bsk = GENERATE_PRIVATE()
  // bpk = Bob सार्वजनिक स्थैतिक कुंजी
  // bpk या तो RouterIdentity का हिस्सा है, या RouterInfo में प्रकाशित होता है (TBD)
  bpk = DERIVE_PUBLIC(bsk)

  // (DH()
  //[chainKey, k] = MixKey(sharedSecret)
  // chainKey से ???
  sharedSecret = DH(aesk, bpk) = DH(bsk, aepk)
  keydata = HKDF(chainKey, sharedSecret, "ECIES-DSM-Reply1", 32)
  chainKey = keydata[0:31]

  1) rootKey = Payload Section से chainKey
  2) k से New Session KDF या split()

  // KDF_RK(rk, dh_out)
  keydata = HKDF(rootKey, k, "KDFDHRatchetStep", 64)

  // आउटपुट 1: उपयोग नहीं हुआ
  unused = keydata[0:31]
  // आउटपुट 2: न्यू सत्र टैग और सममित कुंजी रैचेट्स के लिए चेन कुंजी
  // Alice से Bob के प्रसारण के लिए
  ck = keydata[32:63]

  // सत्र टैग और सममित कुंजी चेन कुंजी
  keydata = HKDF(ck, ZEROLEN, "TagAndKeyGenKeys", 64)
  sessTag_ck = keydata[0:31]
  symmKey_ck = keydata[32:63]

  tag :: 8 बाइट के रूप में RATCHET_TAG() में उत्पन्न हुआ [ECIES](/docs/specs/ecies/)

  k :: 32 बाइट के रूप में RATCHET_KEY() में उत्पन्न हुआ [ECIES](/docs/specs/ecies/)

  n :: टैग का सूचकांक। आमतौर पर 0।

  ad :: 8 बाइट टैग

  payload :: सरलपाठ डाटा, DSM या DSRM।

  ciphertext = ENCRYPT(k, n, payload, ad)

उत्तर प्रारूप

यह मौजूदा सत्र संदेश है, जो ECIES में जैसा है, संदर्भ के लिए नीचे कॉपी किया गया है।

+----+----+----+----+----+----+----+----+
  |       सत्र टैग                     |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            पेलोड अनुभाग            +
  |       ChaCha20 एन्क्रिप्टेड डेटा         |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 संदेश प्रमाणीकरण कोड |
  +              (MAC)                    +
  |             16 बाइट्स                  |
  +----+----+----+----+----+----+----+----+

  सत्र टैग :: 8 बाइट्स, स्पष्ट पाठ

  पेलोड अनुभाग एन्क्रिप्टेड डेटा :: शेष डेटा माइनस 16 बाइट्स

  MAC :: Poly1305 संदेश प्रमाणीकरण कोड, 16 बाइट्स

औचित्य

लुकअप में उत्तर एन्क्रिप्शन पैरामीटर, पहली बार 0.9.7 में पेश किए गए, कुछ हद तक एक परत उल्लंघन हैं। इसे इस तरह से किया गया है ताकि यह कुशल हो। लेकिन साथ ही क्योंकि लुकअप गुमनाम है।

हम लुकअप प्रारूप को सामान्य बना सकते हैं, जैसे कि एक एन्क्रिप्शन प्रकार फ़ील्ड के साथ, लेकिन यह शायद उससे अधिक परेशानी है जितना इसका मूल्य है।

ऊपर प्रस्तावित प्रस्ताव सबसे आसान है और लुकअप प्रारूप में बदलाव को न्यूनतम करता है।

नोट्स

ElG राउटर्स के लिए डेटाबेस लुकअप्स और स्टोर्स को हमेशा की तरह ElGamal/AESSessionTag से एन्क्रिप्टेड होना चाहिए।

मुद्दे

दो ECIES उत्तर विकल्पों की सुरक्षा पर और विश्लेषण की आवश्यकता है।

माइग्रेशन

कोई पिछड़ा संगतता मुद्दा नहीं। RouterInfo में 0.9.46 या उच्चतर का संस्करण विज्ञापित करने वाले राउटर को इस सुविधा का समर्थन करना चाहिए। राउटर को 0.9.46 से कम संस्करण वाले राउटर को नए झंडे के साथ डेटाबेस लुकअप नहीं भेजना चाहिए। अगर गलती से बिट 4 सेट और बिट 1 अनसेट के साथ डेटाबेस लुकअप संदेश को बिना समर्थन के किसी राउटर को भेजा जाता है, तो वह संभवतः प्रदत्त कुंजी और टैग को अनदेखा कर देगा, और उत्तर को बिना एन्क्रिप्ट के भेजेगा।

नोट