1. One-way Function — ฟังก์ชันทางเดียว#

นี่คือ DNA ของ hashing. ผมเคยใช้ analogy นี้ใน EP.12 — เครื่องบดเนื้อ

ลองนึกภาพคุณเอาเนื้อวัวก้อนนึงใส่เครื่องบด — กดปุ่ม — ได้เนื้อบดออกมา. คำถาม — เอาเนื้อบดกลับเข้าเครื่อง กดย้อน ได้วัวคืนไหม? ไม่ได้ครับ. กระบวนการนี้ทำได้ทางเดียว — ไปได้ ย้อนไม่ได้

Hash function = แบบเดียวกัน. ใส่ input (ข้อมูลอะไรก็ได้ — password, ไฟล์ PDF, รูป, video) → คำนวณ → ได้ output เป็นสตริงยาวๆ. และคุณเอา output กลับมาย้อนเป็น input ไม่ได้

ทำไมต้องเป็นทางเดียว? เพราะถ้าย้อนได้ — มันคือ encryption ไม่ใช่ hash. ใน password storage — server ไม่ควรเก็บ password ของคุณในรูปที่อ่านได้. ใน digital signature — คุณไม่ต้องการให้ใครย้อน hash กลับเป็นเอกสารต้นฉบับเพื่อปลอม

2. Deterministic — input เดิม → output เดิมเสมอ#

ใส่ “hello” เข้า SHA-256 — ได้ hash A. ใส่ “hello” อีกครั้ง พรุ่งนี้ ปีหน้า บนคอมพิวเตอร์อีกเครื่อง — ต้องได้ hash A เป๊ะ ไม่ใช่ใกล้เคียง ไม่ใช่คล้ายกัน — เป๊ะตัวต่อตัว

นี่คือเหตุผลที่ password verification ทำงานได้. EP.12 ผมเล่าไว้ว่า — ตอนคุณ login — server ไม่มี password ของคุณเก็บไว้ — มันมีแค่ hash. ระบบเอา password ที่คุณพิมพ์ → hash → เทียบกับ hash ที่เก็บไว้ — ถ้าตรง = ผ่าน. ถ้า hash function ไม่ deterministic — ระบบนี้พังทันที

3. Avalanche Effect — เปลี่ยน 1 bit → hash เปลี่ยนยับ#

ลองดูตัวอย่างที่ผมเคยใช้ใน EP.12. Hash “password123” ด้วย SHA-256:

ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

Hash “password124” — เปลี่ยนเลข 3 เป็น 4 ตัวเดียว:

38a44b21fc99fc7a... — สตริงคนละชุดเลย

ใน hash ที่ดี — เปลี่ยน input 1 bit (เล็กกว่า 1 ตัวอักษรอีก) — output ควรเปลี่ยนประมาณ 50% ของ bit ทั้งหมด. แปลภาษาคน — ดู output แล้ว เดาไม่ออกว่า input เปลี่ยนน้อยหรือเยอะ

ทำไมต้องมีคุณสมบัตินี้? เพราะถ้าไม่มี — โจรที่เห็น hash อาจเดา pattern ได้ว่า input น่าจะใกล้เคียงกับอะไร. Avalanche effect ลบ pattern นั้นทิ้ง

4. Collision Resistance — input ต่างกัน → output ห้ามตรงกัน#

นี่คือคุณสมบัติที่สำคัญที่สุดและทำให้ hash function ส่วนใหญ่ “ตาย” ในที่สุด

Collision = สถานการณ์ที่ input A ≠ input B แต่ hash(A) = hash(B)

ในทางคณิตศาสตร์ — collision ต้องมีอยู่จริง เสมอ. เหตุผลง่ายๆ — input มีจำนวนไม่จำกัด (ข้อมูลอะไรก็ใส่เข้าได้ — ไฟล์ขนาดเท่าไหร่ก็ได้) แต่ output มีจำนวนจำกัด (เช่น SHA-256 ออก 256 bit = 2^256 ความเป็นไปได้). ถ้า input ไม่จำกัด แต่ output จำกัด — ต้องมี input หลายตัวที่ map ไป output เดียวกัน (หลักการ Pigeonhole)

