স্ট্যাটিক কী ফাইলের বিট সংখ্যা OpenVPN সাইফারের শক্তি নয়

একটি স্ক্যানার বা সহকর্মী OpenVPN স্ট্যাটিক কী ফাইলের ভেতরে ছাপা বিট সংখ্যাটি দেখিয়ে জিজ্ঞেস করে, টানেল কেন এই আকারের সাইফার ব্যবহার করছে না। প্রশ্নটি যুক্তিসঙ্গত শোনায়, আর উত্তরটি কোনো সংখ্যা নয়: ব্যানার সংরক্ষিত কী উপাদান গোনে, আর সাইফার কেবল তার কী আকারের প্রয়োজনীয় অংশটুকু খরচ করে। ওই মোটকে শক্তির সেটিং ধরে নিলে এমন সম্পাদনা হয় যা কিছুই বদলায় না। ফরম্যাটটি যেকোনো একক অ্যালগরিদমের ব্যবহারের চেয়ে বেশি উপাদান রাখার জন্য তৈরি।

এখানে দুটি প্রশ্ন মিশে যায়: ফাইলটি কতটা কী উপাদান সংরক্ষণ করে, এবং সমঝোতাকৃত সাইফার কতটা শক্তিশালী। কেবল দ্বিতীয়টি টানেলের বর্ণনা দেয়।

ব্যানারের সংখ্যাটি আসলে কী গোনে

কনটেইনারটি সাইফার উপাদান ও HMAC উপাদানকে আলাদা কাঠামো হিসেবে ক্রমবিন্যাস করে, আর দ্বিমুখী রূপটি এমন দুটি সেট রাখে যাতে প্রতিটি দিক নিজের কী বহন করতে পারে। লেখার কোডটি ক্রমবিন্যস্ত কাঠামোর সংখ্যা, তাদের আকার ও প্রতি বাইটে আট বিট থেকে ছাপা সংখ্যাটি বের করে। এটি সংরক্ষণের ওপর পাটিগণিত, এক সাইফার প্রতিটি সংরক্ষিত বাইট খরচ করে—এমন দাবি নয়। হেডারটি সাইফার উপাদানের সর্বোচ্চ বরাদ্দও স্থির করে, যাতে কোনো লাইব্রেরি পরিবর্তন নীরবে ফরম্যাটের আকার বদলাতে না পারে।

এটিকে সার্টিফিকেট কী-এর সঙ্গে তুলনা করুন, যেখানে বিট সংখ্যা সত্যিই একটি বস্তুর আকার বর্ণনা করে। 4,096 বিটের RSA কী আর যে কী ফাইলের ব্যানারে 4,096 বিট লেখা, তারা ভিন্ন কাজের ভিন্ন বস্তু, এবং তাদের একই ডায়ালের দুটি সেটিং হিসেবে সাজালে খারাপ সিদ্ধান্ত আসে।

এক ফাইলে দুটি কী সেট

ফাইলের প্রতিটি অর্ধেক এনক্রিপশন ও প্রমাণীকরণ উপাদান জোগায়, কারণ পূর্ব-ভাগাভাগি কী মোড ওই আলাদা টুকরোগুলো দিয়ে উভয় দিকে প্যাকেট রক্ষা করে। সক্রিয় সাইফার কেবল তার কী আকারের প্রয়োজনীয় বাইট ব্যবহার করে, আর ডাইজেস্ট নিজের আউটপুট আকার ব্যবহার করে, তাই ব্যবহারযোগ্য শক্তি আসে অপশন থেকে, ফাইলের দৈর্ঘ্য থেকে নয়। ষোড়শিক ব্লবটি বড় করলে কনফিগার করা অ্যালগরিদমকে তার বেশি খরচ করতে বলা হয় না। মন্তব্যটি বড় সংখ্যা দিয়ে সম্পাদনা করলে আরও কম বদলায়।

আপনি সত্যিই দীর্ঘতর কী চাইলে যে সেটিংটি বদলাতে হবে তা হলো সাইফার বা ডাইজেস্ট, আর জেনারেটর নির্বাচিত অ্যালগরিদমের যা প্রয়োজন তাই তৈরি করে।

প্রোফাইল পড়লে বোঝা যায় আপনার কোন মোড আছে

একই ফাইল ফরম্যাট দুটি বেশ আলাদা কাজে লাগে, আর কোনটি আপনার, তা কেবল প্রোফাইল বলে। একটি পুরোনো secret লাইন ফাইলটিকে টানেলের একমাত্র কী উপাদান করে, আর tls-auth বা tls-crypt এটিকে সার্টিফিকেটের পাশাপাশি কন্ট্রোল-চ্যানেল সুরক্ষা করে। কোনোটিই এটিকে ক্লায়েন্টের সার্টিফিকেট ব্যক্তিগত কী-তে পরিণত করে না, ব্লকটি যতই একরকম দেখাক। প্রতিস্থাপন তৈরির আগে অপশন ও সংস্করণ শনাক্ত করুন, এবং অক্ষর যোগ করার বদলে নথিভুক্ত জেনারেটর ব্যবহার করুন।

এই পার্থক্যই প্রকাশ পাওয়ার প্রতিক্রিয়া নির্ধারণ করে। ফাঁস হওয়া tls-auth কী সেশন কী প্রকাশ করে না, কিন্তু আক্রমণকারীকে কন্ট্রোল-চ্যানেল ট্র্যাফিক ঢোকানোর সুযোগ দেয়, তাই এটি বদলানো এখনও প্রয়োজন। ফাঁস হওয়া secret কী আরও খারাপ, কারণ এটি ছিল সেই উপাদান যা নিজে ডেটা রক্ষা করত।

নিরাপত্তা পর্যালোচনায় কী লিপিবদ্ধ করা উচিত

তিনটি জিনিস আলাদাভাবে লিপিবদ্ধ করুন: সমঝোতাকৃত ডেটা-চ্যানেল সুরক্ষা, কন্ট্রোল-চ্যানেল সুরক্ষা এবং সমকক্ষরা কীভাবে প্রমাণীকরণ করে। data-ciphers AES-256-GCM-এর মতো একটি লাইন কেবল প্রথমটির বর্ণনা দেয়, আর সেখানেই থেমে যাওয়া প্রতিবেদন কন্ট্রোল-চ্যানেল আদৌ সুরক্ষিত কি না তার উত্তর দিতে পারে না। স্ট্যাটিক কী ফাইলটি tls-auth বা tls-crypt-এর সঙ্গে ব্যবহার হলে দ্বিতীয় ঝুড়িতে পড়ে, আর ব্যবহার না হলে কোনোটিতেই নয়। যাঁরা ঝুড়িগুলো মিশিয়ে ফেলেন, তাঁরা শক্তিশালী সাইফার চাইলে বরং বড় কী ফাইল চেয়ে বসেন।

ফাইলটি প্রকাশ পেয়ে থাকলে অনুমোদিত চ্যানেল দিয়ে এটি ঘোরান ও পুনর্বণ্টন করুন। আপসকৃত গোপনীয়তায় অক্ষর যোগ করা ঘোরানো নয়, এবং এটি প্রকাশিত উপাদানকে বৈধই রাখে।

ঘোরানোর রেকর্ডটি যে প্রোফাইলের, তার সঙ্গেই রাখুন। পরের পর্যালোচনা জিজ্ঞেস করবে কোন কী কোন সময়কাল রক্ষা করেছিল, আর ব্যানার তার উত্তর দেবে না।