Hash আর MAC — SHA-2, HMAC আর অখণ্ডতা যাচাই

১ · Hash কী — ডেটার আঙুলের ছাপ

একটি কাল্পনিক অনলাইন বাজারের হিসাবরক্ষক প্রতি রাতে এক লাখ লাইনের একটি লেনদেনের ফাইল ব্যাংকে পাঠান। পরদিন সকালে ব্যাংক জানতে চায়, ফাইলটি কি পথে একটুও বদলেছে? পুরো ফাইল আবার মিলিয়ে দেখা অসম্ভব রকম ঝামেলার। এর বদলে যদি ফাইলটির একটি ছোট “ছাপ” থাকত, যা ফোনেও পড়ে শোনানো যায়, কাজটি অনেক সহজ হতো।

এই ছাপ বানায় hash function. ফাইল এক KB হোক বা দশ GB, SHA-256 সবসময় ২৫৬ bit, মানে ৬৪টি hex অক্ষরের একটি ছাপ দেয়। এই ছাপকে বলে hash বা digest. পর্ব ০৭-এ অখণ্ডতার (integrity) লক্ষ্যটি দেখেছেন। এই পর্বে দেখবেন সেই লক্ষ্য পূরণের আসল যন্ত্রগুলো। ধারণাটির প্রথম পরিচয় পাবেন Computer Networks কোর্সের cryptography পর্বে; এখানে আমরা রক্ষকের চোখে আরও গভীরে যাব।

একটি ভালো hash function-এর গুণ

• Determinism: একই ইনপুটে সবসময়, সব কম্পিউটারে একই digest. এই গুণ না থাকলে যাচাই করাই যেত না।
• নির্দিষ্ট দৈর্ঘ্য আর গতি: যেকোনো আকারের ইনপুটে একই দৈর্ঘ্যের আউটপুট, আর হিসাব দ্রুত। (এই দ্রুততাই password রাখার জন্য সমস্যা, সেই আলোচনা পর্ব ১৩-তে।)
• Preimage resistance: শুধু digest দেওয়া থাকলে এমন কোনো ইনপুট খুঁজে পাওয়া কঠিন, যার digest এটি।
• Second preimage resistance: একটি নির্দিষ্ট ফাইল দেওয়া থাকলে একই digest-এর অন্য ফাইল বানানো কঠিন।
• Collision resistance: যেকোনো দুটি আলাদা ইনপুট, যাদের digest এক, খুঁজে পাওয়া কঠিন। এখানে আক্রমণকারী দুটি ইনপুটই নিজে বেছে নিতে পারেন।

কোনটি ভাঙলে কী হয়? ধরুন কেউ চুক্তির দুটি সংস্করণ বানালেন, যাদের digest এক। একটিতে সই নিয়ে পরে অন্যটি দেখালেন। এটি collision-এর বিপদ, আর এর জন্য চুক্তি দুটি তাঁকেই তৈরি করতে হয়। অন্যদিকে, আগে থেকে থাকা কোনো ফাইলের নকল বানাতে হলে দরকার second preimage, যা অনেক বেশি কঠিন। তাই collision ভাঙলেও সব ব্যবহার সঙ্গে সঙ্গে ভেঙে পড়ে না। তবে পেশাদার নিয়ম হলো, collision ভাঙা শুরু হলেই সরে যাওয়া।

২ · Avalanche effect — এক অক্ষরে পুরো ছাপ বদল

পাহাড়ে একটি ছোট নুড়ি গড়িয়ে পড়লে যেমন গোটা ঢাল ধসে যেতে পারে, ভালো hash-এ তেমনি এক bit বদলালে digest-এর প্রায় অর্ধেক bit উল্টে যায়। একে বলে avalanche effect. এর ফলে “কাছাকাছি” ইনপুটের digest-ও কাছাকাছি হয় না, আর digest দেখে ইনপুট সম্পর্কে কোনো আন্দাজ করা যায় না।