แต่ — ที่ hash function ที่ดีทำได้คือ — ทำให้การหา collision ใช้เวลานานเกินไปจนทำไม่ได้ในทางปฏิบัติ. 2^128 ครั้ง? ใช้พลังงาน computing ของทั้งโลก 100 ปียังหาไม่เจอ. นี่คือสิ่งที่เรียกว่า “collision-resistant” — ไม่ใช่ว่า collision เป็นไปไม่ได้ — แค่ “หาไม่เจอในเวลาที่มีความหมาย”

เมื่อไหร่ที่นักวิจัยหา collision ของ hash function ได้เร็วกว่าที่ทฤษฎีกำหนด — hash function นั้น “ตาย”. MD5 ตายเพราะแบบนี้ (2004). SHA-1 ตายเพราะแบบนี้ (2017 — เดี๋ยวเล่าให้ฟัง)

5. Pre-image Resistance — เห็น hash → ห้ามย้อนเดา input ได้#

Pre-image = input ต้นฉบับ. Pre-image resistance = ห้ามมีใครเอา hash ไปย้อนเดา input ได้

ฟังดูคล้าย one-way function แต่ลึกกว่านิดนึง. One-way = ไม่มีสูตรย้อนได้. Pre-image resistance = ต่อให้ใช้ brute force (ลองทุกความเป็นไปได้) — ก็ยังหาไม่เจอในเวลาที่มีความหมาย

มี variant ที่เรียก Second pre-image resistance — เห็น input A + hash(A) → ห้ามมีใครหา input B ≠ A ที่ hash(B) = hash(A) ได้. หินกว่า pre-image อันดับ 1 — แต่สำคัญมากใน digital signature

มุมผู้บริหาร: คำถาม 5 ข้อข้างบนดูเป็นเรื่องคณิตศาสตร์ — แต่ในใจผู้บริหาร แปลเป็น 1 ประโยคได้ครับ — “ทีม dev ของบริษัทเราใช้ hash algorithm ที่ผ่านมาตรฐานวงการในปี 2026 หรือเปล่า?”. ถ้าทีม IT ตอบไม่ได้ — เป็นสัญญาณว่า security review ของบริษัทไม่เคยลงลึกถึงระดับ algorithm. ไม่ต้องลงทุนอะไรเพิ่ม — แค่ขอ checklist จากทีม dev ว่าระบบทั้งหมดเก็บ password / sign document / verify file ด้วย hash ตัวไหน. ถ้าเจอ MD5 หรือ SHA-1 ในระบบใหม่ที่สร้างหลังปี 2020 = red flag

MD5 (1991) — เกิดในยุค Internet ยังไม่มา ตายในปี 2004#

MD5 (Message-Digest 5) — สร้างปี 1991 โดย Ronald Rivest (R ใน RSA — คนเดียวกับ EP.21). output 128 bit = 32 ตัว hex

ในยุค 1990s — MD5 ใช้ทั่วโลกในแทบทุกระบบ. checksum ของไฟล์ที่คุณ download / certificate ของเว็บไซต์ / password ใน database. MD5 = มาตรฐานวงการ

ปี 2004 — นักวิจัยจีน Wang Xiaoyun ประกาศ MD5 collision attack — หาวิธีสร้าง input 2 ตัวที่ hash ออกมาตรงกัน. ในทางทฤษฎี hash 128 bit ต้องใช้ ~2^64 ครั้งเพื่อหา collision (Birthday Paradox — เดี๋ยวคุยกัน). Wang หาได้ในเวลาแค่ “1 ชั่วโมงบน laptop”. เร็วกว่าทฤษฎีเป็นล้านล้านเท่า

ผลต่อจริงในปี 2012 — Flame Malware — มัลแวร์ที่นักวิจัยเชื่อว่าเป็นเครื่องมือสงครามไซเบอร์ (น่าจะระดับ nation-state) โจมตี Windows Update วิธีคือสร้าง certificate ปลอมที่ Microsoft signed ผ่าน MD5 collision ผลคือมัลแวร์ปลอมเป็น update อย่างเป็นทางการของ Microsoft → Windows ทั่วโลกในเป้าหมาย “เชื่อ” และติดตั้ง MD5 collision ในมือคนผิด = ระดับโครงสร้างพื้นฐานของอินเทอร์เน็ตเปราะทันที

