लंबी Blowfish कुंजी 64-बिट ब्लॉक को क्यों ठीक नहीं कर सकती

एक VPN प्रोफ़ाइल 448-बिट कुंजी के साथ Blowfish प्रदान करता है, और कोई सुझाव देता है कि सिफ़र बनाए रखने के लिए सबसे लंबी कुंजी का उपयोग किया जाए। कुंजी की लंबाई वास्तविक है, लेकिन यह अनुकूलन के लिए गलत संख्या है। Blowfish 64-बिट ब्लॉकों को बदलता है, चाहे कुंजी कितनी भी लंबी हो, और ब्लॉक की चौड़ाई ही यह सीमित करती है कि एक कुंजी कितने ट्रैफ़िक की सुरक्षित रूप से रक्षा कर सकती है। नीचे दी गई जाँचें क्रम से चलाएँ और पहली ऐसी जाँच पर रुकें जो सेवा को संदेह से मुक्त कर दे, क्योंकि बाद का चरण पहले के चरण की मरम्मत नहीं कर सकता।

जाँचें कि पक्ष वास्तव में किस पर सहमत होते हैं

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

यदि तय सिफ़र AES-GCM या ChaCha20-Poly1305 है, तो यहीं रुकें। वे संरचनाएँ 128-बिट ब्लॉक का उपयोग करती हैं और पेलोड को प्रमाणित करती हैं, इसलिए नीचे दिया गया 64-बिट टकराव का तर्क उन पर लागू नहीं होता।

कुंजी की लंबाई को ब्लॉक की चौड़ाई से अलग करें

Blowfish 32 से 448 बिट तक की कुंजियाँ स्वीकार करता है, और एल्गोरिदम के लेखक का दस्तावेज़ दोनों संख्याएँ अलग-अलग बताता है। कुंजी रहस्य है; ब्लॉक रूपांतरण की इकाई है। लंबा रहस्य अनुमान लगाना कठिन बनाता है और सिफ़र द्वारा संसाधित ब्लॉक की चौड़ाई पर कुछ नहीं करता।

CBC मोड में सिफ़र निश्चित चौड़ाई के ब्लॉकों पर लागू होता है, जो पिछले सिफ़रटेक्स्ट ब्लॉक के साथ श्रृंखलाबद्ध होते हैं और अंत में पैड किए जाते हैं। Blowfish के लिए वह चौड़ाई 64 बिट यानी आठ बाइट है। कुंजी अनुसूची जितनी बड़ी चाहें हो सकती है; श्रृंखला फिर भी एक बार में आठ बाइट आगे बढ़ती है।

इसलिए लंबी कुंजी कोई शमन नहीं है। यह कुंजी के विरुद्ध ब्रूट फ़ोर्स को संबोधित करती है, जबकि नीचे दिया गया टकराव जोखिम ब्लॉक की चौड़ाई और मोड का गुण है।

जन्मदिन अंकगणित को ब्लॉक के आकार पर लागू करें

64-बिट ब्लॉक का जन्मदिन पैमाना लगभग 2^32 ब्लॉक है जो एक कुंजी के अंतर्गत एन्क्रिप्ट किए जाते हैं, इससे पहले कि टकराव संभावित हों। प्रत्येक ब्लॉक आठ बाइट ले जाता है, इसलिए वही पैमाना लगभग 2^35 बाइट यानी एक कुंजी के अंतर्गत 32 GiB डेटा है।

इसे पैमाना मानें, कोटा नहीं। टकराव संभाव्य हैं, और यह कि कोई कुछ प्रकट करता है या नहीं, मोड, ट्रैफ़िक पैटर्न और इस पर निर्भर करता है कि हमलावर आसपास के सादे पाठ को पहचान सकता है या उसे प्रभावित कर सकता है। 32 GiB के बाद का पहला बाइट डिक्रिप्शन घटना नहीं है, और पहले 32 GiB सुरक्षित प्रमाणित नहीं हैं।

Sweet32 के शोधकर्ताओं ने 2016 में 64-बिट ब्लॉक सिफ़रों के विरुद्ध व्यावहारिक हमले प्रदर्शित किए, जिनमें OpenVPN परिदृश्य भी शामिल था, ऐसी परिस्थितियों में जिनके लिए अवलोकन और ट्रैफ़िक उत्पादन आवश्यक था। उनके प्रकाशित डिफ़ॉल्ट और सॉफ़्टवेयर संस्करण ऐतिहासिक संदर्भ हैं, आपकी तैनाती का विवरण नहीं।

तय करें कि क्या यहाँ CBC का पुन: उपयोग मायने रखता है

CBC में दोहराया गया सिफ़रटेक्स्ट ब्लॉक का अर्थ है कि दोनों सादे पाठ ब्लॉक किसी ज्ञात संबंध से भिन्न हैं, क्योंकि श्रृंखला का XOR स्वयं को रद्द कर देता है। ऐसा हमलावर जो सिफ़रटेक्स्ट का अवलोकन कर सकता है और सादे पाठों में से एक को जानता है या उसे प्रभावित कर सकता है, दूसरे के बारे में जानकारी प्राप्त कर सकता है। इसके लिए Blowfish कुंजी कभी आवश्यक नहीं होती।

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

यदि प्रति कुंजी मापी गई मात्रा जन्मदिन पैमाने से बहुत नीचे रहती है, तो जोखिम कम है। यह फिर भी शून्य नहीं है और फिर भी चिंता छोड़ने के बजाय माइग्रेशन की योजना बनाने का कारण है।

सिफ़र बदलें, कुंजी नहीं

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

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

जाँच को नए कनेक्शन पर तय सिफ़र फिर से पढ़कर और फिर पुष्टि करके बंद करें कि पुराना सिफ़र अब स्वीकार नहीं किया जाता। यदि कोई पक्ष अब भी उसे प्रस्तावित करता है, तो माइग्रेशन पूरा नहीं हुआ, चाहे दूसरी ओर की प्रोफ़ाइल कुछ भी कहे।