নিচের কোডে দুটি কাল্পনিক নির্দেশ আছে, যাদের মধ্যে পার্থক্য একটি অক্ষর। m আর l-এর ASCII কোডে পার্থক্য ঠিক এক bit. চালিয়ে দেখুন digest-এ কতটি bit বদলায়।

import hashlib

def sha(data):
    return hashlib.sha256(data).digest()

def changed_bits(x, y):
    return (int.from_bytes(x) ^ int.from_bytes(y)).bit_count()

a = b"pay Rahim 500 taka"
b = b"pay Rahil 500 taka"
print("input A:", a.decode())
print("input B:", b.decode())
print("input bits changed :", changed_bits(a, b))
print("SHA-256 A:", sha(a).hex())
print("SHA-256 B:", sha(b).hex())
print("output bits changed:", changed_bits(sha(a), sha(b)), "of 256")

# 1000 more pairs: flip one input bit, count changed output bits
counts = []
for i in range(1000):
    msg = bytearray(f"message number {i}".encode())
    before = sha(bytes(msg))
    msg[0] ^= 1                # flip exactly one bit
    counts.append(changed_bits(before, sha(bytes(msg))))
print("1000 pairs: min", min(counts), "avg", sum(counts) / 1000, "max", max(counts))

৩ · Birthday bound — কেন ২৫৬ bit-এ নিরাপত্তা ১২৮ bit

একটি ঘরে কতজন থাকলে দুজনের জন্মদিন এক হওয়ার সম্ভাবনা ৫০% ছাড়ায়? উত্তর মাত্র ২৩. অবাক লাগে, কারণ আমরা ভাবি “আমার সঙ্গে কারও মিল”। কিন্তু প্রশ্নটি “যেকোনো দুজনের মিল”, আর ২৩ জনে জোড়া হয় 23 × 22 / 2 = ২৫৩টি। এই একই গণিত hash-এর birthday bound: জোড়ার সংখ্যা বাড়ে k²-এর মতো, তাই মিল আসে আশার চেয়ে অনেক আগে।

সূত্রটি কোথা থেকে আসে

ধরুন digest n bit, তাই সম্ভাব্য মান N = 2ⁿটি। k টি এলোমেলো ইনপুট নিলে জোড়া হয় প্রায় k²/2টি, আর প্রতিটি জোড়া মেলার সম্ভাবনা 1/N. একটু গুছিয়ে লিখলে:

1.1774 সংখ্যাটি এসেছে √(2 ln 2) থেকে। পরীক্ষায় সাধারণত এটুকু বাদ দিয়ে “প্রায় 2^n/2” লিখলেই চলে। মনে রাখুন, এটি আদর্শ hash-এর সীমা। অ্যালগরিদমে দুর্বলতা থাকলে খরচ এর চেয়েও কমে যায়, যেমনটি MD5 আর SHA-1-এ হয়েছে।

পূর্ণ হিসাব: ১২৮ bit বনাম ২৫৬ bit আউটপুট

ধরে নিন একটি ধনী আক্রমণকারীর ক্ষমতা সেকেন্ডে 10¹²টি hash. সংখ্যাটি শুধু হিসাবের জন্য ধরে নেওয়া।

• ১২৮ bit আউটপুট: k ≈ 1.1774 × 2⁶⁴ ≈ 2.17 × 10¹⁹. সময় ≈ 2.17 × 10⁷ সেকেন্ড, মানে প্রায় ২৫১ দিন। অর্থাৎ এক বছরের কম সময়ে ৫০% সম্ভাবনা।
• ২৫৬ bit আউটপুট: k ≈ 1.1774 × 2¹²⁸ ≈ 4.01 × 10³⁸. সময় ≈ 4.01 × 10²⁶ সেকেন্ড, মানে প্রায় 1.27 × 10¹⁹ বছর। মহাবিশ্বের বয়স প্রায় 1.4 × 10¹⁰ বছর, তার প্রায় ৯০ কোটি গুণ।