ในปี 2026 MD5 ห้ามใช้ในงานที่เกี่ยวกับ security เด็ดขาด แต่ในวงการบริษัทไทย ยังเจอ MD5 ใน legacy system ปี 2008-2015 บ่อย pattern ของวงการ — ระบบเก็บเงินเดือนเขียนปี 2010 ยังใช้ MD5 hash password admin อยู่ 17 ปีของ technical debt ในระบบเดียว — pattern ที่ ISACA / OWASP เตือนบ่อย

SHA-1 (1995) — เกิดจาก NSA ตายปี 2017 ด้วย SHAttered#

SHA-1 (Secure Hash Algorithm 1) — สร้างปี 1995 โดย NSA ของอเมริกา. output 160 bit = 40 ตัว hex. ออกแบบให้แทน MD5

ปี 2005 — นักวิจัย (รวม Wang Xiaoyun อีกครั้ง) พบ theoretical weakness ของ SHA-1. ทฤษฎีบอก SHA-1 ต้อง 2^80 ครั้งเพื่อหา collision — Wang พบวิธีลดเหลือ ~2^69. ยังไม่ practical — แต่เปิดประตูไว้

ปี 2017 — Google + CWI Amsterdam ประกาศ SHAttered — collision จริงของ SHA-1 ครั้งแรกในประวัติศาสตร์. พวกเขาสร้าง PDF 2 ไฟล์ที่หน้าตาเนื้อหาต่างกัน — แต่ SHA-1 hash ตรงกัน. ใช้ computing power 6,500 ปี CPU + 110 ปี GPU = ประมาณ $110,000 ที่ราคา cloud ปี 2017. แพง — แต่ทำได้จริง

หลัง SHAttered — SHA-1 ตายอย่างเป็นทางการ. Browser หยุดยอมรับ SHA-1 certificates ทันที. Git ที่ใช้ SHA-1 มาตั้งแต่ปี 2005 — ประกาศแผน migrate ไป SHA-256 (เริ่มทยอยตั้งแต่ปี 2020). ระบบใดๆ ที่ยังใช้ SHA-1 ในปี 2026 = ต้อง migrate ทันที

ที่น่าสนใจคือ — SHAttered ทำได้ใน 2017 ราคา $110K. ในปี 2025 — ราคาลดเหลือต่ำกว่า **$50,000** ตามการคำนวณของนักวิจัย. และในปี 2030 — น่าจะอยู่ในระดับที่ aficionados ทำเล่นที่บ้านได้

SHA-2 (2001) — SHA-256 / SHA-512 — มาตรฐานปัจจุบัน#

SHA-2 = family ของ hash function ที่ NSA สร้างปี 2001 — รวม SHA-224 / SHA-256 / SHA-384 / SHA-512. ที่ใช้บ่อยที่สุดคือ SHA-256 (256 bit = 64 ตัว hex) และ SHA-512 (512 bit = 128 ตัว hex)

ในปี 2026 — SHA-2 ยังไม่มีใคร collision attack ได้. นักวิจัยทั่วโลกพยายามมา 25 ปี — ยังไม่ขยับ. ทฤษฎียัง 2^128 ครั้งเป๊ะ — และไม่มีใครหาเวลาที่ลดได้

SHA-2 ใช้ในระบบทั่วโลก:

• Bitcoin — block hash ทุกตัวคือ SHA-256 (จริงๆ คือ SHA-256 hash 2 รอบ = double SHA-256)
• TLS / HTTPS certificates — SHA-256 เป็น signature algorithm หลัก
• Code signing — Microsoft / Apple ใช้ SHA-256 sign code ทุกตัวที่ขึ้น store
• Git — เริ่ม migrate จาก SHA-1 ไป SHA-256 ตั้งแต่ปี 2020

SHA-2 = current standard ในปี 2026. ระบบใหม่ทุกระบบควรใช้ SHA-256 ขึ้นไป

SHA-3 (2015) — สถาปัตยกรรมต่างจาก SHA-2 — backup ถ้าวันหนึ่ง SHA-2 พัง#

