DJB এবং নির্মাণভিত্তিক নিরাপত্তা: qmail থেকে Curve25519

নির্মাণভিত্তিক নিরাপত্তা মানে কী (জার্গন ছাড়াই)

নির্মাণভিত্তিক নিরাপত্তা মানে এমনভাবে একটি সিস্টেম তৈরি করা যাতে সাধারণ ভুল করা কঠিন হয়—এবং অনিবার্য ভুলের ক্ষতি সীমিত থাকে। দীর্ঘ একটি চেকলিস্টের ওপর ("X ভ্যালিডেশন করো, Y স্যানিটাইজ করো, Z কনফিগার করো…") নির্ভর করার বদলে আপনি সফটওয়্যারটি এমনভাবে ডিজাইন করেন যাতে সবচেয়ে নিরাপদ পথটিই সবচেয়ে সহজ পথ হয়।

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

কেন সরলতা ঝুঁকি কমায়

নিরাপত্তার সমস্যা প্রায়ই জটিলতায় লুকিয়ে থাকে: অতিরিক্ত ফিচার, অপশন, বা কম্পোনেন্টগুলোর মধ্যে বেশি ইন্টারঅ্যাকশন। প্রতিটি অতিরিক্ত নবলই নতুন ব্যর্থতার পথ তৈরি করতে পারে—সিস্টেম ভাঙার বা মিসইউজ করার অপ্রত্যাশিত উপায়।

সরলতা বাস্তবে দুইভাবে সহায়ক:

• অডিট করার জন্য কম কোড: কম শাখা, কম বিশেষ কেস, কম লুকানো আচরণ।
• কম ভুল কনফিগার করার উপায়: একটিই নিরাপদ ডিফল্ট থাকলে দশটি "ফ্লেক্সিবল" বিকল্পের চেয়ে আকস্মিক অনিরাপত্তার সুযোগ কম থাকে।

এটা নিজের জন্য মিনিমালিজম নয়—এটি এমন আচরণগুলির সেটকে ছোট রাখার ব্যাপার যাতে আপনি তা বাস্তবে বুঝতে, টেস্ট করতে এবং কোনো ভুল হলে কী ঘটে তা যুক্তি করতে পারেন।

এই পোস্টটি কী কভার করে (আর কী করে না)

এই লেখাটি Daniel J. Bernstein-এর কাজকে নির্মাণভিত্তিক নিরাপত্তার কিছু বাস্তব উদাহরণ হিসেবে ব্যবহার করে: কিভাবে qmail ব্যর্থতার মোডগুলো কমানোর চেষ্টা করেছে, কনস্ট্যান্ট-টাইম চিন্তাভাবনা কীভাবে অদৃশ্য লিক এড়ায়, এবং কিভাবে Curve25519/X25519 ও NaCl এমন ক্রিপ্টো দিকে ঠেলে দেয় যা ভুল ব্যবহার করা কঠিন।

এটি যা করবে না: সম্পূর্ণ ক্রিপ্টোগ্রাফির ইতিহাস দেব, অ্যালগরিদমগুলো প্রমাণ করবে নিরাপদ, বা প্রতিটি প্রডাক্টের জন্য "একক শ্রেষ্ঠ" লাইব্রেরি দাবি করবে না। এবং এটা ভান করবে না যে ভাল প্রিমিটিভ সবকিছু সমাধান করে—বাস্তব সিস্টেমগুলো এখনও কী-হ্যান্ডলিং, ইন্টিগ্রেশন ভুল, এবং অপারেশনাল ফাঁকগুলির কারণে ব্যর্থ হয়।

লক্ষ্যটি সহজ: এমন ডিজাইন প্যাটার্ন দেখানো যা নিরাপদ ফলাফল হওয়ার সম্ভাবনা বাড়ায়, এমনকি আপনি ক্রিপ্টোগ্রাফি স্পেশালিস্ট না হলেও।

Daniel J. Bernstein কে এবং কেন মানুষ তাঁর কাজ উদ্ধৃত করে

Daniel J. Bernstein (প্রায়ই "DJB") একজন গাণিতিক ও কম্পিউটার বিজ্ঞানী, যার কাজ বাস্তব নিরাপত্তা ইঞ্জিনিয়ারিংয়ে বারবার দেখা যায়: ইমেইল সিস্টেম (qmail), ক্রিপ্টোগ্রাফিক প্রিমিটিভ ও প্রটোকল (বিশেষ করে Curve25519/X25519), এবং বাস্তব-দুনিয়ার ব্যবহারের জন্য প্যাক করা লাইব্রেরি (NaCl)।

মানুষ DJB-কে উদ্ধৃত করেন কারণ তাঁর প্রকল্পগুলো একগঠিত ইঞ্জিনিয়ারিং প্রবৃত্তি শেয়ার করে যা ঘটনা ভাঙার উপায়গুলো কমায়—তাই নয় যে তিনি একমাত্র "ঠিক" উপায় লিখেছেন।

ইঞ্জিনিয়াররা DJB-স্টাইল কাজ থেকে কী ধার করে