আউটপুট দ্বিগুণ করায় খরচ দ্বিগুণ হয়নি, বরং 2⁶⁴ গুণ হয়েছে। এজন্যই collision-নিরাপত্তা ১২৮ bit চাইলে আউটপুট লাগে ২৫৬ bit. নিচের কোডে একই হিসাব টেবিলে দেখুন।

// Birthday bound: k random hashes, n-bit output
// p(collision) is about 1 - exp(-k^2 / 2^(n+1))
const pCollision = (k, n) => -Math.expm1(-(k * k) / 2 ** (n + 1));
const sci = x => x.toExponential(2).padStart(10);

let noMatch = 1;                 // the classroom version, exact
for (let i = 0; i < 23; i++) noMatch *= (365 - i) / 365;
console.log('23 people, 365 days: ' + ((1 - noMatch) * 100).toFixed(1) + '%');
console.log('');
console.log('bits   k for 50%   p(k=1e9)   p(k=1e12)');
for (const n of [32, 64, 128, 160, 256]) {
  const k50 = 1.1774 * 2 ** (n / 2);
  console.log(String(n).padEnd(5), sci(k50), sci(pCollision(1e9, n)), sci(pCollision(1e12, n)));
}

const rate = 1e12;               // assumed: 10^12 hashes per second
const year = 365.25 * 24 * 3600;
console.log('');
console.log('assumed rate: 1e12 hashes/second');
for (const n of [128, 256]) {
  const seconds = 1.1774 * 2 ** (n / 2) / rate;
  console.log(n + '-bit output, 50% collision: ' + (seconds / year).toExponential(2) + ' years');
}

23 people, 365 days: 50.7%

bits   k for 50%   p(k=1e9)   p(k=1e12)
32       7.72e+4    1.00e+0    1.00e+0
64       5.06e+9    2.67e-2    1.00e+0
128     2.17e+19   1.47e-21   1.47e-15
160     1.42e+24   3.42e-31   3.42e-25
256     4.01e+38   4.32e-60   4.32e-54

assumed rate: 1e12 hashes/second
128-bit output, 50% collision: 6.88e-1 years
256-bit output, 50% collision: 1.27e+19 years

৪ · MD5 আর SHA-1-এর অবসর, এখন কী ব্যবহার করবেন

Hash function চিরকালের নয়। গবেষকেরা দুর্বলতা খুঁজে পান, আর একসময় তত্ত্ব বাস্তব হয়ে যায়। তাই শুধু নাম মুখস্থ না করে প্রতিটির অবস্থা জেনে রাখুন।

এই বিশাল গণনা দেখে মনে হতে পারে “সাধারণ মানুষ তো পারবে না।” কিন্তু দুটি বিষয় ভাবুন। প্রথমত, গণনার খরচ প্রতি বছর কমে। দ্বিতীয়ত, আক্রমণ সবসময় উন্নত হয়, কখনো পিছিয়ে যায় না। MD5-এ যা একসময় গবেষণা ছিল, এখন তা সাধারণ যন্ত্রেই সম্ভব।

৫ · Merkle-Damgård আর length extension — কেন hash(key + message) ভুল

ধরুন আপনি ভাবলেন, “Hash তো যে কেউ বানাতে পারে। তাহলে বার্তার সামনে একটি গোপন key জুড়ে hash করি, হয়ে গেল প্রমাণ।” যুক্তিটি স্বাভাবিক, কিন্তু SHA-256 বা MD5-এর মতো hash-এ এই নকশা ভাঙা। কারণ লুকিয়ে আছে এদের ভেতরের গঠনে, যার নাম Merkle-Damgård. Ralph Merkle আর Ivan Damgård ১৯৮৯ সালে আলাদাভাবে এটি প্রকাশ করেন।

নিচের ডায়াগ্রামে ধাপে ধাপে দেখুন digest কীভাবে তৈরি হয়। এখানে শুধু ধারণাটি দেখানো হয়েছে, padding-এর খুঁটিনাটি বাদ।

ফলাফল কী? SHA-256(key + message) দিয়ে সই করা একটি API-তে আক্রমণকারী key না জেনেও বার্তার শেষে বাড়তি অংশ জুড়ে বৈধ দেখতে ট্যাগ বানাতে পারেন। এটি শুধু তত্ত্ব নয়। ২০০৯ সালে Thai Duong আর Juliano Rizzo একটি প্রকাশিত advisory-তে দেখান, Flickr-এর API signature ঠিক এই কারণে দুর্বল ছিল, যেখানে secret আর parameter জুড়ে MD5 নেওয়া হতো।

এখানে একটি জরুরি শিক্ষা আছে। SHA-256 ভাঙা নয়, ভাঙা হলো তাকে ব্যবহার করার নকশা। ভালো উপাদান দিয়েও ভুল জিনিস বানানো যায়। সমাধান নিচের জোড়ায় দেখুন। এখানে শুধু কোডের ধরন দেখানো হয়েছে, secret আর body আপনার নিজের সিস্টেমের মান ধরে নিন।

# WRONG: plain hash as MAC, and an early-exit compare
tag = hashlib.sha256(secret + body).hexdigest()
if tag == received_tag:
    accept()

# RIGHT: HMAC, and a constant-time compare
tag = hmac.new(secret, body, hashlib.sha256).hexdigest()
if hmac.compare_digest(tag, received_tag):
    accept()

৬ · Hash, MAC আর signature — কোনটি কী প্রমাণ করে

তিনটি জিনিসই “বদল ধরে”, কিন্তু প্রমাণ করে আলাদা জিনিস। পোস্ট অফিসের তিন রকম ব্যবস্থা ভাবুন। খামের ওজন লিখে রাখা হলো hash: যে কেউ নতুন খামে নতুন ওজন লিখতে পারেন। দুই শাখার গোপন সিলমোহর হলো MAC: দুই শাখাই সিল মারতে পারে, তাই তৃতীয় কেউ বুঝবেন না কে মেরেছে। আর ব্যক্তিগত হাতের সই হলো digital signature: সবাই মিলিয়ে দেখতে পারেন, কিন্তু সই করতে পারেন শুধু একজন।

Digital signature-এর গভীর আলোচনা পর্ব ১১-তে। একটি কথা এখনই মনে রাখুন: signature সাধারণত পুরো ফাইলে হয় না, হয় ফাইলের hash-এ। তাই hash ভাঙলে signature-ও ঝুঁকিতে পড়ে। আর encryption-এর সঙ্গে অখণ্ডতা মেলানো, মানে AES-GCM-এর মতো authenticated encryption, পর্ব ০৮-এর বিষয়।

৭ · HMAC — দুই ধাপে বানানো নিরাপদ ট্যাগ

HMAC এসেছে Bellare, Canetti আর Krawczyk-এর ১৯৯৬ সালের গবেষণা থেকে, আর RFC 2104 (১৯৯৭) ও পরে FIPS 198-1-এ মানদণ্ড হিসেবে আছে। এর সৌন্দর্য হলো, এটি যেকোনো hash-এর ওপর চলে, hash বদলাতে হয় না। ধারণাটি সহজ: একবার ভেতরে hash, তারপর সেই ফলকে আরেকটি key-সহ আবার hash. ভেতরের পাস বার্তা চেপে ছোট করে, বাইরের পাস সেই ছাপকে গোপন key দিয়ে মুড়ে দেয়, তাই শেষ digest দেখে শিকল চালিয়ে যাওয়ার সুযোগ থাকে না।

এখানে ‖ মানে পাশাপাশি জোড়া, আর ⊕ মানে XOR. ipad হলো 0x36 আর opad হলো 0x5C, দুটিই block-এর পুরো দৈর্ঘ্য জুড়ে বারবার। নিচে একটি নকল key example-key আর বার্তা amount=500 দিয়ে আসল SHA-256 হিসাব দেখুন। মানগুলো Python-এ হিসাব করা, লম্বা মানের শুধু শুরুটুকু দেখানো হয়েছে।

key = "example-key"  (11 bytes)
K′  = 6578616d706c652d6b6579
      00 00 00 ... (53 bytes of 00)

K′        = 65 78 61 6d 70 ...
ipad      = 36 36 36 36 36 ...
K′ ⊕ ipad = 53 4e 57 5b 46 ...
শেষের 00 ⊕ 36 = 36

m     = "amount=500"
inner = 80d66935e537a414
        256ac4d883ed0e72
        53d3d22e0f09fd23
        41db6d07de0269a5

K′        = 65 78 61 6d 70 ...
opad      = 5c 5c 5c 5c 5c ...
K′ ⊕ opad = 39 24 3d 31 2c ...
শেষের 00 ⊕ 5c = 5c

tag = 6e1bdfc43aaabd25
      f678f046269cb54a
      c6ecc994ae8706c2
      f6310d136cb46207

hand-made : 6e1bdfc43aaabd25...
hmac.new  : 6e1bdfc43aaabd25...
same 32-byte tag

Constant-time তুলনা কেন দরকার

ট্যাগ বানানো হলো অর্ধেক কাজ। মিলিয়ে দেখার কাজটিও নিরাপদে করতে হয়। সাধারণ == বাঁ থেকে একে একে অক্ষর মেলায়, আর প্রথম অমিলেই থেমে যায়। তাই প্রথম অক্ষর ভুল হলে উত্তর সামান্য দ্রুত আসে, শেষ অক্ষর ভুল হলে সামান্য দেরিতে। এই সময়ের পার্থক্যই একটি গোপন তথ্য ফাঁস করে, যার নাম timing attack.

Constant-time comparison ঠিক এই কাজ করে: অমিল পেলেও শেষ পর্যন্ত সব byte দেখে, তারপর উত্তর দেয়। Python-এ hmac.compare_digest, Node.js-এ crypto.timingSafeEqual, Go-তে subtle.ConstantTimeCompare, PHP-তে hash_equals. নিচের কোডে একটি কাল্পনিক API অনুরোধের পুরো যাচাই দেখুন। Key নকল, বার্তা নকল, ঘড়িও সিমুলেট করা, কোনো network নেই।

import hashlib, hmac

KEY = b"example-webhook-key"       # fake key, for this demo only
MAX_AGE = 300                      # seconds
NOW = 1767225700                   # simulated clock

def sign(ts, body, key=KEY):
    return hmac.new(key, f"{ts}.".encode() + body, hashlib.sha256).hexdigest()

def verify(ts, body, tag):
    if abs(NOW - ts) > MAX_AGE:
        return "REJECT: too old"
    if not hmac.compare_digest(sign(ts, body), tag):
        return "REJECT: bad tag"
    return "ACCEPT"

def early_exit_steps(x, y):        # how many characters a naive compare reads
    for i, (p, q) in enumerate(zip(x, y), 1):
        if p != q:
            return i
    return len(x)

ts = 1767225600
body = b'{"order":1042,"amount":500}'
tag = sign(ts, body)
print("tag        :", tag[:32] + "...")
print("original   :", verify(ts, body, tag))
print("amount edit:", verify(ts, body.replace(b"500", b"900"), tag))
print("wrong key  :", verify(ts, body, sign(ts, body, b"other-key")))
print("new ts, old tag:", verify(NOW, body, tag))
print("old message:", verify(ts - 3600, body, sign(ts - 3600, body)))

flip = lambda c: "1" if c == "0" else "0"
print("naive steps, 1st char wrong:", early_exit_steps(tag, flip(tag[0]) + tag[1:]))
print("naive steps, last char wrong:", early_exit_steps(tag, tag[:-1] + flip(tag[-1])))

একটি signed webhook যাচাই, ধাপে ধাপে

পেমেন্ট গেটওয়ে যখন আপনার সার্ভারে “টাকা পেয়েছি” জানায়, সেটি একটি webhook. URL জানলে যে কেউ এই ঠিকানায় অনুরোধ পাঠাতে পারেন। তাই HMAC ট্যাগ ছাড়া বার্তা বিশ্বাস করা চলে না। ওপরের কোডের মানগুলোই নিচে ধাপে ধাপে দেখুন। ঝুঁকিটির STRIDE-চিত্র দেখেছেন পর্ব ০৪-এ।