ปี 2007 — NIST เปิดการแข่งขัน SHA-3 Competition — ให้นักวิจัยทั่วโลกส่ง hash algorithm มาสู้กัน. เหตุผลคือ — ตอนนั้น SHA-1 เริ่มอ่อน + SHA-2 ยังไม่มีปัญหา แต่ NSA อยากเตรียม backup เผื่อ SHA-2 พังในอนาคต

ปี 2012 — algorithm ชื่อ Keccak ของนักวิจัยเบลเยียม-อิตาลีชนะ. ปี 2015 — Keccak ถูก standardize เป็น SHA-3

ที่สำคัญคือ — SHA-3 ใช้สถาปัตยกรรมต่างจาก SHA-2 โดยสิ้นเชิง. SHA-2 ใช้แนว Merkle-Damgård (รับแรงบันดาลใจจาก block cipher). SHA-3 ใช้แนว sponge construction (แนวคิดใหม่). แปลภาษาคน — ถ้าวันหนึ่งมีคนหา weakness ที่ทำให้ SHA-2 พัง — SHA-3 จะไม่พังตามอัตโนมัติ เพราะมันคิดคนละแบบ

ในปี 2026 — SHA-3 ยังไม่ใช้แพร่หลายเท่า SHA-2 — เพราะ SHA-2 ยังดีอยู่ + library / hardware ส่วนใหญ่ใช้ SHA-2 มานาน. แต่ SHA-3 เริ่มขึ้นในงาน high-stakes — เช่น ระบบของ Ethereum (Keccak-256, ซึ่งเป็น variant ใกล้ SHA-3)

BLAKE2 / BLAKE3 — Modern fast alternatives#

นอกตระกูล SHA — มี BLAKE2 (2012) และ BLAKE3 (2020) — สร้างโดยทีมนักวิจัยรวมถึง Jean-Philippe Aumasson

จุดเด่นของ BLAKE = เร็วกว่า SHA-2 มาก บน hardware สมัยใหม่ (BLAKE3 บน CPU 16 cores เร็วกว่า SHA-256 ประมาณ 10 เท่า). และ ปลอดภัยพอๆ กัน — ผ่านการ review จากวงการมา 10+ ปี

BLAKE2 ใช้ใน:

• Argon2 (password hash ที่แนะนำในปี 2026 — recap EP.12) — ภายในใช้ BLAKE2
• WireGuard VPN — ใช้ BLAKE2 สำหรับ MAC
• Linux kernel — ใช้ BLAKE2 ในบางจุด

BLAKE3 ยังไม่ปกติเท่า BLAKE2 ในวงการ enterprise — แต่กำลังขึ้น

มุมผู้บริหาร: ในการประชุมกับ CTO/CIO — คุณไม่ต้องจำชื่อ hash algorithm ทุกตัว. แค่จำกฎ 3 ข้อนี้ก็พอครับ — (1) MD5 + SHA-1 = ห้ามใช้ในระบบใหม่ทั้งหมด + (2) SHA-256 = default ในปี 2026 + (3) ถ้าเจอระบบที่ยังใช้ MD5/SHA-1 — ต้องมีแผน migrate ภายใน 1 ปี. คำถามที่ควรถาม CTO ในประชุมต่อไป — “ระบบไหนของบริษัทเรายังใช้ MD5 หรือ SHA-1 อยู่บ้าง? — มีแผน migrate เมื่อไหร่?” ถ้า CTO ตอบไม่ได้ — ลงทุน 2 อาทิตย์ให้ทีมไป inventory ก่อน

ปัญหาคลาสสิคก่อน — ในห้อง 23 คน มีคน 2 คนวันเกิดตรงกันด้วยความน่าจะเป็น 50%#

ลองทายดูครับ — ในห้องที่มีคน 23 คน — ความน่าจะเป็นที่จะมีคน 2 คนวันเกิดตรงกัน (วันที่ + เดือน ไม่นับปี) เท่าไหร่?

คนส่วนใหญ่ตอบ — 5%? 10%?. คำตอบจริงคือ — 50.7%. ในห้อง 23 คน — มีคน 2 คนวันเกิดตรงกันความน่าจะเป็นกว่าครึ่ง

ในห้อง 70 คน — 99.9%. แทบจะแน่นอน

ฟังดูเหมือนผิด — เพราะเราคิดว่าวันในปี 1 ปีมี 365 วัน — ต้องมีคนเยอะมากกว่าจะหาคนวันเกิดตรงกันได้

