Cryptography-র সাধারণ ভুল — নিজে না বানানো, key management আর post-quantum

১ · নিজে বানাবেন না — Cryptography কেন আলাদা

পর্ব ০৮ থেকে পর্ব ১৩ পর্যন্ত আপনি ভালো হাতিয়ারগুলো চিনেছেন: AES, SHA-2, HMAC, RSA, TLS, Argon2. এই পর্বের প্রশ্ন অন্য। ভালো হাতিয়ার থাকার পরেও সিস্টেম ভাঙে কেন? তত্ত্বের ঝালাই চাইলে Computer Networks কোর্সের cryptography পর্ব দেখে নিতে পারেন।

Bruce Schneier ১৯৯৮ সালে এই কথাটিই বলেছিলেন, যা এখন Schneier’s Law নামে পরিচিত: যে কেউ এমন নিরাপত্তা-ব্যবস্থা বানাতে পারে, যা সে নিজে ভাঙতে পারে না। Roll your own crypto মানে ঠিক এই ফাঁদে পড়া। Cryptography-র ভুলের তিনটি বৈশিষ্ট্য একে সাধারণ bug থেকে আলাদা করে:

• ভুল চোখে পড়ে না। ভাঙা encryption-এর ফলও এলোমেলোই দেখায়। সব test পাস করে, কারণ decrypt করলে মূল লেখা ঠিকই ফেরে।
• প্রতিপক্ষ বুদ্ধিমান। সাধারণ bug এলোমেলো ইনপুটে ধরা পড়ে। নিরাপত্তার bug খোঁজেন এমন মানুষ, যিনি ঠিক দুর্বল জায়গাটিই খুঁজছেন।
• ক্ষতি দেরিতে জানা যায়। চুরি হওয়া ciphertext বছর পরে ভাঙলে আপনি কোনো alert-ই পাবেন না।

তাহলে কী ব্যবহার করবেন? নিচের তালিকা উদাহরণ, কোনো সুপারিশ নয়। আপনার ভাষা আর প্রয়োজন অনুযায়ী বর্তমান ডকুমেন্টেশন দেখে সিদ্ধান্ত নিন।

Library বাছার সময় পাঁচটি প্রশ্ন করুন: নিয়মিত আপডেট হয় কি? স্বাধীন audit হয়েছে কি? নিরাপত্তা-সমস্যা জানানোর পথ আছে কি? ডিফল্ট আচরণ নিরাপদ কি? ভুল ব্যবহার করলে error দেয়, না চুপ থাকে? আর যাচাই-না-করা package বসালে যে ঝুঁকি তৈরি হয়, সেটি পর্ব ৪৮-এর বিষয়।

২ · দশটি সাধারণ ভুল আর প্রতিটির সমাধান

এই তালিকাটি code review-র চেকলিস্ট হিসেবে ব্যবহার করতে পারেন। প্রতিটি সারিতে ভুলের ধারণা আর তার সমাধান আছে। কীভাবে কেউ এই ভুল কাজে লাগায়, সে ধাপ এই কোর্সে নেই। অন্যের সিস্টেমে এসব পরীক্ষা করা অনুমতি ছাড়া অপরাধ হতে পারে, তাই পর্ব ০৬ মনে রাখবেন।

কতবার random nonce নিরাপদ? একটি হিসাব

AES-GCM-এর nonce ৯৬ bit. এলোমেলো nonce নিলে দুটি মিলে যাওয়ার সম্ভাবনা birthday bound মেনে চলে। nটি message-এ সম্ভাবনা মোটামুটি n² / 2^97.

এজন্যই NIST SP 800-38D (২০০৭) এলোমেলো ৯৬-bit nonce-এ একই key দিয়ে encryption-এর সংখ্যা 2³²-এ সীমিত রাখে। খুব বেশি ডেটা হলে সমাধান key বদলানো, যা আমরা ৬ নম্বর অংশে দেখব। সঠিক ব্যবহার দেখতে সাধারণত এত ছোট:

# উদাহরণ (এই পাতায় চলবে না): Python cryptography package লাগে
import secrets
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