একটি পুনরাবৃত্ত থিম হচ্ছে ছোট, শক্ত ইন্টারফেস। যদি একটি সিস্টেম কম এন্ট্রি পয়েন্ট এবং কম কনফিগারেশন বিকল্প প্রকাশ করে, তা রিভিউ করা সহজ, টেস্ট করা সহজ, এবং ভুল ব্যবহার করা কঠিন।

আরও একটি থিম হচ্ছে স্পষ্ট অনুমান। নিরাপত্তা ব্যর্থতা প্রায়ই অখ্যাত প্রত্যাশা থেকে আসে—র্যান্ডমনেস, টাইমিং আচরণ, এরর হ্যান্ডলিং, বা কী কিভাবে স্টোর করা হয় সে সম্পর্কে। DJB-এর লেখালেখি ও বাস্তবায়নগুলো ঝুঁকি মডেলকে স্পষ্ট করে: কী কি রক্ষা করা হচ্ছে, কার থেকে, এবং কোন শর্তে।

শেষটায়, একটি ঝুকি রয়েছে নিরাপদ ডিফল্ট এবং বিরক্তিকর কোরেক্টনেস-এর প্রতি। এই ধারার অনেক ডিজাইন ধারালো ধারগুলো (ambiguous parameters, optional modes, performance shortcuts) সরিয়ে দেয় যাতে সূক্ষ্ম বাগগুলো হওয়া কঠিন হয়।

জীবনী নয়—ইঞ্জিনিয়ারিং দৃষ্টিকোণ

এই আর্টিকেলটি জীবনী নয় বা ব্যক্তিত্ব নিয়ে বিবাদ নয়। এটি একটি ইঞ্জিনিয়ারিং পাঠ: qmail, কনস্ট্যান্ট-টাইম চিন্তা, Curve25519/X25519, এবং NaCl-এ যে প্যাটার্ন দেখা যায় তা কিভাবে সেই প্যাটার্নগুলোকে এমন সিস্টেম বানাতে ব্যবহার করা যায় যা যাচাই করা সহজ এবং প্রোডাকশনে কম ভঙ্গুর।

qmail: কম ব্যর্থতার মোড ডিজাইন করার একটি ব্যবহারিক উদাহরণ

qmail গঠিত হয়েছিল একটি খুবই মহার্ঘ্য কাজে: মেইল নির্ভরযোগ্যভাবে ডেলিভার করা, একই সময়ে মেইল সার্ভারকে একটি উচ্চ-মূল্যের টার্গেট হিসেবে দেখা। মেইল সিস্টেমগুলো ইন্টারনেটে স্থাপন থাকে, দিনে ভিন্নধর্মী ও শত্রুস্বভাবের ইনপুট গ্রহণ করে, এবং সংবেদনশীল ডেটা (মেসেজ, ক্রেডেনশিয়াল, রাউটিং নিয়ম) স্পর্শ করে। ঐতিহাসিকভাবে, একটি মনোলিথিক মেইল ডেমন-এ একটি বাগ পুরো সিস্টেম কমপ্রোমাইজ বা নিঃশব্দে মেসেজ লস ঘটাতে পারত—যা পরে অবশ্যই ধরা পড়ত না।

কাজ ভাগ করে, ব্লাস্ট রেডিয়াস ছোট করা

qmail-এর একটি মূল ধারণা হল "মেইল ডেলিভারি"-কে ছোট প্রোগ্রামে ভাগ করা যা প্রতিটি একটি কাজ করে: গ্রহণ, কিউইং, লোকাল ডেলিভারি, রিমোট ডেলিভারি ইত্যাদি। প্রতিটি অংশের একটি সংকীর্ণ ইন্টারফেস এবং সীমিত দায়িত্ব থাকে।

এই বিভাজনটি গুরুত্বপূর্ণ কারণ ব্যর্থতাগুলো লোকাল হয়:

• যদি একটি কম্পোনেন্ট ক্র্যাশ করে, তা স্বয়ংক্রিয়ভাবে কিউকে করাপ্ট বা পুরো সিস্টেমকে ডাউন করে না।
• যদি একটি কম্পোনেন্টে সিকিউরিটি বাগ থাকে, আক্রমণকারী সাথে সাথেই অন্যান্য অংশগুলোর সকল প্রিভিলেজ পায় না।
• যদি আপনি একটি কম্পোনেন্টকে বিচ্ছিন্নভাবে যুক্তি করতে পারেন, তা বেশি কার্যকরভাবে টেস্ট ও অডিট করা যায়।

এটি বাস্তব রূপে নির্মাণভিত্তিক নিরাপত্তা: সিস্টেমটি এমনভাবে ডিজাইন করুন যাতে "একটি ভুল" সহজে "মোটাল ফল ব্যর্থতা"তে পরিণত না হয়।

অনুসরণীয় ডিজাইন অভ্যাস

qmail কয়েকটি অভ্যাস দেখায় যা ইমেইলের বাইরেও ভাল কাজে লাগে:

• পরিষ্কার সীমানা: একটি কম্পোনেন্ট কোন ইনপুট নেবে এবং কোন আউটপুট দেবে সেগুলো নির্দিষ্ট করুন। ছোট, স্পষ্ট চুক্তি প্রয়োগ করা সহজ।
• কঠোর ইনপুট হ্যান্ডলিং: নেটওয়ার্ক থেকে আসা সবকিছুকে সম্ভাব্য শত্রু হিসেবে বিবেচনা করুন; আগে যাচাই করুন, অদ্ভুত কেস প্রত্যাখ্যান করুন, এবং “সহায়ক” অনুমান এড়িয়ে চলুন।
• ডিফল্টভাবে লিস্ট-প্রিভিলেজ: কম্পোনেন্টগুলোকে কেবল তাদের প্রয়োজনীয় অনুমতিতেই চালান, যাতে একটি বাগ স্বয়ংক্রিয়ভাবে পুরো takeover-এ পরিণত না হয়।

সারমর্মি: “qmail ব্যবহার করো” নয়—এটা বোঝাতে যে আপনি প্রায়ই বড় সিকিউরিটি লাভ পেতে পারেন যদি আপনি অধিক কোড লেখার বা বেশি নবল যোগ করার আগে কম ব্যর্থতার মোড নিয়ে পুনরায় ডিজাইন করেন।

টাইট ইন্টারফেসের মাধ্যমে এটাক সারফেস কমানো

"অ্যাটাক সারফেস" হলো আপনার সিস্টেমে সব জায়গার সমষ্টি যেখানে কেউ টানতে বা ঠেলে সিস্টেমকে ভুল কাজ করাতে পারে। একটি বাড়ির তুলনা বিবেচনা করুন: প্রতিটি দরজা, জানালা, গ্যারেজ ওপনার, বাড়ির চাবি—সবই প্রবেশের সম্ভাব্য পথ। আপনি ভালো লক বসাতে পারেন, কিন্তু কম প্রবেশপথ রেখেও আপনি নিরাপদ থাকতে পারেন।

সফটওয়্যারেও একই কথা। আপনি যেই প্রতি পোর্ট খুলেন, ফাইল ফরম্যাট গ্রহণ করেন, অ্যাডমিন এন্ডপয়েন্ট প্রকাশ করেন, কনফিগারেশন নবল যোগ করেন, প্লাগিন হুক সাপোর্ট করেন—প্রতিটিই ব্যর্থতার নতুন উপায় বাড়ায়।

টাইট ইন্টারফেস: ছোট API, কম ব্যর্থতার মোড

"টাইট ইন্টারফেস" এমন একটি API যা কম করে, কম ভ্যারিয়েশন নেয়, এবং অস্পষ্ট ইনপুট অস্বীকার করে। এটি সীমাবদ্ধ মনে হলেও—এটি নিরাপত্তার জন্য সহজ কারণ অডিট করার জন্য কম কোড পাথ থাকে এবং অপ্রত্যাশিত ইন্টারঅ্যাকশন কম থাকে।

দুটি ডিজাইনের তুলনা:

• ওয়াইড ইন্টারফেস: "যেকোন ফাইল টাইপ আপলোড করো; আমরা ফরম্যাট ডিটেক্ট করব; ঐচ্ছিক কম্প্রেশন; ঐচ্ছিক এনক্রিপশন; ঐচ্ছিক মেটাডেটা; একাধিক অথ স্কীম।"
• টাইট ইন্টারফেস: "বাইট আপলোড করো; আপনাকে ছোট allowlist থেকে কনটেন্ট টাইপ ডিক্লেয়ার করতে হবে; সর্বোচ্চ সাইজ স্থির; এনক্রিপশন অভ্যন্তরীণভাবে হ্যান্ডেল করা হবে; একটি অথ পদ্ধতি।"

দ্বিতীয় ডিজাইন আক্রমণকারীরা কী ম্যানিপুলেট করতে পারে তা কমিয়ে দেয়। এটাই আপনার টিমের আকস্মিক মিসকনফিগার করার সুযোগও কমায়।

কেন কম অপশন নিরাপদ হতে পারে

অপশনগুলো টেস্টিংকে গুণগতভাবে বাড়ায়। যদি আপনি 10টি টগল সাপোর্ট করেন, আপনি 10টি আচরণ পাচ্ছেন না—আপনার কাছে তাদের কম্বিনেশন আছে। অনেক সিকিউরিটি বাগ সেই সিমগুলোর মধ্যে থাকে: "এই ফ্ল্যাগ চেক বন্ধ করছে," "এই মোড ভ্যালিডেশন স্কিপ করছে," "এই লিগ্যাসি সেটিং রেট লিমিট বাইপাস করে।" টাইট ইন্টারফেস "চুজ-ইউর-ওন-অ্যাডভেঞ্চার সিকিউরিটি" কে একটি ভাল আলোয় দেখা পথ টার্ন করে।

চেকলিস্ট: complexity কোথায় লুকায়

এগুলো ব্যবহার করে এটাক সারফেস খুঁজুন:

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

যখন আপনি ইন্টারফেস ছোট করতে না পারেন, তা কঠোর করুন: আগে যাচাই করুন, অজানা ফিল্ড প্রত্যাখ্যান করুন, এবং "পাওয়ার ফিচারগুলো" আলাদা, স্পষ্ট স্কোপযুক্ত এন্ডপয়েন্টের পিছনে রাখুন।

কনস্ট্যান্ট-টাইম চিন্তা: আপনি যা দেখতে পারেন না এমন লিক প্রতিরোধ করা

"কনস্ট্যান্ট-টাইম" আচরণ মানে একটি কম্পিউটেশন গোপন মানগুলোর উপর নির্ভর করে (প্রাইভেট কি, নন্স, বা মধ্যবর্তী বিট) সময়ে (প্রায়) একই থাকে। লক্ষ্য দ্রুত হওয়া নয়; বরং নির্বিকার হওয়া: যদি আক্রমণকারী রানটাইমের সাথে গোপনগুলো কে কোরিলেট করতে না পারে, তাহলে গোপন বের করা অনেক কঠিন হয়ে ওঠে।

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

কোথায় টাইমিং ভ্যারিয়েবিলিটি ঢুকে পড়ে

সাধারণ কোডও ডেটার ওপর ভিত্তি করে ভিন্ন আচরণ করতে পারে:

• গোপন ডেটায় শাখা: if (secret_bit) { ... } কন্ট্রোল ফ্লো এবং সাধারণত রানটাইম বদলে দেয়।
• গোপন দ্বারা ইনডেক্স করা টেবিল লুকআপ: সিক্রেট-নির্ভর ইনডেক্সগুলি আলাদা ক্যাশ লাইন টেনে আনে।
• ক্যাশ ও মেমরি ইফেক্ট: সিক্রেট-নির্ভর মেমরি অ্যাকসেস CPU ক্যাশ, পেজ ফল্ট, বা প্রিফেচিং-এর মাধ্যমে লিক করতে পারে।
• ভ্যারিয়েবল-টাইম ইন্সট্রুকশন: কিছু বড়-নাম্বার অপারেশন, ডিভিশন, বা আগাম-ছাড়া লুপ নির্দিষ্ট ইনপুটে বেশি সময় নিতে পারে।

টাইমিং ঝুঁকি অডিট করার উচ্চ-স্তরের উপায়

আপনাকে অ্যাসেম্বলি পড়তে হবে না:

1. সিক্রেট প্রভাব ট্রেস করুন: কোন ভ্যারিয়েবলগুলো সিক্রেট (প্রাইভেট কিজ, শেয়ারড সিক্রেট, অথ ট্যাগ) এবং সেগুলো কোথায় প্রবাহিত হচ্ছে তালিকা করুন।
2. রেড ফ্ল্যাগ খুঁজুন: সিক্রেট-নির্ভর if স্টেটমেন্ট, অ্যারে ইনডেক্স, সিক্রেট-ভিত্তিক টার্মিনেশন লুপ, এবং "ফাস্ট পাথ/স্লো পাথ" লজিক।
3. ডিপেন্ডেন্সিগুলোকে থ্রেট মডেলের অংশ ভাবুন: যাচাই করুন যে ক্রিপ্টো লাইব্রেরিগুলো সংশ্লিষ্ট অপারেশনের জন্য স্পষ্টভাবে কনস্ট্যান্ট-টাইম আচরণের দাবি করে কি না।
4. ভ্যারিয়েন্স টেস্ট করুন: বিভিন্ন সিক্রেট নিয়ে অপারেশন বহুবার চালিয়ে মাপুন; বড়, ধারাবাহিক পার্থক্য সতর্কতার ইঙ্গিত।

কনস্ট্যান্ট-টাইম চিন্তাভাবনা নায়কত্ব নয়—এটি শৃঙ্খলা: কোড এমনভাবে ডিজাইন করুন যাতে গোপন টাইমিংকে পরিচালিত করতে না পারে।

Curve25519 এবং X25519: এমন ক্রিপ্টো যা ভুল ব্যবহার করা কঠিন করে দেয়

এলিপটিক-কার্ভ কী এক্সচেঞ্জ হল একটি উপায় যাতে দুই ডিভাইস একই শেয়ার করা সিক্রেট তৈরি করে এমনকি তারা কেবল "পাবলিক" মেসেজই নেটওয়ার্কে পাঠায়। প্রতিটি পক্ষ একটি প্রাইভেট মান (গোপন) এবং সংশ্লিষ্ট পাবলিক মান (পাঠানোর জন্য নিরাপদ) তৈরি করে। পাবলিক মান বিনিময় করার পরে, উভয় পক্ষ তাদের নিজস্ব প্রাইভেট মান অধিৎ অন্যান্য পক্ষের পাবলিক মান মিলিয়ে একই শেয়ার করা সিক্রেট হিসাব করে। ইভেসড্রপার পাবলিক মানগুলো দেখে, কিন্তু শেয়ার করা সিক্রেট পুনর্গঠন কার্যত অসম্ভব, তাই উভয় পক্ষপরে এনক্রিপশন কী ডিরাইভ করে গোপনভাবে কথা বলতে পারে।

কেন Curve25519/X25519 জনপ্রিয় হয়েছে