ที่เราคิดผิดเพราะ — เราไม่ได้หาคน “วันเกิดตรงกับฉัน” — เราหา “คน 2 คนที่ไหนก็ได้ ที่วันเกิดตรงกัน”. จำนวนคู่ที่เป็นไปได้ในห้อง 23 คน = C(23,2) = 253 คู่. แต่ละคู่มีโอกาส 1/365 ตรงกัน. รวม 253 × 1/365 ≈ 69%. ใกล้ๆ 50% ที่คำนวณจริง (สูตรจริงซับซ้อนกว่านี้นิดหน่อย)

นี่คือ Birthday Paradox — ปัญหาคู่อันดับ “ที่ไหนก็ได้” ง่ายกว่าปัญหาเดี่ยว “ตรงกับเฉพาะคน” มหาศาล

แล้วเกี่ยวกับ hash ยังไง?#

นี่คือจุดสำคัญ. สมมติ hash function ของคุณออก n bit = 2^n ความเป็นไปได้ (เช่น SHA-256 = 2^256).

Pre-image attack (หา input ที่ map ไป hash ที่กำหนด) — ต้องลอง ~2^n ครั้ง (ในตัวอย่างคือ 2^256). ใหญ่มหาศาล — ในทางปฏิบัติทำไม่ได้ตลอดกาลด้วย computing ทั่วไป

Collision attack (หา input 2 ตัวที่ไหนก็ได้ ที่ hash ตรงกัน) — Birthday Paradox บอกว่า — ใช้แค่ ~2^(n/2) ครั้ง

แปลภาษาคน — collision attack ใช้ effort เป็น square root ของ pre-image attack

ตัวเลขจริง:

• MD5 — 128 bit. Pre-image ต้อง 2^128. Collision ต้อง 2^64 = ~18 พันล้านพันล้าน ครั้ง. ปี 2004 Wang หาได้ในเวลา 1 ชั่วโมง — เพราะ MD5 มี weakness ที่ลดต่ำกว่า 2^64 ลงไปอีก
• SHA-1 — 160 bit. Pre-image 2^160. Collision 2^80. SHAttered 2017 ทำได้ที่ราคา $110K
• SHA-256 — 256 bit. Pre-image 2^256. Collision 2^128. ในปี 2026 — ไม่มีใครทำได้
• SHA-512 — 512 bit. Collision 2^256. ไม่ต้องคิดเลย

ความสำคัญต่อผู้บริหาร: ตอนเลือก hash — ต้องดู effective bit length ครึ่งนึงของ output. SHA-256 ที่บอก 256 bit — ทนต่อ collision จริงๆ ที่ 128 bit. ดังนั้นถ้าต้องการ security level สูง (เช่น สำหรับการเก็บข้อมูลที่ต้องคงทนผ่าน decade) — เลือก SHA-512 หรือสูงกว่า

Collision หาแล้วเอาไปทำอะไรในชีวิตจริง?#

หลายคนถามว่า — “ก็แค่ input 2 ตัวที่ hash ตรงกัน — แล้วโจรเอาไปทำประโยชน์ยังไง?”

ตัวอย่างที่เห็นภาพชัดสุดคือ SHAttered 2017:

1. Google สร้าง PDF 2 ไฟล์ — ไฟล์ A เป็น “PDF ขาว” / ไฟล์ B เป็น “PDF เขียนข้อความสำคัญ”
2. ทั้ง 2 ไฟล์ — SHA-1 hash ตรงกันเป๊ะ
3. ถ้าระบบใช้ SHA-1 verify digital signature — คุณ sign ไฟล์ A (PDF ขาว) → ระบบเก็บ hash. โจรเอาไฟล์ B (PDF เขียนเปลี่ยนสัญญา) มาแทน → ระบบเช็ค hash → ตรงกัน → ระบบ “เชื่อ” ว่าคุณ sign ไฟล์ B แล้ว
4. ผลคือ — โจรปลอม signature ของคุณได้ โดยไม่ต้องรู้ private key คุณเลย

นี่คือสาเหตุที่ collision attack อันตรายมากใน digital signature / certificate / blockchain. ไม่ใช่แค่ “ตัวเลขตรงกัน” — แต่คือ “ปลอม identity ได้”