ts   = 1767225600
body = {"order":1042,
        "amount":500}
tag  = HMAC(key, ts + "." + body)
     = bb8f652c8efa40d7...

header ts  : 1767225600
header tag : bb8f652c8efa40d7...
raw body   : 27 bytes, unchanged
clock NOW  : 1767225700

|1767225700 - 1767225600|
  = 100 seconds
100 <= 300  pass

computed = HMAC(key,
  "1767225600." + raw body)
         = bb8f652c8efa40d7...

compare_digest(computed, tag)
  bb8f652c8efa40d7...
  bb8f652c8efa40d7...
result: True

order 1042 seen before? no
amount 500  mark as paid
store event id, reply 200

computed = 01775b873b06c071...
received = bb8f652c8efa40d7...
result: False
reject, log, do not process

এখানে দেখানো ট্যাগ ও header-এর বিন্যাস একটি সাধারণ ধরন, নির্দিষ্ট কোনো সেবার নয়। আপনি যে সেবা ব্যবহার করছেন, তার নথিতে দেওয়া বিন্যাসই মেনে চলুন। আর মনে রাখুন, এই পরীক্ষাগুলো নিজের সিস্টেমে বা লিখিত অনুমতি নিয়ে করবেন। অনুমতি ছাড়া অন্যের API-তে পরীক্ষা অপরাধ হতে পারে; দেখুন পর্ব ০৬।

৮ · Download যাচাই — checksum, নিরাপত্তা আর sha256sum

আগে একটি পার্থক্য পরিষ্কার করা যাক। Checksum আর cryptographic hash এক নয়। CRC বা কার্ড নম্বরের শেষ অঙ্কের মতো checksum তৈরি হয়েছে দুর্ঘটনা ধরতে: নেটওয়ার্কের শব্দ, disk-এর নষ্ট bit, টাইপের ভুল। এগুলো দ্রুত, কিন্তু কেউ ইচ্ছা করে ফাইল বদলালে একই checksum সহজে মিলিয়ে দিতে পারেন। তাই “বৃষ্টিতে ভিজল কি না” দেখতে checksum চলে, কিন্তু “কেউ বদলাল কি না” দেখতে cryptographic hash লাগে।

নিচের কোড নিজে দুটি ফাইল বানায়, একটি digest-তালিকা তৈরি করে, তারপর একটি অক্ষর বদলে আবার যাচাই করে। সব কাজ একটি অস্থায়ী folder-এ, আপনার বা কারও আসল ফাইলে নয়।

set -eu
cd "$(mktemp -d)"
printf 'release 1.0: payroll tool\n' > app-1.0.tar
printf 'install notes\n' > notes.txt

sha256sum app-1.0.tar notes.txt > SHA256SUMS
cut -c1-16 SHA256SUMS
echo "--- check 1: files untouched"
sha256sum -c SHA256SUMS

echo "--- check 2: one character changed, same size"
wc -c < app-1.0.tar
printf 'release 1.0: paYroll tool\n' > app-1.0.tar
wc -c < app-1.0.tar
if sha256sum -c SHA256SUMS 2>&1; then
    echo "all good"
else
    echo "exit code $?: do not install this file"
fi

নিজের কম্পিউটারে একটি আসল download যাচাই

নিজের ডাউনলোড করা ফাইলে নিচের কমান্ড চালান। ফাইলের নাম উদাহরণ মাত্র।

sha256sum app-1.0.tar
# with a published list in the same folder:
sha256sum -c SHA256SUMS

Get-FileHash .\app-1.0.tar -Algorithm SHA256
# or in Command Prompt:
certutil -hashfile app-1.0.tar SHA256

shasum -a 256 app-1.0.tar
shasum -a 256 -c SHA256SUMS

৯ · Content addressing আর Merkle tree