Curve25519 হল আন্ডারলিং কার্ভ; X25519 হল তার উপর নির্মিত স্ট্যান্ডার্ডাইজড "এই কাজটি কর" কী-এক্সচেঞ্জ ফাংশন। তাদের আকর্ষণ মূলত নির্মাণভিত্তিক সুরক্ষা: কম ফুটগান, কম প্যারামিটার নির্বাচন, এবং নিরাপদ সেটিং ভুল করে বেছে নেওয়ার কম উপায়।

এগুলো অধিকাংশ হার্ডওয়্যারে দ্রুত; সার্ভার যা প্রচুর কানেকশন হ্যান্ডেল করে বা ফোন যা ব্যাটারি বাঁচায়—দু'দিকেই তা জরুরি। এবং ডিজাইন এমন বাস্তবায়নকে উৎসাহ দেয় যা কনস্ট্যান্ট-টাইম রাখা সহজ, ফলে টাইমিং আক্রমণ প্রতিহত করা সহজ হয়।

এটি কী করে—এবং কী করে না

X25519 আপনাকে কী-এগ্রিমেন্ট দেয়: দুটি পক্ষকে শেয়ার করা সিক্রেট ডিরাইভ করতে সাহায্য করে।

এটি নিজে থেকে অথেনটিকেশন দেয় না। যদি আপনি X25519 চালান কিন্তু কাকে আপনি কথা বলছেন সেটা যাচাই না করেন (উদাহরণস্বরূপ সার্টিফিকেট, সিগনেচার, বা প্রিশেয়ার্ড কী দিয়ে), তবে আপনি এখনও ভুল পক্ষের সঙ্গে নিরাপদভাবে কথা বলার ফাঁদে পড়তে পারেন। অর্থাৎ: X25519 জারণ-রোধে সহায়ক, কিন্তু নিজে থেকে নকল-প্রতিরোধ করে না।

NaCl-এর বড় ধারণা: কম বিকল্প, কম ভুল

NaCl ("Networking and Cryptography library") এর নির্মাণমূল লক্ষ্য ছিল: অ্যাপ ডেভেলপাররা অনিচ্ছাকৃতভাবে অনিরাপদ ক্রিপ্টো জোড়া না দিতে পারে। বাফেতে বিভিন্ন অ্যালগরিদম, মোড, প্যাডিং নিয়ম, এবং কনফিগারেশন নবল দেওয়ার বদলে, NaCl আপনাকে এমন উচ্চ-স্তরের অপারেশন দেয় যা আগে থেকেই নিরাপদভাবে সংযোজিত।

নিরাপদ বিল্ডিং ব্লক হিসেবে “box” এবং “secretbox”

NaCl-এর API-র নামগুলো আপনি কী করতে চান তার ওপর ভিত্তি করে—নো কি প্রিমিটিভ কোথায় লাগবে তার ওপর নয়।

• crypto_box ("box"): পাবলিক-কী অথেন্টিকেটেড এনক্রিপশন। আপনি এতে আপনার প্রাইভেট কী, রিসিপিয়েন্টের পাবলিক কী, একটি নন্স, ও একটি মেসেজ দেন। আউটপুট হয় একটি সাইফারটেক্সট যা (ক) মেসেজ লুকায় এবং (খ) প্রমাণ করে যে তা সঠিক কী জ্ঞানকারীর কাছ থেকে এসেছে।
• crypto_secretbox ("secretbox"): শেয়ারড-কী অথেন্টিকেটেড এনক্রিপশন। ধারণাটি একই, কিন্তু একটি শেয়ারড সিক্রেট কী ব্যবহার করে।

মূল সুবিধা হল আপনি আলাদাভাবে "এনক্রিপশন মোড" ও "MAC অ্যালগরিদম" বেছে নিয়ে এগুলো সঠিকভাবে একত্র না করে দিন—NaCl-এর ডিফল্টস আধুনিক, মিসইউজ-রেসিস্টেন্ট কম্পোজিশন (encrypt-then-authenticate) জোর দেয়, তাই সাধারণ ব্যর্থতাগুলো—যেমন ইন্টিগ্রিটি চেক ভুলে যাওয়া—অনেকটাই বন্ধ হয়ে যায়।

ট্রেড-অফ: কম অপশন বনাম নমনীয়তা

NaCl-এর কড়াকড়ি যদি আপনাকে লিগ্যাসি প্রটোকল, বিশেষ ফরম্যাট, বা নিয়ন্ত্রক-নির্দিষ্ট অ্যালগরিদ্মের সাথে সামঞ্জস্য রাখতে বাধ্য করে, তাহলে তা সীমাবদ্ধ মনে হতে পারে। আপনি "প্রতিটি প্যারামিটার টিউন করতে পারি" এর বদলে "ক্রিপ্টো বিশেষজ্ঞ না হয়েই কিছু নিরাপদ চালানো যায়" বেছে নিচ্ছেন।

অনেক প্রডাক্টের জন্য, এটিই মূল উদ্দেশ্য: ডিজাইন স্পেসকে সংকুচিত করে যাতে প্রথম থেকেই কম বাগ থাকতে পারে। যদি সত্যিই কাস্টমাইজেশন দরকার, আপনি নিম্ন-স্তরের প্রিমিটিভে নামতে পারেন—কিন্তু তখন আপনি ফের সেই ধারালো কিনারায় ফিরে এসেছেন।