key = AESGCM.generate_key(bit_length=256)  # CSPRNG থেকে; বাস্তবে KMS থেকে আনুন
aead = AESGCM(key)
nonce = secrets.token_bytes(12)            # প্রতি message-এ নতুন
blob = aead.encrypt(nonce, b"hello", b"order-42")  # শেষে tag যুক্ত থাকে
text = aead.decrypt(nonce, blob, b"order-42")      # tag না মিললে InvalidTag

এবার ভুলগুলো চোখে ধরার অনুশীলন। নিচের খেলনা linter কোনো কোড চালায় না, শুধু ১২টি নকল লাইনের লেখা মিলিয়ে দেখে। প্রতিটি নিয়ম উপরের তালিকার এক একটি ভুল। Run চেপে দেখুন, তারপর কোনো লাইন বদলে আবার চালান।

// খেলনা linter: শুধু লেখা (string) মেলায়, কোনো কোড চালায় না। উদাহরণের নামগুলো কাল্পনিক।
const rules = [
  [/MODE_ECB/, 'ECB mode', 'use an AEAD: AES-GCM or ChaCha20-Poly1305'],
  [/nonce\s*=\s*b?["'0]/, 'fixed nonce', 'fresh nonce per message, or use a counter'],
  [/MODE_(CBC|CTR)/, 'no authentication', 'use an AEAD, not bare CBC or CTR'],
  [/random\.(randbytes|random|randint)|Math\.random/, 'non-CSPRNG key', 'use secrets or crypto.getRandomValues'],
  [/(KEY|SECRET|TOKEN)\w*\s*=\s*["']/i, 'hard-coded key', 'load from a KMS or secret manager'],
  [/\b(md5|sha1)\(/i, 'broken hash', 'use SHA-256; for passwords use Argon2id'],
  [/(tag|mac|token)\w*\s*==\s*\w/i, 'secret compared with ==', 'use hmac.compare_digest'],
  [/verify\s*=\s*False|rejectUnauthorized:\s*false/, 'certificate check off', 'keep verify on; fix the CA bundle'],
  [/decrypt\(.*;.*verify/, 'decrypt before tag check', 'verify first, or use an AEAD API'],
  [/TLSv1(_1)?\b(?!\.[23])|allow_downgrade/, 'downgrade option', 'set the minimum version to TLS 1.2 or 1.3'],
];
const code = [
  'cipher = AES.new(k, AES.MODE_ECB)',
  'nonce = b"000000000000"',
  'cipher = AES.new(k, AES.MODE_CBC, iv)',
  'k = random.randbytes(32)',
  'API_KEY = "example-token"',
  'digest = hashlib.md5(data).hexdigest()',
  'if tag == expected: accept()',
  'requests.get(url, verify=False)',
  'plain = decrypt(blob); verify_tag(blob)',
  'ctx.minimum_version = TLSv1_1',
  'nonce = secrets.token_bytes(12)',
  'key = kms.get_data_key("orders")',
];
let found = 0;
code.forEach((line, i) => {
  const hit = rules.find(([re]) => re.test(line));
  if (hit) { found++; console.log(`L${i + 1} ${hit[1]} -> ${hit[2]}`); }
  else console.log(`L${i + 1} ok`);
});
console.log(`${found} of ${code.length} lines flagged`);

L10 downgrade option -> set the minimum version to TLS 1.2 or 1.3
L11 ok
L12 ok
10 of 12 lines flagged

৩ · যে তথ্য অঙ্ক দিয়ে নয়, আচরণ দিয়ে ফাঁস হয়

এটাই side channel-এর ধারণা। গণিতে algorithm নিখুঁত হলেও বাস্তব যন্ত্র কাজ করার সময় বাইরে চিহ্ন রেখে যায়। Paul Kocher ১৯৯৬ সালে সময়ের ফাঁস নিয়ে আর ১৯৯৯ সালে সহকর্মীদের সাথে বিদ্যুৎ-খরচের ফাঁস নিয়ে যুগান্তকারী গবেষণা প্রকাশ করেন।

Constant-time অভ্যাস মানে সময় একেবারে সমান করা নয়। মানে কাজের সময় secret-এর মানের ওপর নির্ভর না করা। নিয়ম তিনটি: secret দেখে if নয়, secret দিয়ে array index নয়, আর secret-কে ভাগের মতো পরিবর্তনশীল-সময়ের নির্দেশে নয়। Compiler কোড বদলে দিতে পারে বলে এটি হাতে লেখা কঠিন। সেজন্য ভাষার দেওয়া function ব্যবহার করুন: Python hmac.compare_digest, Node crypto.timingSafeEqual, Go subtle.ConstantTimeCompare, Java MessageDigest.isEqual, PHP hash_equals.

নিচের কোড কোনো সময় মাপে না। এটি API বেছে নেওয়ার শিক্ষা: দুটি পদ্ধতির উত্তর একই, পার্থক্য তাদের প্রতিশ্রুতিতে। এখানে বসানো key নকল, শুধু উদাহরণ।

import hashlib, hmac

key = b"example-key-not-real"              # নকল key, শুধু উদাহরণ
msg = b"amount=500;to=rahim"
tag = hmac.new(key, msg, hashlib.sha256).digest()
print("tag starts:", tag.hex()[:16])

def verify(message, claimed):
    expected = hmac.new(key, message, hashlib.sha256).digest()
    return hmac.compare_digest(expected, claimed)   # == নয়

print("right tag :", verify(msg, tag))
print("changed   :", verify(b"amount=900;to=rahim", tag))
print("short tag :", verify(msg, tag[:8]))
print("== agrees :", (tag == tag[:8]) == hmac.compare_digest(tag, tag[:8]))

try:
    hmac.compare_digest("৳500", "৳500")      # non-ASCII str
except TypeError as err:
    print("TypeError :", err)
print("bytes ok  :", hmac.compare_digest("৳500".encode(), "৳500".encode()))

tag starts: 2f235f012327defd
right tag : True
changed   : False
short tag : False
== agrees : True
TypeError : comparing strings with non-ASCII characters is not supported
bytes ok  : True

Padding oracle আর “আগে যাচাই” নিয়ম

Padding oracle একটি ধারণা হিসেবে জানলেই চলবে। পুরোনো CBC mode-এ server যদি “padding ভুল” আর “tag ভুল”, এই দুই অবস্থায় আলাদা আচরণ করে, তবে সেই ছোট পার্থক্যটিই প্রশ্নের উত্তরদাতা (oracle) হয়ে যায়। Serge Vaudenay ২০০২ সালে CBC-র ক্ষেত্রে আর Daniel Bleichenbacher ১৯৯৮ সালে RSA padding-এর ক্ষেত্রে এই শ্রেণির সমস্যা প্রকাশ করেন। প্রতিরক্ষা কৌশল নয়, নকশা: AEAD ব্যবহার করুন, আর সব decrypt ব্যর্থতায় একই সাধারণ error দিন।

Moxie Marlinspike ২০১১ সালে একে “Cryptographic Doom Principle” নাম দেন: tag যাচাইয়ের আগে message-এর ওপর কোনো কাজ করলে, কোনো না কোনোভাবে বিপদ আসবেই। সেজন্য ক্রম সবসময় যাচাই → তারপর decrypt → তারপর ব্যবহার।

৪ · Key management — একটি key-এর জীবনচক্র

Kerckhoffs-এর নীতি (পর্ব ০৭) বলে, শুধু key গোপন থাকলেই সিস্টেম নিরাপদ থাকা উচিত। উল্টো করে ভাবলে, পুরো নিরাপত্তার ভার key-এর ওপর। Key management তাই crypto-র সবচেয়ে কঠিন বাস্তব কাজ। NIST SP 800-57 Part 1 (Rev. 5, ২০২০) এর প্রধান নির্দেশিকা। এর Rev. 6-এর খসড়া ডিসেম্বর ২০২৫-এ প্রকাশ হয়েছে, আর অক্টোবর ২০২৬-এ যাচাই করার সময় পর্যন্ত সেটি খসড়াই ছিল।

Cryptoperiod মানে একটি key কতদিন ব্যবহারের অনুমতি পাবে। উত্তর একটি নয়। এটি নির্ভর করে key কতটা ডেটা রক্ষা করে, ফাঁসের ক্ষতি কত, আর বদলাতে কতটা ঝামেলা, তার ওপর। SP 800-57 ধরনভেদে পরামর্শ দেয়। “এক বছরই সবসময় ঠিক” বলা ভুল হবে। Separation of duties-ও এখানে কাজে লাগে: key-এর প্রশাসক আর key-এর ব্যবহারকারী আলাদা মানুষ বা role হওয়া ভালো।

৫ · Envelope encryption, KMS আর HSM

Envelope encryption-এ data encrypt হয় DEK (Data Encryption Key) দিয়ে, আর DEK encrypt হয় KEK (Key Encryption Key) দিয়ে। এভাবে তৈরি হয় key hierarchy. এর চারটি সুবিধা: বড় data দ্রুত encrypt হয়, KEK কখনো বাইরে যায় না, প্রতিটি object আলাদা DEK পায় বলে blast radius ছোট থাকে, আর KEK ব্যবহারের প্রতিটি অনুরোধ log-এ ধরা পড়ে। Cloud-এ এর বাস্তব রূপ, খরচ আর caching Cloud & DevOps কোর্সের secrets ও KMS পর্বে আছে, তাই এখানে আমরা নীতিতেই থাকব।

KMS বনাম HSM: HSM (Hardware Security Module) একটি বিশেষ tamper-resistant যন্ত্র, যার ভেতরেই key তৈরি ও ব্যবহার হয়। FIPS 140-3 এর মতো মান দিয়ে এটি যাচাই করা যায়। KMS একটি সেবা বা সফটওয়্যার স্তর, যা permission, log আর rotation সামলায়, আর ভেতরে প্রায়ই HSM ব্যবহার করে। HSM মানেই নিরাপদ ব্যবহার নয়। যে কেউ HSM-কে DEK খুলে দিতে বলতে পারলে key বাইরে না গিয়েও ক্ষতি হয়। তাই permission আর log দুটিই সমান জরুরি।

এবার পুরো ধারণাটি নিজে চালান। নিচের cipher একটি XOR খেলনা, real নয়, শুধু ধারণার জন্য। Key-ও মাত্র ৪ byte, যাতে আউটপুট চোখে পড়ে।

// খেলনা envelope encryption: real নয়, শুধু ধারণার জন্য (XOR keystream)
function mulberry32(a){return()=>{a=a+0x6D2B79F5|0;let t=Math.imul(a^a>>>15,1|a);t=t+Math.imul(t^t>>>7,61|t)^t;return((t^t>>>14)>>>0)/4294967296}}
const rng=mulberry32(2026);
const newKey=()=>Array.from({length:4},()=>Math.floor(rng()*256));
const hex=b=>b.map(x=>x.toString(16).padStart(2,'0')).join('');
const stream=(data,key,nonce)=>{const r=mulberry32(key.reduce((s,b)=>s*257+b>>>0,nonce));return data.map(b=>b^Math.floor(r()*256))};
const bytes=s=>Array.from(s,c=>c.charCodeAt(0)), text=b=>String.fromCharCode(...b);

const kms={keys:{1:newKey()},active:1,n:0};           // KEK কখনো KMS-এর বাইরে যায় না
const wrap=dek=>{const v=kms.active,nonce=++kms.n;return{v,nonce,w:stream(dek,kms.keys[v],nonce)}};
const unwrap=e=>{if(!kms.keys[e.v])throw new Error('KEK v'+e.v+' destroyed');return stream(e.w,kms.keys[e.v],e.nonce)};
function seal(msg){const dek=newKey();return{data:stream(bytes(msg),dek,0),env:wrap(dek)}}
const open=o=>text(stream(o.data,unwrap(o.env),0));
const show=(tag,o)=>console.log(tag,'data='+hex(o.data),'wrappedDEK='+hex(o.env.w),'kek=v'+o.env.v);

const rec=seal('nid=example');
show('sealed :',rec);
console.log('open   :',open(rec));
const before=hex(rec.data);
kms.keys[2]=newKey(); kms.active=2;                   // নতুন KEK version
rec.env=wrap(unwrap(rec.env));                        // শুধু DEK নতুন করে মোড়ানো
show('rewrap :',rec);
console.log('data unchanged?',hex(rec.data)===before);
delete kms.keys[1];                                   // পুরোনো KEK ধ্বংস
console.log('open   :',open(rec));
delete kms.keys[2];                                   // শেষ KEK-ও ধ্বংস
try{open(rec)}catch(e){console.log('open   : FAILED,',e.message)}

sealed : data=37c32f1651c1ac7708f474 wrappedDEK=25e94f35 kek=v1
open   : nid=example
rewrap : data=37c32f1651c1ac7708f474 wrappedDEK=ae64bc26 kek=v2
data unchanged? true
open   : nid=example
open   : FAILED, KEK v2 destroyed

৬ · Key rotation — data না ছুঁয়ে চাবি বদল

Key rotation মানে নির্দিষ্ট সময় পরে বা কোনো ঘটনার পরে পুরোনো key-এর জায়গায় নতুন version আনা। এতে একটি key-তে রক্ষিত ডেটার পরিমাণ সীমিত থাকে, আর ফাঁস হলে ক্ষতির সময়ও ছোট হয়। নিচের stepper-এ ওপরের সেই record-টিই আছে, আর একটি rotation ধাপে ধাপে চলছে।

কত সস্তা? একটি হিসাব

ধরুন ১০ লাখ object, প্রতিটি ২ MB, আর গতি ধরে নেওয়া হলো ২০০ MB/s. প্রতিটি wrapped DEK ১০০ byte, আর KMS প্রতি সেকেন্ডে ১,০০০টি অনুরোধ নেয়। এই সব সংখ্যাই ধরে নেওয়া, কোনো পণ্যের মাপ নয়।

অনেক KMS-এ আরও সহজ পথ আছে: পুরোনো version decrypt-এর জন্য রেখে দেওয়া, আর record পড়ার সময় ধীরে ধীরে re-wrap করা।

ফাঁসের সন্দেহ হলে পরিকল্পিত rotation আর জরুরি বদলের পার্থক্য মনে রাখুন। জরুরি অবস্থায় আগে key-এর ব্যবহার বন্ধ, তারপর audit log দেখে প্রভাবের সীমা ঠিক করা, তারপর নতুন key আর দরকার হলে re-encrypt. পুরো প্রক্রিয়া পর্ব ৬১-এর incident response পরিকল্পনার অংশ হওয়া উচিত।

৭ · Crypto agility — আগামী বদলের জন্য আজকের নকশা

আজকের নিরাপদ algorithm একদিন বিদায় নেবে। MD5, SHA-1, DES, RC4, সবারই এটি ঘটেছে। Crypto agility মানে পুরো সিস্টেম নতুন করে না লিখে algorithm বদলাতে পারার ক্ষমতা। মোবাইল ব্যাংকিংয়ের PIN বদলাতে যেমন নতুন অ্যাকাউন্ট খুলতে হয় না, তেমনি algorithm বদলাতেও পুরো application লেখা উচিত নয়।

• তালিকা রাখুন। Cryptographic inventory ছাড়া migration শুরুই হয় না: কোন system, কোন algorithm, কোন key, কতদিনের ডেটা, কে মালিক।
• ডেটার সাথে version লিখুন। Ciphertext-এর শুরুতে format আর key-এর version থাকলে পুরোনো আর নতুন একসাথে চলতে পারে।
• এক জায়গায় রাখুন। সব crypto একটি ছোট wrapper-এর পেছনে থাকলে বদলাতে হবে এক জায়গায়, শত ফাইলে নয়।
• Test রাখুন। পুরোনো ডেটা পড়া আর নতুন algorithm-এ লেখা, দুটোরই automated test থাকুক।

৮ · Post-quantum — কী ভাঙবে, কী টিকবে

Post-quantum cryptography মানে এমন algorithm, যা সাধারণ কম্পিউটারেই চলে, কিন্তু বড় quantum computer-এর বিরুদ্ধেও নিরাপদ বলে মনে করা হয়। এটি “quantum কম্পিউটার দিয়ে encryption” নয়। ভয়ের কারণটি হলো দুটি algorithm:

একটি সহজ তুলনা। Shor যেন তালার ভেতরের নকশাটিই বুঝে ফেলা, তাই তালাটি বাতিল। Grover যেন একই চাবির গোছায় একটু দ্রুত হাত চালানো, তাই গোছা বড় হলেই চলে।

এজন্যই symmetric key-এর আকার খুব একটা চিন্তার বিষয় নয়। NIST IR 8547-এ বলা আছে, অন্তত ১২৮-bit ক্ল্যাসিক্যাল শক্তির সব অনুমোদিত symmetric primitive অন্তত Category 1-এর শর্ত পূরণ করে বলে মনে করা হয়। “AES-128 এখন অর্ধেক শক্তির, তাই অকেজো” কথাটি অতি সরলীকরণ।

নতুন মান: FIPS 203, 204, 205

NIST আট বছরের উন্মুক্ত প্রতিযোগিতার পর ১৩ আগস্ট ২০২৪ তারিখে তিনটি মান চূড়ান্ত করে।

তুলনার জন্য, X25519-এর public key মাত্র ৩২ byte আর Ed25519-এর signature ৬৪ byte. তাই সবচেয়ে বড় বাস্তব পরিবর্তন গণিতে নয়, আকারে। Handshake বড় হয়, certificate chain ভারী হয়, ছোট IoT যন্ত্রে জায়গা কমে। NIST ML-KEM-768-কে ডিফল্ট হিসেবে সুপারিশ করে। এছাড়া key স্থাপনের বিকল্প হিসেবে HQC মানের জন্য নির্বাচিত, আর FN-DSA (FIPS 206) খসড়া পর্যায়ে ছিল বলে জানা গেছে। এই দুটির অবস্থা ব্যবহারের আগে NIST-এর পাতায় দেখে নিন।

আজকের ঝুঁকি: আগে জমা, পরে খোলা

Harvest now, decrypt later মানে কেউ আজকের encrypted traffic জমা রাখছে, ভবিষ্যতে quantum computer এলে খুলবে বলে। মহল্লার পকেটমার আজই টাকা নেয়, কিন্তু এই চোর তালাবন্ধ সিন্দুকটিই তুলে নিয়ে যায়, পরে ভাঙবে বলে। ২০২৬ সালের শেষ পর্যন্ত এমন বড় quantum computer প্রকাশ্যে জানা নেই, আর কবে আসবে তা নিয়ে বিশেষজ্ঞদের মতভেদ আছে। তবু দীর্ঘদিন গোপন রাখার ডেটার জন্য ঝুঁকিটি আজকেরই, আর যা একবার জমা হয়ে গেছে তা আর ফেরানো যায় না।

Signature-এর হিসাব একটু আলাদা। আজকের signature আজ জাল হচ্ছে না, তাই “আগে জমা, পরে খোলা” এখানে সরাসরি খাটে না। কিন্তু দীর্ঘদিন বিশ্বাসযোগ্য থাকতে হয় এমন root key বা firmware key আগে বদলানো জরুরি, কারণ যন্ত্র একবার বিক্রি হলে তার ভেতরের বিশ্বাসের ভিত্তি বদলানো কঠিন।

Hybrid key exchange-এ একটি পুরোনো algorithm (যেমন X25519) আর একটি নতুন algorithm (ML-KEM) একসাথে চলে, আর দুটির ফল মিলিয়ে key বানানো হয়। একটি ভাঙলেও অন্যটি রক্ষা করে। আগস্ট ২০২৬-এ প্রকাশিত RFC 10024 TLS 1.3-এর জন্য এমন hybrid যেমন X25519MLKEM768 নির্দিষ্ট করেছে। এর client share ১২১৬ byte, যার ১১৮৪ byte ML-KEM আর ৩২ byte X25519.

NIST-এর সময়সূচি

NIST IR 8547-এর চূড়ান্ত রূপ অক্টোবর ২০২৬-এ প্রকাশ হয়েছে (নভেম্বর ২০২৪-এর খসড়ার পরে)। এটি মার্কিন federal ব্যবস্থার নথি, বাংলাদেশের কোনো প্রতিষ্ঠানের ওপর সরাসরি বাধ্যতামূলক নয়, তবে সারা বিশ্বের পণ্য ও মান এর সাথে তাল মেলায় বলে এটি একটি বাস্তব মাপকাঠি।

এখানে deprecated মানে ব্যবহার করা যায়, তবে ঝুঁকি মেপে সিদ্ধান্ত নিতে হয়। Disallowed মানে সেই কাজে আর অনুমোদিত নয়। IR 8547 আরও বলে, ব্যবহারভিত্তিক নির্দেশনা হয়তো key স্থাপনে এর আগেই migration চাইবে। আর SHA-1 FIPS-validated module-এ ২০৩০-এর পর নিষিদ্ধ হবে। এই তারিখগুলো ভবিষ্যতে বদলাতে পারে, তাই পরিকল্পনার সময় মূল নথি দেখুন।

৯ · একটি প্রতিষ্ঠানের post-quantum পরিকল্পনা

Michele Mosca-র একটি সহজ অসমতা (Mosca-র হিসাব, ২০১৫) পরিকল্পনাকে সংখ্যায় আনে। x = ডেটা কত বছর নিরাপদ থাকতে হবে, y = migration-এ কত বছর লাগবে, z = বড় quantum computer আসতে কত বছর।

উদাহরণ: ধরুন x = ১০, y = ৫, আর z = ১২ (ধরে নেওয়া সংখ্যা)। তাহলে x + y = ১৫, যা ১২-র চেয়ে বড়। অর্থাৎ ১৫ − ১২ = ৩ বছরের ডেটা ঝুঁকিতে থাকবে। z অনিশ্চিত, কিন্তু x আর y আপনার নিজের জানা সংখ্যা, আর সেখানেই আপনার হাত আছে।

এবার একটি কাল্পনিক ক্ষুদ্রঋণ প্রতিষ্ঠানের পাঁচটি system সাজাই। z = ১৫ একটি অনুমান মাত্র। মান বদলে আবার চালিয়ে দেখুন, ক্রম কতটা বদলায়।

// Mosca-র হিসাব: x = data কত বছর গোপন বা বিশ্বাসযোগ্য থাকতে হবে, y = migration-এর সময়।
// z = বড় quantum computer আসতে কত বছর: এটি ধরে নেওয়া সংখ্যা, কোনো পূর্বাভাস নয়।
const z = 15;
const systems = [
  { name: 'loan archive',    use: 'RSA key wrap', x: 25, y: 5 },
  { name: 'branch VPN',      use: 'ECDH',         x: 10, y: 3 },
  { name: 'website TLS',     use: 'ECDHE',        x: 2,  y: 1 },
  { name: 'firmware signing', use: 'ECDSA',       x: 15, y: 6 },
  { name: 'OTP codes',       use: 'HMAC only',    x: 0,  y: 0, symmetric: true },
];
const rows = systems
  .map(s => ({ ...s, gap: s.x + s.y - z }))
  .sort((a, b) => b.gap - a.gap);

console.log(`assumed z = ${z} years`);
for (const s of rows) {
  const verdict = s.symmetric ? 'no change needed'
    : s.gap > 0 ? `LATE by ${s.gap} years, start now`
    : `margin ${-s.gap} years, plan it`;
  console.log(`${s.name} (${s.use}): x+y=${s.x + s.y} -> ${verdict}`);
}

assumed z = 15 years
loan archive (RSA key wrap): x+y=30 -> LATE by 15 years, start now
firmware signing (ECDSA): x+y=21 -> LATE by 6 years, start now
branch VPN (ECDH): x+y=13 -> margin 2 years, plan it
website TLS (ECDHE): x+y=3 -> margin 12 years, plan it
OTP codes (HMAC only): x+y=0 -> no change needed

১০ · AI-এর যুগে crypto কোড

Crypto-তে AI-এর ঝুঁকি বিশেষভাবে বেশি, কারণ ভুল কোডও চলে আর test পাস করে। AI যে কোড দেয়, সেটি প্রায়ই পুরোনো টিউটোরিয়ালের প্রতিধ্বনি।

AI-এর crypto কোড গ্রহণের আগে

• Algorithm আর mode বর্তমান মান অনুযায়ী কি না, মূল ডকুমেন্টেশনে মিলিয়েছি
• Key কোথা থেকে আসে, কোথায় থাকে, কীভাবে বদলাবে, তিনটিরই উত্তর জানি
• Nonce-এর উৎস আর সীমা বুঝেছি, tag ভুল হলে কী হয় তা test করেছি
• কোনো যাচাই বন্ধ করা হয়নি: certificate, tag, hostname, সবই চালু আছে
• Prompt-এ আসল key, token বা গ্রাহকের ডেটা দিইনি
• গুরুত্বপূর্ণ কোডে একজন মানুষ review করে সিদ্ধান্ত নিয়েছেন