Hash শুধু যাচাইয়ের যন্ত্র নয়, সিস্টেম গড়ারও উপাদান। ধরুন প্রতিটি ফাইলের নাম হবে তার digest. একে বলে content addressing. একই বিষয়বস্তু তাহলে একবারই জমা থাকে, আর নাম দেখেই যাচাই করা যায় ফাইলটি বদলেছে কি না।

Git এভাবেই কাজ করে। hello লেখা ৬ byte-এর একটি ফাইলের জন্য Git “blob 6”, একটি শূন্য byte আর ফাইলের বিষয়বস্তু জুড়ে SHA-1 নেয়, আর ফল আসে ce013625… দিয়ে শুরু। মানটি আমরা Python-এর hashlib-এ এই সূত্রেই হিসাব করেছি। প্রতিটি commit আবার আগের commit-এর digest ধরে রাখে, তাই ইতিহাসের একটি অক্ষর বদলালে পরের সব id বদলে যায়। বিস্তারিত দেখুন Git internals পর্বে।

কিন্তু লাখ লাখ ফাইলের কোনটি বদলেছে, তা জানতে কি সব মেলাতে হবে? না। ১৯৭০-এর দশকের শেষে Ralph Merkle-এর দেওয়া Merkle tree এই সমস্যার উত্তর। পাতায় থাকে ডেটার hash, ওপরে জোড়ায় জোড়ায় hash-এর hash, আর চূড়ায় একটি Merkle root. শুধু root নিরাপদে রাখলেই পুরো তালিকা পাহারায় থাকে।

A:100  B:250  C:75   D:500
263c67 d595ae b01ab0 d532f9

  410a7d        a1258c
  /    \        /    \
263c67 d595ae b01ab0 d532f9
A:100  B:250  C:75   D:500

     root 901a8d
     /          \
  410a7d       a1258c
  /    \       /    \
263c67 d595ae b01ab0 d532f9
A:100  B:250  C:75   D:500

     root 901a8d
     /          \
  410a7d       a1258c
  /    \       /    \
263c67 d595ae 5dca72 d532f9
A:100  B:250  C:95   D:500

     root ed188f
     /          \
  410a7d       b4f0cd
  /    \       /    \
263c67 d595ae 5dca72 d532f9
saved root: 901a8d  mismatch

root      901a8d / ed188f  differ
left      410a7d / 410a7d  same, skip
right     a1258c / b4f0cd  differ
leaf 3    b01ab0 / 5dca72  differ: C
leaf 4    d532f9 / d532f9  same

have  : A:100, saved root
given : d595ae, a1258c
H(A)            = 263c67
H(263c67+d595ae)= 410a7d
H(410a7d+a1258c)= 901a8d  match

১০ · AI-এর যুগে hash আর MAC

AI কয়েক সেকেন্ডে webhook যাচাইয়ের কোড লিখে দিতে পারে, আর সেটি চলেও। সমস্যা হলো, ভুল crypto কোডও পরীক্ষায় দিব্যি চলে। ট্যাগ মেলে, বার্তা পাস হয়, শুধু নিরাপত্তা থাকে না। তাই নিচের ভুলগুলো চোখে রাখুন।

AI-এর লেখা hash বা MAC কোড চালুর আগে

• অ্যালগরিদম SHA-256 বা তার সমান, MD5 বা SHA-1 নয়
• MAC বানাতে library-র HMAC ব্যবহার হয়েছে, নিজে লেখা জোড়াতালি নয়
• তুলনা constant-time, আর ভুল ট্যাগ, পুরোনো timestamp, বদলানো body দিয়ে নিজের ল্যাবে পরীক্ষা করেছি
• Key কোডে বা Git-এ নেই, secret store থেকে আসে; prompt-এও পেস্ট করিনি
• AI-এর দেওয়া RFC, FIPS বা CVE নম্বর মূল উৎসে মিলিয়ে দেখেছি
• Diff নিজে পড়েছি, আর প্রতিটি লাইনের কাজ নিজের ভাষায় বলতে পারি