लांब 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 की काहीही महत्त्वाचे बदलत नाही, आणि एका क्लायंटवर नवीन निर्देशाचा अंदाज लावणे हा कार्यरत बोगदा खराब बोगदा होण्याचा मार्ग आहे। उर्वरित ताफ्याला स्पर्श करण्यापूर्वी एका क्लायंटवर आणि एका सर्व्हरवर बदल तपासा। जुने प्रोफाइल परत जाण्यासाठी उपलब्ध ठेवा जोपर्यंत नवीन सिफर पूर्ण कनेक्शन चक्र पार करत नाही।

बदलादरम्यान प्रमाणपत्र पडताळणी आणि खाते प्रमाणीकरण टिकवून ठेवा। ते वेगवेगळ्या प्रश्नांची उत्तरे देतात: यशस्वी लॉगिन ब्लॉक रुंद करू शकत नाही, आणि चांगला डेटा सिफर चुकीच्या सर्व्हरवर विश्वास ठेवण्याचे कारण ठरत नाही।

तपासणी नवीन कनेक्शनवर वाटाघाटी झालेला सिफर पुन्हा वाचून आणि नंतर जुना सिफर स्वीकारला जात नाही याची पुष्टी करून बंद करा। एखादा पक्ष तो अजूनही सुचवत असल्यास, स्थलांतर पूर्ण झाले नाही, दुसऱ्या बाजूचे प्रोफाइल काहीही म्हणो।