ในเคส Flame Malware (2012) ที่ผมเล่าก่อนหน้า — เขาใช้ MD5 collision สร้าง certificate ปลอมของ Microsoft. ปลอม identity ของ Microsoft ได้ = ปลอม Windows Update ได้ = ระบบทั่วโลกถูกพัง

มุมผู้บริหาร: ผู้บริหารไม่ต้องเข้าใจคณิตศาสตร์ทั้งหมด — แต่ควรเข้าใจ 1 concept — “output bit length / 2 = security จริง”. SHA-256 = security 128 bit. SHA-512 = security 256 bit. ถ้าระบบของคุณเก็บข้อมูลที่ต้องคงทนผ่าน 20-30 ปี (เช่น สัญญากฎหมาย, medical record) — ใช้ SHA-512 ไม่ใช่ SHA-256. เผื่อ computing power ของอนาคต (รวม quantum computer ถ้ามาจริง) ทำให้ 128 bit ไม่พอ

HMAC — Hash-based Message Authentication Code#

ลองนึกฉากนี้ครับ — คุณส่ง API call ไป AWS ขอ list ไฟล์ใน S3 bucket. AWS ต้องตอบ 2 คำถาม:

1. คนที่ส่ง API call นี้คือคนของบริษัทคุณจริงไหม? (authenticity)
2. request นี้ระหว่างทางถูกแก้ไขโดยใครไหม? (integrity)

ถ้าใช้ hash ตรงๆ — เช่น hash request body → ส่งไปด้วย — โจรที่ดักได้ก็แก้ request + คำนวณ hash ใหม่ → AWS เชื่อ. ห่วย

ถ้าใช้ encryption — ก็ตอบ authenticity ได้แต่ overhead เยอะ. และในหลายเคส เราไม่ต้องการ confidentiality — แค่ต้องการ “เชื่อว่าคนส่งคือเจ้าของ”

HMAC = วิธีรวม hash + secret key เพื่อตอบ 2 คำถามนี้

หลักการเรียบง่าย:

1. คุณกับ AWS แชร์ secret key K (ที่คนอื่นไม่รู้)
2. ตอนส่ง request — คุณคำนวณ HMAC = hash(K + message)
3. ส่ง message + HMAC ไปด้วย
4. AWS รับมา — คำนวณ hash(K + message) เอง — เทียบกับ HMAC ที่ส่งมา
5. ตรงกัน = (a) message ไม่ได้ถูกแก้ + (b) คนส่งรู้ K = เจ้าของบัญชี

โจรที่ดักได้ — แก้ message ไม่ได้ (เพราะคำนวณ HMAC ใหม่ไม่ได้ — ไม่รู้ K). ไม่ปลอม sender ได้ (เหตุผลเดียวกัน)

จริงๆ สูตร HMAC ซับซ้อนกว่านี้นิดนึง — มี inner pad + outer pad เพื่อป้องกัน “length extension attack” แต่ concept หลักคือนี่

HMAC อยู่ที่ไหนบ้าง:

• AWS Signature Version 4 (SigV4) — ทุก API call ของ AWS ใช้ HMAC-SHA256
• JWT (JSON Web Token) HS256 — token ที่ใช้ใน OAuth / authentication ปัจจุบัน
• TLS — ใช้ HMAC ใน record layer protection
• Stripe webhooks — verify ว่า webhook มาจาก Stripe จริง

HMAC คือเสาหลักของ API security ในปี 2026 — เหมือนตราประทับลับของเมืองที่ยืนยันว่าจดหมายมาจากคนของเมืองจริง ไม่ใช่จดหมายปลอม

Merkle Tree — ต้นไม้ของ hash ที่ Bitcoin / Git ใช้#

ลองนึกปัญหานี้ครับ — คุณมีข้อมูล 1 ล้านชิ้น (เช่น 1 ล้าน transaction ของ Bitcoin / 1 ล้านไฟล์ใน Git repo). คำถาม — คุณจะ verify ว่าข้อมูลทั้ง 1 ล้านชิ้นไม่ถูกแก้ — ด้วย hash 1 ตัวเดียว — ได้ยังไง?

