OpenVPN EC বনাম ED: নামগুলো কেন শক্তির সিঁড়ি নয়
EC, ED, ECDHE আর auth ভিন্ন ভিন্ন প্রশ্নের উত্তর দেয়। কিছু তুলনা বা সম্পাদনা করার আগে প্রতিটি নাম যে কাজ করে সেই অনুযায়ী OpenVPN প্রোফাইল সাজান।
একটি প্রোফাইলে ec, ed, ecdh, ecdsa, auth এবং একটি TLS সাইফার তালিকা পাশাপাশি রাখুন, আর ফাইলটি ছয়টি অবস্থানের একটি শক্তি-চাকা মনে হতে শুরু করে। কিন্তু তা নয়। প্রতিটি নাম ভিন্ন প্রশ্নের উত্তর দেয়, এবং যেসব প্রোফাইল এগুলোর একটিতে আলাদা, তারা অপরিহার্যভাবে একে অপরের চেয়ে বেশি বা কম শক্তিশালী নয়। নামগুলোকে তাদের কাজ অনুযায়ী সাজাতে প্রায় পাঁচ মিনিট লাগে এবং কাজ করা কনফিগারেশনে মানুষ যে খারাপ সম্পাদনা করে তার বেশিরভাগ প্রতিরোধ করে।
নিচের বাছাই বিভ্রান্তি থেকেই শুরু হয়, তারপর বাইরের দিকে এগোয় প্রোফাইলের সেই অংশগুলোর দিকে যেগুলো আসলে ঠিক করে কী আপনার ট্রাফিক রক্ষা করে। প্রতিটি অনুচ্ছেদে একটি করে ভুল পাঠ নেয় এবং দেখায় নামটি আসলে কীসের সাথে যুক্ত।
দুটি অক্ষর, দুটি আলাদা প্রশ্ন
সবচেয়ে বেশি বিতর্ক তৈরি করে EC আর ED, আর বিতর্ক সাধারণত ধরে নেয় এরা একই প্রশ্নের প্রতিদ্বন্দ্বী উত্তর। এরা তো একই অক্ষেও নেই। EC বর্ণনা করে গণিতের একটি পরিবার: উপবৃত্তীয়-বক্ররেখা ক্রিপ্টোগ্রাফি, যেখানে নিরাপত্তা আসে বড় সসীম ক্ষেত্রের বদলে বক্ররেখার উপর বিচ্ছিন্ন লগারিদমের কঠিনতা থেকে।
ED সেই পরিবারের ভেতরের একটি বক্ররেখার আকৃতি বর্ণনা করে। Twisted Edwards বক্ররেখা হলো গতি এবং কয়েকটি বাস্তবায়ন ভুলের বিরুদ্ধে প্রতিরোধের জন্য বেছে নেওয়া একটি উপস্থাপনা, আর Ed25519 হলো সেই নাম যা মানুষ সাধারণত বোঝায়। বক্ররেখাটি উপবৃত্তীয়-বক্ররেখা ক্রিপ্টোগ্রাফির প্রতিদ্বন্দ্বী নয়; এটি উপবৃত্তীয় বক্ররেখা লেখার একটি উপায়। ED-কে "নতুন, শক্তিশালী EC" হিসেবে পড়া হলো প্রথম ভুল মোড়, আর তার পরের সবকিছু একই দিকে ভুল হতে থাকে।
স্বাক্ষর করা আর বিনিময় করা আলাদা কাজ
পরিবারের প্রশ্ন নিষ্পত্তি হলে বাকি নামগুলো দুটি স্তম্ভে ভাগ হয়, যারা কখনো একে অপরের বিকল্প হয় না। একটি স্তম্ভ স্বাক্ষর করে, অন্যটি একটি ভাগ করা গোপন তথ্যে একমত হয়।
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA আর ECDSA দুটোই স্বাক্ষর করে, কিন্তু এরা ভিন্ন কী ফরম্যাটের ভিন্ন স্কিম, তাই একটির জন্য জারি করা সনদ অন্যটি হিসেবে ব্যবহার করা যায় না। EdDSA অল্প কিছু বক্ররেখার জন্য সংজ্ঞায়িত; P-256 তার একটি নয়, এজন্যই P-256 সনদ ECDSA দিয়ে যাচাই হয় এবং কখনো Ed25519 দিয়ে নয়।
বিনিময় স্তম্ভে EdDH নামে কোনো সমতুল্য নেই। Curve25519 কী-তে ক্ষণস্থায়ী সম্মতি হলো X25519, এবং সেটি নির্দিষ্ট একটি বক্ররেখাসহ ECDH, ঠিক যেমন P-256-এর সাথে। Ed25519 কঠোরভাবে স্বাক্ষর স্কিম বোঝায়, যদিও দুটি বক্ররেখা সম্পর্কিত হওয়ায় নামটি বিনিময়ের জন্য ঢিলেঢালাভাবে ব্যবহৃত হয়: স্বাক্ষরের জন্য ব্যবহৃত Edwards রূপ আর X25519-এর জন্য ব্যবহৃত Montgomery রূপ একই অন্তর্নিহিত গ্রুপ বর্ণনা করে।
কেন EC প্রোফাইলে dh ফাইল থাকে না
dh ফাইলে সসীম-ক্ষেত্র Diffie-Hellman-এর জন্য আগে থেকে তৈরি প্যারামিটার থাকে, আর সেই প্যারামিটারগুলো থাকে কারণ একটি বড় মৌলিক সংখ্যা আর একটি জেনারেটরকে কোথাও থেকে আসতে হয়। উপবৃত্তীয়-বক্ররেখার বিনিময়ে সেগুলো লাগে না: নামযুক্ত বক্ররেখাই প্যারামিটারের সেট, আর দুই পক্ষই তা আগেই জানে। এটাই সেই পুরো কারণ যার জন্য একটি EC প্রোফাইল নির্দেশিকাটি বাদ দিতে পারে।
অন্যথায় আধুনিক দেখতে একটি প্রোফাইলে এখনো দুটি পরিস্থিতি dh লাইন তৈরি করে। প্রথমটি হলো দ্বিতীয় শ্রোতা বা পুরোনো সহকর্মী যা সত্যিই সসীম-ক্ষেত্র গ্রুপ নিয়ে দরকষাকষি করে। দ্বিতীয়টি হলো RSA যুগের টেমপ্লেট থেকে কপি করা এবং কখনো না সরানো অবশিষ্ট লেখা। যে প্রোফাইল বিনিময়ের জন্য একটি বক্ররেখার নাম দেয় আর তবুও 2048-বিট dh ফাইল লোড করে, সেটি তা করার কারণে বেশি নিরাপদ নয়; এটি একটি অব্যবহৃত নিদর্শন বহন করছে।
TLS 1.3 নাম থেকে কী বিনিময় সরিয়ে দিয়েছে
TLS_AES_256_GCM_SHA384-এর সাথে TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 তুলনা করুন, আর ছোট নামটি অবনতি মনে হয়। এটি পুনর্নামকরণ, আর কারণটি কাঠামোগত: TLS 1.3 স্থির RSA আর সসীম-ক্ষেত্র Diffie-Hellman কী বিনিময় সরিয়ে দিয়েছে, তাই ক্ষণস্থায়ী উপবৃত্তীয়-বক্ররেখার বিনিময়ই একমাত্র অবশিষ্ট অ-PSK বিকল্প। প্রতিটি স্যুটে এর নাম দেওয়া একই তথ্য ডজনবার পুনরাবৃত্তি করত।
সনদের ধরনটি সম্পর্কিত কারণে নাম থেকে অদৃশ্য হয়ে গেছে। 1.3-এ সনদ হ্যান্ডশেক স্বাক্ষরকে প্রমাণ করে, কী চুক্তিকে নয়, তাই এটি আর স্যুট নির্বাচন করে না। সেজন্যই কনফিগারেশনে 1.3-এর জন্য আলাদা সাইফার তালিকা আছে: স্যুটগুলো পুনর্নামকরণ ও পুনর্বিন্যাস করা হয়েছে, দুর্বল করা হয়নি।
একটি পরিণতি সরাসরি বলা দরকার। ECDHE একটি কী-বিনিময় অ্যালগরিদম এবং কখনোই সাইফার নয়। "উপবৃত্তীয়" হিসেবে বর্ণিত একটি স্যুট দুই পক্ষ কীভাবে একটি ভাগ করা কী-তে পৌঁছাল সে সম্পর্কে কিছু বলে, আর তারপর পেলোড কী এনক্রিপ্ট করে সে সম্পর্কে কিছুই বলে না।
auth প্যাকেট প্রমাণ করে, পেলোড নয়
auth নির্দেশিকা সেই HMAC ডাইজেস্ট বেছে নেয় যা প্যাকেট প্রমাণ করে, আর এর ঐতিহাসিক ডিফল্ট SHA1। অ-AEAD ডেটা সাইফারে OpenVPN সাইফারটেক্সটের উপর ডাইজেস্ট গণনা করে তা যোগ করে, এটি একটি এনক্রিপ্ট-তারপর-MAC ব্যবস্থা যা প্যাডিং নিয়ে কারসাজি অকার্যকর করে।
এখানে মিথ হলো auth কে SHA512-এ বাড়ালে টানেল শক্ত হয়। এটি এনক্রিপশনের শক্তি বাড়ায় না, আর দরকষাকষি করা ডেটা সাইফার যদি AES-256-GCM-এর মতো AEAD মোড হয়, তবে ডাইজেস্ট ডেটা প্যাকেটে একেবারেই প্রয়োগ হয় না। GCM ট্যাগ ইতিমধ্যে সেগুলো প্রমাণ করে, আর auth মান নিয়ন্ত্রণ-চ্যানেলের HMAC এবং এখনো ব্যবহৃত যেকোনো অ-AEAD সাইফারের জন্য রেখে দেওয়া হয়।
তাই নির্দেশিকাটি গুরুত্বপূর্ণ, কিন্তু ফাইলে তার অবস্থান যা ইঙ্গিত করে তার চেয়ে সংকীর্ণ জায়গায় গুরুত্বপূর্ণ। কোন সাইফার আসলে দরকষাকষি হয়েছে তা দেখা আপনাকে বলে এটি আদৌ প্রযোজ্য কি না।
র্যাংক দিয়ে নয়, স্তম্ভ দিয়ে প্রোফাইল পড়ুন
তিনটি প্রশ্ন স্তরগুলোকে পরিষ্কারভাবে আলাদা করে, আর প্রতিটির উত্তর দেয় দরকষাকষি করা সেশনের ভিন্ন একটি অংশ। কোন সাইফার পেলোড রক্ষা করে? কোন ট্যাগ বা ডাইজেস্ট প্রতিটি প্যাকেটের জামিন হয়, আর ব্যবহৃত সাইফার আদৌ এমন একটি দরকার করে কি? কার সনদ হ্যান্ডশেক বন্ধ করল, আর নিয়ন্ত্রণ-চ্যানেল কি অতিরিক্তভাবে tls-auth বা tls-crypt দিয়ে সুরক্ষিত?
EC বা ED লেবেলে কিছুই ওই তিনটির কোনোটিই নিষ্পত্তি করে না, আর একটি স্যুট নাম একা নিজেও তাদের কোনোটিই নিষ্পত্তি করে না। দরকষাকষি করা ফলাফলই একমাত্র প্রমাণ, তাই শব্দভাণ্ডার থেকে শক্তি অনুমান না করে সেটিই পড়ুন:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logপ্রথম কমান্ড আপনাকে বলে আপনার সনদ আসলে কোন স্বাক্ষর স্কিম ব্যবহার করে, আর আপনি ECDSA না Ed25519 চালাচ্ছেন তা জানার এটিই একমাত্র নির্ভরযোগ্য উপায়। দ্বিতীয়টি ক্লায়েন্ট সেশনের জন্য যে নিয়ন্ত্রণ-চ্যানেল লাইন লগ করেছে তা দেখায়, যার মধ্যে TLS সংস্করণ আর যে স্যুটে এটি থেমেছে তা রয়েছে। কোনো প্রোফাইল সম্পাদনা যদি ওই দুটি আউটপুটের একটিও দিয়ে যুক্তিসঙ্গত না হয়, তবে এটি সম্ভবত কোনো বৈশিষ্ট্যের বদলে একটি নামের পরিবর্তন।