সুরক্ষিত ডিফল্টস এবং অতিরিক্ত নবল-এর খরচ

"ডিফল্ট হিসেবে নিরাপদ" মানে আপনার কিছু না করলেই সবচেয়ে যুক্তিসঙ্গত ও নিরাপদ অপশনটাই পাওয়া যায়। যদি একটি ডেভেলপার একটি লাইব্রেরি ইনস্টল করে, একটি দ্রুত উদাহরণ কপি করে, বা ফ্রেমওয়ার্ক ডিফল্ট ব্যবহার করে, ফলাফলটি মিসইউজ করা কঠিন ও আকস্মিকভাবে দুর্বল করা কঠিন হওয়া উচিত।

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

কীভাবে ডিফল্টস ঝুঁকি গোপনভাবে তৈরি করে

ক্রিপ্টো ব্যর্থতা সবসময় "ম্যাথ খারাপ ছিল" না। প্রায়ই সে কারণ হয় একটি বিপজ্জনক সেটিং বেছে নেওয়া কারণ এটি উপলব্ধ, পরিচিত, বা সহজ ছিল।

সাধারণ ডিফল্ট ফাঁদগুলো:

• দুর্বল বা পূর্বানুমেয় র্যান্ডমনেস: নন-ক্রিপ্টোগ্রাফিক PRNG ব্যবহার, সীড পুনরায় ব্যবহার, বা কন্টেইনার/VM-এ কম-এন্ট্রপি উত্সে fallback করা। যদি কী জেনারেশন দুর্বল র‍্যান্ডমনেসের ওপর নির্ভর করে, তবে তার উপর সবকিছু দুর্বল হয়ে যায়।
• কম্প্যাটিবিলিটির জন্য পুরনো অ্যালগরিদম সক্রিয় রাখা: SHA-1, MD5, বা পুরোনো RSA সাইজগুলো "জাস্ট ইন কেস" রেখে দেওয়া এবং পরে দেখা যায় প্রোডাকশনে সেগুলো ব্যবহার হচ্ছে কারণ সিস্টেম ডাউনগ্রেড করেছে।
• কাস্টম বা অস্বাভাবিক মোড ও প্যারামিটার: ব্লক সাইফার মোড, প্যাডিং রুল, নন্স হ্যান্ডলিং বা ঘরোয়া স্কিমের অনেক নবল দেওয়া। অপশন যত বেশি, তত বেশি পথ যা সত্যিই এনক্রিপ্টেড মনে হয় কিন্তু নিরাপদ নয়।

বাস্তবসম্মত নিয়ম: কম অপশন, নিরাপদ ফলাফল

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

যখন সম্ভব, এমন লাইব্রেরি ও ডিজাইন বেছে নিন যা:

• আধুনিক, ব্যাপকভাবে রিভিউ করা অ্যালগরিদ্মকে ডিফল্ট করে
• ডিপ্রিকেটেড অপশনগুলো সরিয়ে দেয়, "অ্যাডভান্সড সেটিংস" -এর পিছনে লুকায় না
• অনিরাপদ অপারেশনগুলোকে অসম্ভব (বা অন্তত কষ্টকরভাবে স্পষ্ট) করে তোলে

নির্মাণভিত্তিক নিরাপত্তা আংশিকভাবে প্রত্যেক সিদ্ধান্তকে ড্রপডাউন বানিয়ে দেওয়া থেকে বিরত থাকারই নাম।

বাস্তব কোডে “সরল ও যাচাইযোগ্য” কেমন দেখায়

"যাচাইযোগ্য" মানে প্রডাক্ট টিমগুলোর বেশিরভাগ ক্ষেত্রে "ফর্মালি প্রমাণিত" নয়। এর মানে হলো আপনি দ্রুত, পুনরাবৃত্তভাবে, এবং কম ভুল বোঝাবুঝির সঙ্গে আস্থা স্থাপন করতে পারেন।

প্রায়োগিকভাবে “যাচাইযোগ্য” মানে কী হতে পারে

একটি কোডবেস তখন আরও যাচাইযোগ্য হয় যখন:

• রিডেবিলিটি বেশি: ছোট ফাংশন, স্পষ্ট নামকরণ, এবং মিনিমাল "ম্যাজিক"। একটি নতুন ইঞ্জিনিয়ারকে আপনি অসংকোচে প্রবাহ বোঝাতে পারবেন।
• পরিচিত-ভাল টেস্ট ভেক্টর আছে: ইনপুট দিলে আউটপুট স্থির ও ডক্সে আছে (ক্রিপ্টোতে বিশেষভাবে গুরুত্বপূর্ণ)। এগুলো দুর্ঘটনাজনিত পরিবর্তন ধরবে।
• বিল্ড পুনরুত্পন্নযোগ্য: একই সোর্স একই বাইনারি উৎপন্ন করে, তাই আপনি নিশ্চিত হতে পারেন যে যা রিভিউ হয়েছে তা চালানো হচ্ছে।
• অডিট সম্ভব: কম, কিন্তু সীমাবদ্ধ—অডিটররা গুরুত্বপূর্ণ পাথগুলো কভার করতে পারে বুনধে ডুব না দিয়ে।