วิธีง่ายๆ — hash ข้อมูลทั้ง 1 ล้านชิ้นต่อกัน → ได้ hash 1 ตัว. โอเค — แต่มีปัญหา. ถ้าคุณอยากเช็คว่า “ชิ้นที่ 500,000 ไม่ถูกแก้” — คุณต้องโหลดทั้ง 1 ล้านชิ้นมา hash ใหม่. แพง

Merkle Tree (Ralph Merkle, 1979) = วิธีจัด hash เป็นต้นไม้ ที่ทำให้ verify “ชิ้นเดียว” ได้โดยโหลดข้อมูลน้อยมาก

หลักการ:

1. Hash ข้อมูลทุกชิ้น → ได้ leaf hashes
2. จับคู่ leaf hashes → hash คู่นั้น → ได้ node ชั้นบน
3. จับคู่ node ชั้นบนต่อ → ขึ้นเรื่อยๆ จนเหลือ hash 1 ตัว = root hash (Merkle Root)

ผลคือ — Merkle Root 1 ตัว = ตัวแทนของข้อมูลทั้งหมด. แก้ข้อมูลชิ้นใดชิ้นเดียวในระดับล่างสุด — Merkle Root จะเปลี่ยน (Avalanche Effect ทำงานทั้งต้น)

และที่เจ๋งคือ — verify ชิ้นเดียวใช้ข้อมูลแค่ log₂(n) ชิ้น (สำหรับ n = 1 ล้าน — แค่ ~20 ชิ้น แทนที่จะเป็น 1 ล้าน). เรียกว่า Merkle Proof

Merkle Tree อยู่ที่ไหนบ้าง:

• Bitcoin / Blockchain ทั้งหมด — แต่ละ block มี Merkle Root ของ transaction ทั้ง block. ทำให้ light client (เช่น mobile wallet) verify transaction ตัวเองได้โดยไม่ต้องโหลด block ทั้งหมด
• Git — ทุก commit คือ tree of hashes. ทุก directory = tree. ทุก file = blob hash. ทำให้ Git ตรวจสอบ integrity ของ repo ได้ที่ระดับ bit. นี่คือเหตุผลที่ git status รู้ว่าไฟล์ไหนเปลี่ยน — เปรียบเทียบ hash ของ tree
• IPFS — content-addressed storage ใช้ Merkle DAG (variant ของ Merkle Tree)
• Certificate Transparency logs — verify certificate ทั่วโลกด้วย Merkle Tree
• AWS DynamoDB / Cassandra — anti-entropy ระหว่าง replica ใช้ Merkle Tree

ใน Git — ทุก commit hash คือ SHA-1 (กำลัง migrate ไป SHA-256) ของ Merkle Tree ของ commit นั้น. คุณ git log เห็น hash อย่าง 89a0cf3... — นั่นคือ Merkle Root ของ snapshot ทั้ง repo ณ commit นั้น

ถ้าคุณเข้าใจเรื่องนี้ — คุณจะเห็นว่า Git คือ database ของ hash tree ไม่ใช่แค่ “version control”

มุมผู้บริหาร: HMAC + Merkle Tree ฟังดูเทคนิค แต่ implication ตรงๆ คือ — คำถามที่ควรถามทีม IT — “ระบบ audit log ของเรา tamper-proof ไหม? ถ้าโจรเข้ามาแก้ log เพื่อลบรอยเท้า เรารู้ไหม?” ถ้า audit log แก้ได้โดยไม่ตรวจจับ — incident response จะพังเมื่อมี breach. หลายบริษัทเสียโอกาสในการสืบสวนเพราะ log ของตัวเองเชื่อไม่ได้

มุมผู้บริหาร: เคสที่เห็นภาพชัด — supply chain transparency. ถ้าบริษัทคุณทำสินค้า + อ้างว่า “ตามได้ทุก batch ตั้งแต่ฟาร์มถึงโต๊ะ” — ระบบที่อยู่เบื้องหลังคำสัญญานี้ส่วนใหญ่ใช้ Merkle Tree เพื่อให้ผู้บริโภค verify ได้. ถ้า marketing claims แบบนี้ แต่หลังบ้านไม่ใช้ hash chain — claim ของคุณเชื่อไม่ได้และเสี่ยงต่อข้อหา greenwashing / fraud