০৪ মে, ২০২৫·8 মিনিট
DJB এবং নির্মাণভিত্তিক নিরাপত্তা: qmail থেকে Curve25519
ড্যানিয়েল জে. বার্নস্টাইনের নির্মাণভিত্তিক নিরাপত্তা ধারণা—qmail থেকে Curve25519 পর্যন্ত—এবং বাস্তবে “সরল, যাচাইযোগ্য ক্রিপ্টো” কী বোঝায় তার একটি ব্যবহারিক বিশ্লেষণ।
ড্যানিয়েল জে. বার্নস্টাইনের নির্মাণভিত্তিক নিরাপত্তা ধারণা—qmail থেকে Curve25519 পর্যন্ত—এবং বাস্তবে “সরল, যাচাইযোগ্য ক্রিপ্টো” কী বোঝায় তার একটি ব্যবহারিক বিশ্লেষণ।
নির্মাণভিত্তিক নিরাপত্তা মানে এমনভাবে একটি সিস্টেম তৈরি করা যাতে সাধারণ ভুল করা কঠিন হয়—এবং অনিবার্য ভুলের ক্ষতি সীমিত থাকে। দীর্ঘ একটি চেকলিস্টের ওপর ("X ভ্যালিডেশন করো, Y স্যানিটাইজ করো, Z কনফিগার করো…") নির্ভর করার বদলে আপনি সফটওয়্যারটি এমনভাবে ডিজাইন করেন যাতে সবচেয়ে নিরাপদ পথটিই সবচেয়ে সহজ পথ হয়।
এটি শিশু-সুরক্ষিত প্যাকেজিংয়ের মতো: এটা ধরে নেয় না যে সবাই পরিপূর্ণভাবে সাবধানে চলবে; বরং ধরে নেয় মানুষ ক্লান্ত, ব্যস্ত এবং কখনও কখনও ভুল করবে। ভালো ডিজাইন ডেভেলপার, অপারেটর, এবং ব্যবহারকারীদের কাছ থেকে প্রয়োজনীয় "পারফেক্ট ব্যবহারের" পরিমাণ কমিয়ে দেয়।
নিরাপত্তার সমস্যা প্রায়ই জটিলতায় লুকিয়ে থাকে: অতিরিক্ত ফিচার, অপশন, বা কম্পোনেন্টগুলোর মধ্যে বেশি ইন্টারঅ্যাকশন। প্রতিটি অতিরিক্ত নবলই নতুন ব্যর্থতার পথ তৈরি করতে পারে—সিস্টেম ভাঙার বা মিসইউজ করার অপ্রত্যাশিত উপায়।
সরলতা বাস্তবে দুইভাবে সহায়ক:
এটা নিজের জন্য মিনি মালিজম নয়—এটি এমন আচরণগুলির সেটকে ছোট রাখার ব্যাপার যাতে আপনি তা বাস্তবে বুঝতে, টেস্ট করতে এবং কোনো ভুল হলে কী ঘটে তা যুক্তি করতে পারেন।
এই লেখাটি Daniel J. Bernstein-এর কাজকে নির্মাণভিত্তিক নিরাপত্তার কিছু বাস্তব উদাহরণ হিসেবে ব্যবহার করে: কিভাবে qmail ব্যর্থতার মোডগুলো কমানোর চেষ্টা করেছে, কনস্ট্যান্ট-টাইম চিন্তাভাবনা কীভাবে অদৃশ্য লিক এড়ায়, এবং কিভাবে Curve25519/X25519 ও NaCl এমন ক্রিপ্টো দিকে ঠেলে দেয় যা ভুল ব্যবহার করা কঠিন।
এটি যা করবে না: সম্পূর্ণ ক্রিপ্টোগ্রাফির ইতিহাস দেব, অ্যালগরিদমগুলো প্রমাণ করবে নিরাপদ, বা প্রতিটি প্রডাক্টের জন্য "একক শ্রেষ্ঠ" লাইব্রেরি দাবি করবে না। এবং এটা ভান করবে না যে ভাল প্রিমিটিভ সবকিছু সমাধান করে—বাস্তব সিস্টেমগুলো এখনও কী-হ্যান্ডলিং, ইন্টিগ্রেশন ভুল, এবং অপারেশনাল ফাঁকগুলির কারণে ব্যর্থ হয়।
লক্ষ্যটি সহজ: এমন ডিজাইন প্যাটার্ন দেখানো যা নিরাপদ ফলাফল হওয়ার সম্ভাবনা বাড়ায়, এমনকি আপনি ক্রিপ্টোগ্রাফি স্পেশালিস্ট না হলেও।
Daniel J. Bernstein (প্রায়ই "DJB") একজন গাণিতিক ও কম্পিউটার বিজ্ঞানী, যার কাজ বাস্তব নিরাপত্তা ইঞ্জিনিয়ারিংয়ে বারবার দেখা যায়: ইমেইল সিস্টেম (qmail), ক্রিপ্টোগ্রাফিক প্রিমিটিভ ও প্রটোকল (বিশেষ করে Curve25519/X25519), এবং বাস্তব-দুনিয়ার ব্যবহারের জন্য প্যাক করা লাইব্রেরি (NaCl)।
মানুষ DJB-কে উদ্ধৃত করেন কারণ তাঁর প্রকল্পগুলো একগঠিত ইঞ্জিনিয়ারিং প্রবৃত্তি শেয়ার করে যা ঘটনা ভাঙার উপায়গুলো কমায়—তাই নয় যে তিনি একমাত্র "ঠিক" উপায় লিখেছেন।
একটি পুনরাবৃত্ত থিম হচ্ছে ছোট, শক্ত ইন্টারফেস। যদি একটি সিস্টেম কম এন্ট্রি পয়েন্ট এবং কম কনফিগারেশন বিকল্প প্রকাশ করে, তা রিভিউ করা সহজ, টেস্ট করা সহজ, এবং ভুল ব্যবহার করা কঠিন।
আরও একটি থিম হচ্ছে স্পষ্ট অনুমান। নিরাপত্তা ব্যর্থতা প্রায়ই অখ্যাত প্রত্যাশা থেকে আসে—র্যান্ডমনেস, টাইমিং আচরণ, এরর হ্যান্ডলিং, বা কী কিভাবে স্টোর করা হয় সে সম্পর্কে। DJB-এর লেখালেখি ও বাস্তবায়নগুলো ঝুঁকি মডেলকে স্পষ্ট করে: কী কি রক্ষা করা হচ্ছে, কার থেকে, এবং কোন শর্তে।
শেষটায়, একটি ঝুকি রয়েছে নিরাপদ ডিফল্ট এবং বিরক্তিকর কোরেক্টনেস-এর প্রতি। এই ধারার অনেক ডিজাইন ধারালো ধারগুলো (ambiguous parameters, optional modes, performance shortcuts) সরিয়ে দেয় যাতে সূক্ষ্ম বাগগুলো হওয়া কঠিন হয়।
এই আর্টিকেলটি জীবনী নয় বা ব্যক্তিত্ব নিয়ে বিবাদ নয়। এটি একটি ইঞ্জিনিয়ারিং পাঠ: qmail, কনস্ট্যান্ট-টাইম চিন্তা, Curve25519/X25519, এবং NaCl-এ যে প্যাটার্ন দেখা যায় তা কিভাবে সেই প্যাটার্নগুলোকে এমন সিস্টেম বানাতে ব্যবহার করা যায় যা যাচাই করা সহজ এবং প্রোডাকশনে কম ভঙ্গুর।
qmail গঠিত হয়েছিল একটি খুবই মহার্ঘ্য কাজে: মেইল নির্ভরযোগ্যভাবে ডেলিভার করা, একই সময়ে মেইল সার্ভারকে একটি উচ্চ-মূল্যের টার্গেট হিসেবে দেখা। মেইল সিস্টেমগুলো ইন্টারনেটে স্থাপন থাকে, দিনে ভিন্নধর্মী ও শত্রুস্বভাবের ইনপুট গ্রহণ করে, এবং সংবেদনশীল ডেটা (মেসেজ, ক্রেডেনশিয়াল, রাউটিং নিয়ম) স্পর্শ করে। ঐতিহাসিকভাবে, একটি মনোলিথিক মেইল ডেমন-এ একটি বাগ পুরো সিস্টেম কমপ্রোমাইজ বা নিঃশব্দে মেসেজ লস ঘটাতে পারত—যা পরে অবশ্যই ধরা পড়ত না।
qmail-এর একটি মূল ধারণা হল "মেইল ডেলিভারি"-কে ছোট প্রোগ্রামে ভাগ করা যা প্রতিটি একটি কাজ করে: গ্রহণ, কিউইং, লোকাল ডেলিভারি, রিমোট ডেলিভারি ইত্যাদি। প্রতিটি অংশের একটি সংকীর্ণ ইন্টারফেস এবং সীমিত দায়িত্ব থাকে।
এই বিভাজনটি গুরুত্বপূর্ণ কারণ ব্যর্থতাগুলো লোকাল হয়:
এটি বাস্তব রূপে নির্মাণভিত্তিক নিরাপত্তা: সিস্টেমটি এমনভাবে ডিজাইন করুন যাতে "একটি ভুল" সহজে "মোটাল ফল ব্যর্থতা"তে পরিণত না হয়।
qmail কয়েকটি অভ্যাস দেখায় যা ইমেইলের বাইরেও ভাল কাজে লাগে:
সারমর্মি: “qmail ব্যবহার করো” নয়—এটা বোঝাতে যে আপনি প্রায়ই বড় সিকিউরিটি লাভ পেতে পারেন যদি আপনি অধিক কোড লেখার বা বেশি নবল যোগ করার আগে কম ব্যর্থতার মোড নিয়ে পুনরায় ডিজাইন করেন।
"অ্যাটাক সারফেস" হলো আপনার সিস্টেমে সব জায়গার সমষ্টি যেখানে কেউ টানতে বা ঠেলে সিস্টেমকে ভুল কাজ করাতে পারে। একটি বাড়ির তুলনা বিবেচনা করুন: প্রতিটি দরজা, জানালা, গ্যারেজ ওপনার, বাড়ির চাবি—সবই প্রবেশের সম্ভাব্য পথ। আপনি ভালো লক বসাতে পারেন, কিন্তু কম প্রবেশপথ রেখেও আপনি নিরাপদ থাকতে পারেন।
সফটওয়্যারেও একই কথা। আপনি যেই প্রতি পোর্ট খুলেন, ফাইল ফরম্যাট গ্রহণ করেন, অ্যাডমিন এন্ডপয়েন্ট প্রকাশ করেন, কনফিগারেশন নবল যোগ করেন, প্লাগিন হুক সাপোর্ট করেন—প্রতিটিই ব্যর্থতার নতুন উপায় বাড়ায়।
"টাইট ইন্টারফেস" এমন একটি API যা কম করে, কম ভ্যারিয়েশন নেয়, এবং অস্পষ্ট ইনপুট অস্বীকার করে। এটি সীমাবদ্ধ মনে হলেও—এটি নিরাপত্তার জন্য সহজ কারণ অডিট করার জন্য কম কোড পাথ থাকে এবং অপ্রত্যাশিত ইন্টারঅ্যাকশন কম থাকে।
দুটি ডিজাইনের তুলনা:
দ্বিতীয় ডিজাইন আক্রমণকারীরা কী ম্যানিপুলেট করতে পারে তা কমিয়ে দেয়। এটাই আপনার টিমের আকস্মিক মিসকনফিগার করার সুযোগও কমায়।
অপশনগুলো টেস্টিংকে গুণগতভাবে বাড়ায়। যদি আপনি 10টি টগল সাপোর্ট করেন, আপনি 10টি আচরণ পাচ্ছেন না—আপনার কাছে তাদের কম্বিনেশন আছে। অনেক সিকিউরিটি বাগ সেই সিমগুলোর মধ্যে থাকে: "এই ফ্ল্যাগ চেক বন্ধ করছে," "এই মোড ভ্যালিডেশন স্কিপ করছে," "এই লিগ্যাসি সেটিং রেট লিমিট বাইপাস করে।" টাইট ইন্টারফেস "চুজ-ইউর-ওন-অ্যাডভেঞ্চার সিকিউরিটি" কে একটি ভাল আলোয় দেখা পথ টার্ন করে।
এগুলো ব্যবহার করে এটাক সারফেস খুঁজুন:
যখন আপনি ইন্টারফেস ছোট করতে না পারেন, তা কঠোর করুন: আগে যাচাই করুন, অজানা ফিল্ড প্রত্যাখ্যান করুন, এবং "পাওয়ার ফিচারগুলো" আলাদা, স্পষ্ট স্কোপযুক্ত এন্ডপয়েন্টের পিছনে রাখুন।
"কনস্ট্যান্ট-টাইম" আচরণ মানে একটি কম্পিউটেশন গোপন মানগুলোর উপর নির্ভর করে (প্রাইভেট কি, নন্স, বা মধ্যবর্তী বিট) সময়ে (প্রায়) একই থাকে। লক্ষ্য দ্রুত হওয়া নয়; বরং নির্বিকার হওয়া: যদি আক্রমণকারী রানটাইমের সাথে গোপনগুলো কে কোরিলেট করতে না পারে, তাহলে গোপন বের করা অনেক কঠিন হয়ে ওঠে।
টাইমিং লিক গুরুত্বপূর্ণ কারণ আক্রমণকারীরা সবসময় গণিত ভাঙার প্রয়োজন অনুভব করে না। যদি তারা একই অপারেশন বহুবার চালাতে পারে (বা শেয়ার্ড হার্ডওয়্যারে সেটি পর্যবেক্ষণ করতে পারে), ক্ষুদ্রতম পার্থক্য — মাইক্রোসেকেন্ড, ন্যানোসেকেন্ড, এমনকি ক্যাশ এফেক্ট—ও প্যাটার্ন প্রকাশ করতে পারে যা গোপন উদ্ধারে পরিণত হয়।
সাধারণ কোডও ডেটার ওপর ভিত্তি করে ভিন্ন আচরণ করতে পারে:
if (secret_bit) { ... } কন্ট্রোল ফ্লো এবং সাধারণত রানটাইম বদলে দেয়।আপনাকে অ্যাসেম্বলি পড়তে হবে না:
if স্টেটমেন্ট, অ্যারে ইনডেক্স, সিক্রেট-ভিত্তিক টার্মিনেশন লুপ, এবং "ফাস্ট পাথ/স্লো পাথ" লজিক।কনস্ট্যান্ট-টাইম চিন্তাভাবনা নায়কত্ব নয়—এটি শৃঙ্খলা: কোড এমনভাবে ডিজাইন করুন যাতে গোপন টাইমিংকে পরিচালিত করতে না পারে।
এলিপটিক-কার্ভ কী এক্সচেঞ্জ হল একটি উপায় যাতে দুই ডিভাইস একই শেয়ার করা সিক্রেট তৈরি করে এমনকি তারা কেবল "পাবলিক" মেসেজই নেটওয়ার্কে পাঠায়। প্রতিটি পক্ষ একটি প্রাইভেট মান (গোপন) এবং সংশ্লিষ্ট পাবলিক মান (পাঠানোর জন্য নিরাপদ) তৈরি করে। পাবলিক মান বিনিময় করার পরে, উভয় পক্ষ তাদের নিজস্ব প্রাইভেট মান অধিৎ অন্যান্য পক্ষের পাবলিক মান মিলিয়ে একই শেয়ার করা সিক্রেট হিসাব করে। ইভেসড্রপার পাবলিক মানগুলো দেখে, কিন্তু শেয়ার করা সিক্রেট পুনর্গঠন কার্যত অসম্ভব, তাই উভয় পক্ষপরে এনক্রিপশন কী ডিরাইভ করে গোপনভাবে কথা বলতে পারে।
Curve25519 হল আন্ডারলিং কার্ভ; X25519 হল তার উপর নির্মিত স্ট্যান্ডার্ডাইজড "এই কাজটি কর" কী-এক্সচেঞ্জ ফাংশন। তাদের আকর্ষণ মূলত নির্মাণভিত্তিক সুরক্ষা: কম ফুটগান, কম প্যারামিটার নির্বাচন, এবং নিরাপদ সেটিং ভুল করে বেছে নেওয়ার কম উপায়।
এগুলো অধিকাংশ হার্ডওয়্যারে দ্রুত; সার্ভার যা প্রচুর কানেকশন হ্যান্ডেল করে বা ফোন যা ব্যাটারি বাঁচায়—দু'দিকেই তা জরুরি। এবং ডিজাইন এমন বাস্তবায়নকে উৎসাহ দেয় যা কনস্ট্যান্ট-টাইম রাখা সহজ, ফলে টাইমিং আক্রমণ প্রতিহত করা সহজ হয়।
X25519 আপনাকে কী-এগ্রিমেন্ট দেয়: দুটি পক্ষকে শেয়ার করা সিক্রেট ডিরাইভ করতে সাহায্য করে।
এটি নিজে থেকে অথেনটিকেশন দেয় না। যদি আপনি X25519 চালান কিন্তু কাকে আপনি কথা বলছেন সেটা যাচাই না করেন (উদাহরণস্বরূপ সার্টিফিকেট, সিগনেচার, বা প্রিশেয়ার্ড কী দিয়ে), তবে আপনি এখনও ভুল পক্ষের সঙ্গে নিরাপদভাবে কথা বলার ফাঁদে পড়তে পারেন। অর্থাৎ: X25519 জারণ-রোধে সহায়ক, কিন্তু নিজে থেকে নকল-প্রতিরোধ করে না।
NaCl ("Networking and Cryptography library") এর নির্মাণমূল লক্ষ্য ছিল: অ্যাপ ডেভেলপাররা অনিচ্ছাকৃতভাবে অনিরাপদ ক্রিপ্টো জোড়া না দিতে পারে। বাফেতে বিভিন্ন অ্যালগরিদম, মোড, প্যাডিং নিয়ম, এবং কনফিগারেশন নবল দেওয়ার বদলে, NaCl আপনাকে এমন উচ্চ-স্তরের অপারেশন দেয় যা আগে থেকেই নিরাপদভাবে সংযোজিত।
NaCl-এর API-র নামগুলো আপনি কী করতে চান তার ওপর ভিত্তি করে—নো কি প্রিমিটিভ কোথায় লাগবে তার ওপর নয়।
crypto_box ("box"): পাবলিক-কী অথেন্টিকেটেড এনক্রিপশন। আপনি এতে আপনার প্রাইভেট কী, রিসিপিয়েন্টের পাবলিক কী, একটি নন্স, ও একটি মেসেজ দেন। আউটপুট হয় একটি সাইফারটেক্সট যা (ক) মেসেজ লুকায় এবং (খ) প্রমাণ করে যে তা সঠিক কী জ্ঞানকারীর কাছ থেকে এসেছে।crypto_secretbox ("secretbox"): শেয়ারড-কী অথেন্টিকেটেড এনক্রিপশন। ধারণাটি একই, কিন্তু একটি শেয়ারড সিক্রেট কী ব্যবহার করে।মূল সুবিধা হল আপনি আলাদাভাবে "এনক্রিপশন মোড" ও "MAC অ্যালগরিদম" বেছে নিয়ে এগুলো সঠিকভাবে একত্র না করে দিন—NaCl-এর ডিফল্টস আধুনিক, মিসইউজ-রেসিস্টেন্ট কম্পোজিশন (encrypt-then-authenticate) জোর দেয়, তাই সাধারণ ব্যর্থতাগুলো—যেমন ইন্টিগ্রিটি চেক ভুলে যাওয়া—অনেকটাই বন্ধ হয়ে যায়।
NaCl-এর কড়াকড়ি যদি আপনাকে লিগ্যাসি প্রটোকল, বিশেষ ফরম্যাট, বা নিয়ন্ত্রক-নির্দিষ্ট অ্যালগরিদ্মের সাথে সামঞ্জস্য রাখতে বাধ্য করে, তাহলে তা সীমাবদ্ধ মনে হতে পারে। আপনি "প্রতিটি প্যারামিটার টিউন করতে পারি" এর বদলে "ক্রিপ্টো বিশেষজ্ঞ না হয়েই কিছু নিরাপদ চালানো যায়" বেছে নিচ্ছেন।
অনেক প্রডাক্টের জন্য, এটিই মূল উদ্দেশ্য: ডিজাইন স্পেসকে সংকুচিত করে যাতে প্রথম থেকেই কম বাগ থাকতে পারে। যদি সত্যিই কাস্টমাইজেশন দরকার, আপনি নিম্ন-স্তরের প্রিমিটিভে নামতে পারেন—কিন্তু তখন আপনি ফের সেই ধারালো কিনারায় ফিরে এসেছেন।
"ডিফল্ট হিসেবে নিরাপদ" মানে আপনার কিছু না করলেই সবচেয়ে যুক্তিসঙ্গত ও নিরাপদ অপশনটাই পাওয়া যায়। যদি একটি ডেভেলপার একটি লাইব্রেরি ইনস্টল করে, একটি দ্রুত উদাহরণ কপি করে, বা ফ্রেমওয়ার্ক ডিফল্ট ব্যবহার করে, ফলাফলটি মিসইউজ করা কঠিন ও আকস্মিকভাবে দুর্বল করা কঠিন হওয়া উচিত।
ডিফল্টস গুরুত্বপূর্ণ কারণ বাস্তব সিস্টেমগুলোর অধিকাংশই সেগুলো চালায়। টিম দ্রুত কাজ করে, ডকুমেন্টেশন হালকা পড়া হয়, এবং কনফিগারেশন জৈবভাবে বাড়ে। যদি ডিফল্ট "ফ্লেক্সিবল" হয়, তা প্রায়ই "কনফিগার করা সহজ" থেকে "মিসকনফিগার করা সহজ"-এ পরিণত হয়।
ক্রিপ্টো ব্যর্থতা সবসময় "ম্যাথ খারাপ ছিল" না। প্রায়ই সে কারণ হয় একটি বিপজ্জনক সেটিং বেছে নেওয়া কারণ এটি উপলব্ধ, পরিচিত, বা সহজ ছিল।
সাধারণ ডিফল্ট ফাঁদগুলো:
যেসব স্ট্যাক নিরাপদ পাথটিকে সবচেয়ে সহজ করে সেগুলো পছন্দ করুন: যাচাই করা প্রিমিটিভ, সংরক্ষণশীল প্যারামিটার, এবং এমন API যা আপনাকে ভঙ্গুর সিদ্ধান্ত নিতে বলছে না। যদি একটি লাইব্রেরি আপনাকে দশটি অ্যালগরিদ্ম, পাঁচটি মোড, এবং একাধিক এনকোডিং বেছে নিতে বলছে, আপনি কনফিগারেশন দ্বারা সিকিউরিটি ইঞ্জিনিয়ারিং করতে বাধ্য হচ্ছেন।
যখন সম্ভব, এমন লাইব্রেরি ও ডিজাইন বেছে নিন যা:
নির্মাণভিত্তিক নিরাপত্তা আংশিকভাবে প্রত্যেক সিদ্ধান্তকে ড্রপডাউন বানিয়ে দেওয়া থেকে বিরত থাকারই নাম।
"যাচাইযোগ্য" মানে প্রডাক্ট টিমগুলোর বেশিরভাগ ক্ষেত্রে "ফর্মালি প্রমাণিত" নয়। এর মানে হলো আপনি দ্রুত, পুনরাবৃত্তভাবে, এবং কম ভুল বোঝাবুঝির সঙ্গে আস্থা স্থাপন করতে পারেন।
একটি কোডবেস তখন আরও যাচাইযোগ্য হয় যখন:
প্রতিটি শাখা, মোড, ও ঐচ্ছিক ফিচার রিভিউয়ারকে বেশি কিছু নিয়ে ভাবতে বাধ্য করে। সরল ইন্টারফেস সম্ভাব্য রাষ্ট্রগুলোর সেটকে সংকুচিত করে, যা রিভিউ মানে উন্নতি করে:
নিরবচল এবং পুনরাবৃত্তি করবেন:
এই সংমিশ্রণ এক্সপার্ট রিভিউ প্রতিস্থাপন করবে না, কিন্তু মেঝে উপরে তুলবে: কম অপ্রত্যাশ্যতা, দ্রুত সনাক্তকরণ, এবং_code_ বাস্তবে যুক্তি করা যায় এমন কোড।
যদি আপনি X25519 বা NaCl-শৈলীর "box"/"secretbox" মতো ভাল প্রিমিটিভ বেছে নেন তবুও সিস্টেমগুলো ইন্টিগ্রেশন, এনকোডিং, ও অপারেশনে গলদ খায়। রিয়েল-ওয়ার্ল্ড_INCIDENT_গুলো সাধারণত "গণিত ভুল ছিল" না বরং "গণিত ভুলভাবে ব্যবহার করা হয়েছে"।
কী হ্যান্ডলিং ভুল সাধারণ: দীর্ঘমেয়াদী কী যেখানে ক্ষণস্থায়ী কী দরকার, কীগুলো সোর্স কন্ট্রোলে রাখা, বা "পাবলিক কী" ও "সিক্রেট কী" বাইট স্ট্রিংগুলোর মধ্যে গলতি করা—কারণ তারা দুটোই শুধু অ্যারে।
নন্স মিসইউজ বারবার অপরাধী। অনেক অথেন্টিকেটেড-এনক্রিপশন স্কিম প্রতিটি কী-এর নিচে ইউনিক নন্স দাবি করে। নন্স ডুপ্লিকেট করা (কাউন্টার রিসেট, মাল্টি-প্রকেস রেস, বা "র্যান্ডম যথেষ্ট" অনুমান) করলে গোপনীয়তা বা ইন্টিগ্রিটি হারাতে পারেন।
এনকোডিং ও পার্সিং সমস্যা নিঃশব্দ ব্যর্থতা তৈরি করে: base64 বনাম hex বিভ্রান্তি, লিডিং জিরো ফেলে দেওয়া, এন্ডিয়ানিটির অসামঞ্জস্য—এসব বাগ "ভেরিফাই করা সিগনেচার"কে অন্যকিছুকে ভেরিফাই করেছে এমন করে দিতে পারে।
এরর হ্যান্ডলিং উভয় দিকেই বিপজ্জনক হতে পারে: আক্রমণকারীর জন্য সহায়ক বিস্তারিত ফিরিয়ে দেওয়া, অথবা ভেরিফিকেশন ব্যর্থতা উপেক্ষা করে চলা।
গোপনশব্দ লিক হয় লগ, ক্র্যাশ রিপোর্ট, অ্যানালিটিক্স, ও "ডিবাগ" এন্ডপয়েন্টগুলোর মাধ্যমে। কীগুলো এছাড়া ব্যাকআপ, VM ইমেজ, এবং অত্যধিক শেয়ার করা পরিবেশ ভ্যারিয়েবল-এ পড়ে। পাশাপাশি ডিপেন্ডেন্সি আপডেট (বা না-থাকার ফলে) আপনাকে দুর্বল বাস্তবায়নে আটকে রাখতে পারে যদিও ডিজাইনটা ভালো ছিল।
ভাল প্রিমিটিভ স্বয়ংক্রিয়ভাবে নিরাপদ প্রডাক্ট তৈরি করে না। আপনি যত বেশি সিদ্ধান্ত উন্মুক্ত করবেন—মোড, প্যাডিং, এনকোডিং, কাস্টম টুইক—তত বেশি আপনার টিম দুর্ঘটনাক্রমে ভঙ্গুর কিছু তৈরি করতে পারে। নির্মাণভিত্তিক নিরাপত্তার একটি পথ শুরু হয় এমন একটি ইঞ্জিনিয়ারিং পথ বেছে নিয়ে যা সিদ্ধান্তের পয়েন্টগুলো কমায়।
একটি উচ্চ-স্তরের লাইব্রেরি (ওয়ান-শট API যেমন: "এই মেসেজটা ঐ রিসিপিয়েন্টের জন্য এনক্রিপ্ট কর") ব্যবহার করুন যখন:
নীচ-স্তরের প্রিমিটিভ (AEADs, হ্যাশ, কী এক্সচেঞ্জ) কম্পোজ করুন যখন:
উপকারী নিয়ম: যদি আপনার ডিজাইন ডকুমেন্টে "মোড পরে বেছে নেব" বা "নন্স নিয়ে আমরা কেবল সাবধানে থাকব" লেখা থাকে, আপনি ইতিমধ্যে বেশি নবল রাখার মূল্য ভোগ করছেন।
বাজারি ভাষা নয়, cụত উত্তর চান:
Security-by-construction এমনভাবে সফটওয়্যার ডিজাইন করা যাতে সবচেয়ে নিরাপদ পাথটিই সবচেয়ে সহজ পাথ হয়। মানুষকে লম্বা চেকলিস্ট মনে রাখার ওপর নির্ভর করার পরিবর্তে, আপনি সিস্টেমকে এমনভাবে সীমাবদ্ধ করেন যাতে সাধারণ ভুল করা কঠিন হয় এবং অনিবার্য ভুলের ক্ষতি সীমিত (কম “ব্লাস্ট রেডিয়াস”) রাখা যায়।
জটিলতা লুকোনো ইন্টারঅ্যাকশন এবং এজ কেস তৈরি করে যা টেস্ট করা কঠিন এবং ভুল কনফিগার করা সহজ।
প্রায়োগিক সুবিধাগুলো:
একটি টাইট ইন্টারফেস কম করে এবং কম ভ্যারিয়েশন গ্রহণ করে। এটি অস্পষ্ট ইনপুট এড়ায় এবং ঐ অপশনগুলো থেকে উদ্ভুত “সিকিউরিটি বাই কনফিগারেশন” ঝুঁকি কমায়।
প্রায়োগিক পদ্ধতি:
qmail মেইল হ্যান্ডলিংকে ছোট ছোট প্রোগ্রামে ভাগ করে (গ্রহণ, কিউ, ডেলিভারি ইত্যাদি), প্রতিটি ন্যারো রেসপনসিবিলিটির সঙ্গে। এর ফলে:
কনস্ট্যান্ট-টাইম আচরণ মানে রানটাইম (এবং প্রায়শই মেমরি অ্যাকসেস প্যাটার্ন) গোপন মানগুলির উপর নির্ভর না করে একই ধরনের সময় নেয়। এটি গুরুত্বপূর্ণ কারণ আক্রমণকারীরা অনেক বার অপারেশন চালিয়ে সময় পরিমাপ করে গোপন উন্মোচন করতে পারে—কনস্ট্যান্ট-টাইম থাকা সেই ধরনের "অদৃশ্য লিক" আটকায়।
এটি শুধুই শক্ত অ্যালগরিদম বাছাই করার ব্যাপার নয়; বাইনারি বা লজিক লেভেলে/runtime পারফরম্যান্সে গোপনকে প্রভাবিত না করার ব্যাপার।
প্রশ্নটি: কোন জায়গায় গোপন প্রভাব ফেলে তা চিহ্নিত করে, তারপর সেই জায়গায় খুঁজুন যেখানে গোপন ধরে নিয়েই কন্ডিশনাল কন্ট্রোল ফ্লো বা মেমরি অ্যাকসেস আছে।
সতর্ক সংকেত:
if শাখাএছাড়া আপনার ক্রিপ্টো ডিপেন্ডেন্সিগুলোর ডকুমেন্টে যাচাই করুন যে তারা যে অপারেশনগুলোর জন্য কনস্ট্যান্ট-টাইম দাবী করে তা স্পষ্ট আছে কিনা।
X25519 হল Curve25519-এর উপরে তৈরী একটি স্ট্যান্ডার্ডাইজড কী-এগ্রিমেন্ট ফাংশন। এটি "ফুটগান" কমায়: কম প্যারামিটার বাছাই করতে হয়, ভাল পারফরম্যান্স, এবং কনস্ট্যান্ট-টাইম বাস্তবায়ন সহজ করে—অতএব ভুল ব্যবহার কম সম্ভাব্য।
এটিকে কী-এক্সচেঞ্জের জন্য একটি নিরাপদ ডিফল্ট হিসাবে বিবেচনা করা যায়—তবে আপনি এখনও অথেনটিকেশন ও কী ম্যানেজমেন্ট ঠিক রাখতে হবে।
না। X25519 কেবল কী-এগ্রিমেন্ট দেয় (শেয়ার করা সিক্রেট), কিন্তু সেটা থেকে নিজে থেকেই অপর पक्षকে অথেনটিকেট করা যায় না।
ভু
NaCl প্রধান উদ্দেশ্য ছিল—অ্যাপ ডেভেলপাররা ভুল করে অনিরাপদ ক্রিপ্টো গঠন না করতে পারে। এটি অনেক অপশন না দিয়ে আপনাকে উচ্চ-স্তরের অপারেশন দেয় যা সুরক্ষিতভাবে একসঙ্গে বোনা থাকে।
উপকারিতা: আপনি আলাদাভাবে "এনক্রিপশন মোড" ও "MAC অ্যালগরিদম" না বাছাই করে নিরাপদ কম্পোজিশন পেয়ে যান।
ভাল প্রিমিটিভ ব্যবহার করলেও সিস্টেম ত্রুটির শিকার হয় যখন ইন্টিগ্রেশন ও অপারেশন স্লপি হয়। সাধারণ সমস্যা:
প্রতিকার: