अवलोकन
यह प्रस्ताव NTCP परिवहन को सुधारने के बारे में है ताकि इसे स्वचालित पहचान से बचाया जा सके।
प्रेरणा
पहले संदेश के बाद NTCP डेटा एन्क्रिप्ट किया जाता है (और पहला संदेश रैंडम डेटा के रूप में आता है), जिससे “पेलोड विश्लेषण” के माध्यम से प्रोटोकॉल पहचान को रोका जा सकता है। यह अभी भी “फ्लो विश्लेषण” के माध्यम से प्रोटोकॉल पहचान के लिए असुरक्षित है। इसका कारण यह है कि पहले 4 संदेश (यानी हैंडशेक) निश्चित लंबाई के होते हैं (288, 304, 448, और 48 बाइट्स)।
प्रत्येक संदेश में रैंडम मात्रा में रैंडम डेटा जोड़कर, हम इसे काफी कठिन बना सकते हैं।
NTCP में संशोधन
यह काफी भारी है लेकिन यह DPI उपकरण द्वारा किसी भी पता लगाने को रोकता है।
288-बाइट संदेश 1 के अंत में निम्नलिखित डेटा जोड़ा जाएगा:
- एक 514-बाइट ElGamal एन्क्रिप्टेड ब्लॉक
- रैंडम पैडिंग
ElG ब्लॉक बॉब की सार्वजनिक कुंजी के लिए एन्क्रिप्ट किया गया है। जब इसे 222 बाइट्स में डिक्रिप्ट किया जाता है, तो इसमें होता है:
- 214 बाइट्स रैंडम पैडिंग
- 4 बाइट्स 0 आरक्षित
- 2 बाइट्स पैडिंग लंबाई जो आगे होगी
- 2 बाइट्स प्रोटोकॉल संस्करण और फ्लैग्स
संदेश 2-4 में, पैडिंग की आखिरी दो बाइट्स अब आगे आने वाली पैडिंग की लंबाई को दर्शाएंगी।
ध्यान दें कि ElG ब्लॉक के पास परफेक्ट फॉरवर्ड सीक्रेसी नहीं है लेकिन उसमें कुछ भी दिलचस्प नहीं है।
हम अपनी ElG लाइब्रेरी को संशोधित कर सकते हैं ताकि यह छोटी डेटा साइजों को एन्क्रिप्ट कर सके अगर हमें लगता है कि 514 बाइट्स बहुत ज्यादा है? क्या प्रत्येक NTCP सेटअप के लिए ElG एन्क्रिप्शन बहुत अधिक है?
इसके समर्थन के लिए “version=2” विकल्प के साथ नेटडबी RouterAddress में विज्ञापन दिया जाएगा। यदि संदेश 1 में केवल 288 बाइट्स प्राप्त होते हैं, तो एलिस को संस्करण 1 माना जाता है और subsequent संदेशों में कोई पैडिंग नहीं भेजी जाती। ध्यान दें कि यदि MITM द्वारा IP को 288 बाइट्स में खंडित किया गया हो तो संवाद ब्लॉक हो सकता है (सर्वे Brandon के अनुसार, यह बहुत ही असंभावित है)।