लामो 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 कुञ्जीले केही महत्त्वपूर्ण बदल्दैन, र एउटा क्लाइन्टमा नयाँ निर्देशको अनुमान लगाउनु काम गर्ने सुरुङ बिग्रिएको सुरुङ बन्ने तरिका हो। बाँकी फ्लीटलाई छुनुअघि एउटा क्लाइन्ट र एउटा सर्भरमा परिवर्तन परीक्षण गर्नुहोस्। नयाँ साइफरले पूर्ण जडान चक्र पार नगरेसम्म पुरानो प्रोफाइल फर्काउन उपलब्ध राख्नुहोस्।

परिवर्तनका क्रममा प्रमाणपत्र प्रमाणीकरण र खाता प्रमाणीकरण कायम राख्नुहोस्। तिनले फरक प्रश्नको उत्तर दिन्छन्: सफल लगइनले ब्लक फराकिलो बनाउन सक्दैन, र राम्रो डेटा साइफरले गलत सर्भरमा विश्वास गर्ने बहाना दिँदैन।

जाँच नयाँ जडानमा वार्ता भएको साइफर फेरि पढेर र पुरानो साइफर अब स्वीकार नगरिने पुष्टि गरेर बन्द गर्नुहोस्। कुनै पक्षले अझै त्यो प्रस्ताव गर्छ भने माइग्रेसन पूरा भएको छैन, अर्कोतर्फको प्रोफाइलले जे भने पनि।