কেন সরল কোডপাথ রিভিউ করা সহজ

প্রতিটি শাখা, মোড, ও ঐচ্ছিক ফিচার রিভিউয়ারকে বেশি কিছু নিয়ে ভাবতে বাধ্য করে। সরল ইন্টারফেস সম্ভাব্য রাষ্ট্রগুলোর সেটকে সংকুচিত করে, যা রিভিউ মানে উন্নতি করে:

1. রিভিউয়াররা কয়েকটি সিকিউরিটি-ক্রিটিক্যাল ফ্লোতে ফোকাস করতে পারে; এজ কেসের পিছনে ছায়া খেলা লাগে না।
2. কোনো কিছু "ভুল" লাগলে সেটা দ্রুত চোখে পড়ে (অপ্রত্যাশিত অ্যালোকেশন, ঝুঁকিপূর্ণ পার্সিং স্টেপ, টাইমিং-সেনসিটিভ তুলনা)।

আপনি গ্রহণ করতে পারেন এমন একটি লাইটওয়েট যাচাই ওয়ার্কফ্লো

নিরবচল এবং পুনরাবৃত্তি করবেন:

• টেস্টস: প্রত্যেক প্রিমিটিভের জন্য ইউনিট টেস্ট ও টেস্ট ভেক্টর যোগ করুন; প্রতিটি চেঞ্জে CI-তে চালান।
• রিভিউ: কী, র্যান্ডমনেস, সিরিয়ালাইজেশন, ও তুলনা স্পর্শ করা পরিবর্তনের জন্য সিকিউরিটি-ফোকাসড চেকলিস্ট বাধ্যতামূলক করুন।
• মনিটরিং: উচ্চ-স্তরের ব্যর্থতার কারণ লোগ করুন (গোপন নয়), ডিক্রিপ্ট/ভেরিফাই ব্যর্থতার স্পাইকগুলোতে অ্যালার্ট করুন, এবং ডিপেন্ডেন্সি ভার্শন ট্র্যাক করুন যাতে জানেন কখন ক্রিপ্টো কোড আপনার উপর পরিবর্তিত হয়েছে।

এই সংমিশ্রণ এক্সপার্ট রিভিউ প্রতিস্থাপন করবে না, কিন্তু মেঝে উপরে তুলবে: কম অপ্রত্যাশ্যতা, দ্রুত সনাক্তকরণ, এবং_code_ বাস্তবে যুক্তি করা যায় এমন কোড।

কোথায় ক্রিপ্টো সিস্টেম এখনও ব্যর্থ হয় (ভাল প্রিমিটিভ থাকা সত্ত্বেও)

যদি আপনি X25519 বা NaCl-শৈলীর "box"/"secretbox" মতো ভাল প্রিমিটিভ বেছে নেন তবুও সিস্টেমগুলো ইন্টিগ্রেশন, এনকোডিং, ও অপারেশনে গলদ খায়। রিয়েল-ওয়ার্ল্ড_INCIDENT_গুলো সাধারণত "গণিত ভুল ছিল" না বরং "গণিত ভুলভাবে ব্যবহার করা হয়েছে"।

ইন্টিগ্রেশন পিটফল (সাধারণ অপরাধী)

কী হ্যান্ডলিং ভুল সাধারণ: দীর্ঘমেয়াদী কী যেখানে ক্ষণস্থায়ী কী দরকার, কীগুলো সোর্স কন্ট্রোলে রাখা, বা "পাবলিক কী" ও "সিক্রেট কী" বাইট স্ট্রিংগুলোর মধ্যে গলতি করা—কারণ তারা দুটোই শুধু অ্যারে।

নন্স মিসইউজ বারবার অপরাধী। অনেক অথেন্টিকেটেড-এনক্রিপশন স্কিম প্রতিটি কী-এর নিচে ইউনিক নন্স দাবি করে। নন্স ডুপ্লিকেট করা (কাউন্টার রিসেট, মাল্টি-প্রকেস রেস, বা "র্যান্ডম যথেষ্ট" অনুমান) করলে গোপনীয়তা বা ইন্টিগ্রিটি হারাতে পারেন।

এনকোডিং ও পার্সিং সমস্যা নিঃশব্দ ব্যর্থতা তৈরি করে: base64 বনাম hex বিভ্রান্তি, লিডিং জিরো ফেলে দেওয়া, এন্ডিয়ানিটির অসামঞ্জস্য—এসব বাগ "ভেরিফাই করা সিগনেচার"কে অন্যকিছুকে ভেরিফাই করেছে এমন করে দিতে পারে।

এরর হ্যান্ডলিং উভয় দিকেই বিপজ্জনক হতে পারে: আক্রমণকারীর জন্য সহায়ক বিস্তারিত ফিরিয়ে দেওয়া, অথবা ভেরিফিকেশন ব্যর্থতা উপেক্ষা করে চলা।

অপারেশনাল পিটফল যা ভাল ক্রিপ্টোকে উল্টে দেয়

গোপনশব্দ লিক হয় লগ, ক্র্যাশ রিপোর্ট, অ্যানালিটিক্স, ও "ডিবাগ" এন্ডপয়েন্টগুলোর মাধ্যমে। কীগুলো এছাড়া ব্যাকআপ, VM ইমেজ, এবং অত্যধিক শেয়ার করা পরিবেশ ভ্যারিয়েবল-এ পড়ে। পাশাপাশি ডিপেন্ডেন্সি আপডেট (বা না-থাকার ফলে) আপনাকে দুর্বল বাস্তবায়নে আটকে রাখতে পারে যদিও ডিজাইনটা ভালো ছিল।

সাধারণ-মানুষের জন্য একটি মিটিগেশন চেকলিস্ট

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

আপনার প্রডাক্টের জন্য ক্রিপ্টো ইঞ্জিনিয়ারিং পন্থা নির্বাচন করা

ভাল প্রিমিটিভ স্বয়ংক্রিয়ভাবে নিরাপদ প্রডাক্ট তৈরি করে না। আপনি যত বেশি সিদ্ধান্ত উন্মুক্ত করবেন—মোড, প্যাডিং, এনকোডিং, কাস্টম টুইক—তত বেশি আপনার টিম দুর্ঘটনাক্রমে ভঙ্গুর কিছু তৈরি করতে পারে। নির্মাণভিত্তিক নিরাপত্তার একটি পথ শুরু হয় এমন একটি ইঞ্জিনিয়ারিং পথ বেছে নিয়ে যা সিদ্ধান্তের পয়েন্টগুলো কমায়।

একটি বাস্তব উপায় সিদ্ধান্ত নেওয়ার

একটি উচ্চ-স্তরের লাইব্রেরি (ওয়ান-শট API যেমন: "এই মেসেজটা ঐ রিসিপিয়েন্টের জন্য এনক্রিপ্ট কর") ব্যবহার করুন যখন:

• আপনার টিম ক্রিপ্টো উপরে নিয়োজিত নয়।
• আপনি নমনীয়তার চাইতে নিরাপদ ডিফল্ট (নন্স হ্যান্ডলিং, অথেন্টিকেশন, কী ফরম্যাট) চান।
• আপনি গ্লু কোড কম রাখতে চান যা পুনরায় ব্যর্থতার মোড ফিরিয়ে আনে।

নীচ-স্তরের প্রিমিটিভ (AEADs, হ্যাশ, কী এক্সচেঞ্জ) কম্পোজ করুন যখন:

• আপনার কাছে স্পষ্ট প্রটোকল স্পেসিফিকেশন ও ইন্টারঅপারেবিলিটি প্রয়োজন।
• আপনি রিভিউ, টেস্ট ভেক্টর, ও দীর্ঘমেয়াদি রক্ষণাবেক্ষণের দায়িত্ব নির্ধারণ করতে পারেন।
• আপনি নিশ্চিত যে আপনি আগেই বিদ্যমান কোনো প্রটোকল আবার তৈরি করছেন না।

উপকারী নিয়ম: যদি আপনার ডিজাইন ডকুমেন্টে "মোড পরে বেছে নেব" বা "নন্স নিয়ে আমরা কেবল সাবধানে থাকব" লেখা থাকে, আপনি ইতিমধ্যে বেশি নবল রাখার মূল্য ভোগ করছেন।

ভেন্ডর ও ইন্টারনাল টিমকে প্রশ্ন করা

বাজারি ভাষা নয়, cụত উত্তর চান:

• API ডিজাইন: API কি অনিরাপদ অবস্থাগুলোকে প্রতিনিধিত্ব করা কঠিন করে তোলে? নন্স সাইজ, কী সাইজ, এবং অ্যালগরিদম সংবিধিবদ্ধ কি?
• ডিফল্টস: ডেভেলপার শুধু কী ও প্লেইনটেক্সট দিলে কী ঘটে? এনক্রিপশন কি সর্বদা অথেন্টিকেটেড (AEAD) না কি আপনি আকস্মিকভাবে "এনক্রিপ্ট-অনলি" করতে পারবেন?
• সাইড-চ্যানেল অবস্থান: কোন অপারেশনগুলো কনস্ট্যান্ট-টাইম হিসেবে বিবেচিত? টাইমিং, ক্যাশ, ও ব্রাঞ্চ লিকেজের জন্য কি থ্রেট মডেল ধরা হয়েছে?
• কী ম্যানেজমেন্ট: কী কিভাবে জেনারেট, স্টোর, রোটেট, ও জিরো-াইজ করা হয়? কী ফরম্যাটগুলো স্পষ্ট ও ভার্শন্ড কি?
• অডিট ও রক্ষণাবেক্ষণ: সর্বশেষ স্বাধীন অডিট কখন করা হয়েছিল? ভঙ্গুরতা কিভাবে হ্যান্ডেল করা হয়? সিকিউরিটি-রিলেভেন্ট পরিবর্তনের চেঞ্জলগ আছে কি?