กระบวนการทำงาน#

ในระบบ Symmetric สมัยใหม่ (ที่ไม่ใช่ Caesar Cipher แล้ว) — ขั้นตอนเป็นแบบนี้ครับ:

1. คุณ + เพื่อน ตกลงกันก่อนว่าจะใช้ key อะไร (เช่น สตริงสุ่ม 256 bit)
2. คุณ อยากส่งข้อความ → ใส่ข้อความ + key เข้าฟังก์ชัน encrypt → ได้ ciphertext (ข้อความที่เข้ารหัสแล้ว — อ่านไม่รู้เรื่อง)
3. คุณ ส่ง ciphertext ไปให้เพื่อน (ผ่านอินเทอร์เน็ต / ทาง email ก็ได้ — เพราะคนกลางอ่านไม่ออก)
4. เพื่อน รับ ciphertext → ใส่ ciphertext + key เดียวกัน เข้าฟังก์ชัน decrypt → ได้ข้อความต้นฉบับคืน

ลองสังเกตขั้นตอนที่ 1 ดีๆ ครับ — “ตกลงกันก่อนว่าจะใช้ key อะไร”. นี่คือจุดที่ Symmetric แสดงจุดอ่อนใหญ่ที่สุดของตระกูล

ปัญหาใหญ่ของ Symmetric — Key Distribution#

ลองคิดต่อ — ถ้าคุณกับเพื่อนเจอกันที่ร้านกาแฟ คุณเขียน key ใส่กระดาษส่งให้เพื่อนก็จบ. แต่ถ้าคุณ 2 คนอยู่คนละประเทศล่ะ จะส่ง key ไปยังไง?

• ส่งทาง email — email ก็ผ่านอินเทอร์เน็ต คนกลางอ่านได้
• ส่งทาง chat — เหมือนกัน chat provider เห็น
• โทรศัพท์อ่าน key 256 ตัวให้ฟัง — ใช้ได้ แต่อาจถูกดักฟัง และผิดพลาดง่าย
• ส่งทาง courier กระดาษ — ปลอดภัย แต่ช้า และไม่ scale

นี่คือปัญหาที่เรียกว่า Key Distribution Problem (ปัญหาการแจกจ่ายกุญแจ) — ปัญหาที่ใช้เวลา มากกว่า 2,000 ปี ก่อนวงการจะหาทางออกได้ (ทางออกคือ Asymmetric ใน EP.21)

แย่กว่านั้นคือปัญหา scale. สมมติบริษัทคุณมีพนักงาน 1,000 คน ทุกคนต้องคุยกันลับๆ. จำนวน key ที่ต้องแจกจ่าย = n(n-1)/2 = 1,000 × 999 / 2 = 499,500 keys. นี่คือ 5 แสน key ที่ต้องสร้าง + แจกจ่าย + เก็บรักษา + เปลี่ยนเป็นระยะ. ฝันร้ายของ admin

แต่ และนี่คือ “แต่” สำคัญ — Symmetric ดี + เร็วมาก เมื่อ key อยู่ในมือทั้ง 2 ฝ่ายแล้ว. เร็วกว่า Asymmetric เป็นพันเท่า. ดังนั้นในระบบจริง Asymmetric ใช้ตอน “หาทาง” (key exchange) แค่วินาทีเดียว เพื่อ “ส่งกุญแจ Symmetric” ให้กันได้ปลอดภัย. หลังจากนั้น Symmetric รับช่วงต่อ ขนข้อมูล GB เป็นชั่วโมง. นี่คือ hybrid system ที่ทุกระบบ crypto สมัยใหม่ใช้ (TLS, Signal, WhatsApp ทั้งหมด)

ผมจะย้ำอีกครั้ง — อย่ามองว่า Symmetric vs Asymmetric เป็นคู่แข่ง. ทั้ง 2 ทำงานคนละ role. Symmetric = ขนของหลัก. Asymmetric = ส่งกุญแจให้กันก่อน. คนละหน้าที่ ทำงานคู่กัน

มุมผู้บริหาร: เวลาทีม IT พูดว่า “เราใช้ AES” — ถามต่อทันทีว่า “แล้ว key แจกยังไง?” ถ้าตอบ “hardcode ในโค้ด” = ผิดมาก (โจรเปิด source code = ได้ key). ถ้าตอบ “ใน config file” = อ่อนแอ. ถ้าตอบ “ใช้ KMS ของ AWS/Azure/GCP” = ถูกต้อง. key distribution คือจุดอ่อนของ Symmetric — และเป็นจุดที่บริษัทไทยส่วนใหญ่ทำผิดที่สุด

ก่อนยุค AES — DES ครองวงการ 25 ปี#

ย้อนกลับไปปี 1976 — IBM ร่วมกับ NSA ออก DES (Data Encryption Standard) — เป็นมาตรฐานเข้ารหัสของอเมริกา. DES ใช้ key ขนาด 56 bit. ในยุคที่ computer ใช้กระดาษเจาะรู — 56 bit คือยักษ์ใหญ่

DES ครองวงการมา 20 กว่าปี. ทุกธนาคารใช้. ทุกระบบรัฐบาลใช้. SSL ในยุคแรกใช้

แต่ปัญหามาในปี 1997-1998 — DESCHALL Project (กลุ่มนักวิจัยอินเทอร์เน็ตที่ระดมเครื่องคอมพิวเตอร์ของอาสาสมัครทั่วโลกมาช่วย) — ใช้เวลา 96 วันแตก DES key. ปีถัดมา ปี 1999 — EFF (Electronic Frontier Foundation) สร้างเครื่อง Deep Crack มูลค่า 250,000 ดอลลาร์ — แตก DES ภายใน 22 ชั่วโมง

แปลภาษาคน — DES ตายในวงการตั้งแต่ปี 1999. และ NSA + NIST รู้ตัวก่อนหน้านั้นแล้ว — จึงเปิดการแข่งขันหามาตรฐานใหม่ตั้งแต่ปี 1997 ครับ

NIST AES Competition (1997-2001) — การแข่งขันระดับโลก#

ในปี 1997 — NIST (National Institute of Standards and Technology) ของอเมริกาประกาศ “ใครก็ได้ในโลก ส่ง algorithm มาให้เราตรวจ. เราจะคัด algorithm ที่ดีที่สุดมาเป็นมาตรฐานใหม่ของอเมริกา”

นี่คือเรื่องที่ใหญ่ในวงการครับ. ก่อนหน้านี้ มาตรฐาน crypto ของอเมริกาทำในห้องลับของ NSA ทั้งหมด. ครั้งนี้ NIST เปิดให้ทั่วโลกส่ง — transparent เปิดให้นักวิจัยทุกคนช่วยตรวจสอบ. นี่คือการเปลี่ยน paradigm ครั้งใหญ่

มีทีมส่ง algorithm มา 15 ทีม จาก 12 ประเทศ. ในรอบสุดท้ายเหลือ 5 ทีม. และในปี 2000 NIST ประกาศผล — Rijndael ชนะ ออกแบบโดย 2 นักวิจัยเบลเยียม — Vincent Rijmen และ Joan Daemen

ลองสังเกตจุดสำคัญครับ — algorithm ที่ชนะการแข่งขัน crypto ที่สำคัญที่สุดในประวัติศาสตร์ ออกแบบโดยคนเบลเยียม 2 คน ไม่ใช่อเมริกัน. นี่คือสัญญาณว่า NIST จริงจังกับ “open competition” ไม่ใช่แค่หาทาง legitimize algorithm ของตัวเอง

ในปี 2001 — Rijndael ได้รับการประกาศเป็น AES (Advanced Encryption Standard) อย่างเป็นทางการ. ตั้งแต่นั้นมา — AES = มาตรฐานของอเมริกา + ลามไปทั่วโลกอย่างรวดเร็ว

AES-128 / AES-192 / AES-256 — 3 variant แตกต่างยังไง?#

AES มาในรูปแบบ 3 variant — ต่างกันที่ขนาดของ key:

• AES-128 — key 128 bit (16 byte)
• AES-192 — key 192 bit (24 byte)
• AES-256 — key 256 bit (32 byte)

ความหมายของขนาด key คือ — จำนวนความเป็นไปได้ของ key. ลองคำนวณดู:

• AES-128: 2^128 = 3.4 × 10^38 ความเป็นไปได้
• AES-256: 2^256 = 1.16 × 10^77 ความเป็นไปได้

ตัวเลขใหญ่จนคนอ่านไม่ออก. ลองภาษาคน — AES-128 — ถ้าใช้ computer ทุกเครื่องในโลก brute force พร้อมกัน — ใช้เวลามากกว่าอายุของจักรวาล. AES-256 — มากกว่านั้นอีกล้านล้านเท่า

ในทางปฏิบัติ — AES-128 ยังถือว่าปลอดภัยมากในปี 2026. AES-256 เผื่อสำหรับยุค quantum computer ที่อาจมาในอนาคต. ในชีวิตจริง — เลือกใช้ AES-256 ถ้าทำได้ (overhead ความเร็วต่างกันน้อยกว่า 30%)

ทำไม AES ยังไม่ถูก break หลังผ่าน 25 ปี?#

คำถามที่นักวิจัยทั่วโลกพยายาม attack AES มา 25 ปี — ทำไมมันยังแข็งแรงอยู่?

คำตอบสั้นๆ — เพราะการออกแบบของมันผ่านการตรวจสอบที่ละเอียดที่สุดในประวัติศาสตร์ crypto. ตั้งแต่ปี 1998 ถึง 2026 — มีนักวิจัยจากทุกประเทศพยายามหาช่องโหว่. ผ่าน 25+ การประชุม crypto ระดับโลก. ผ่าน 1,000+ paper ที่วิเคราะห์ AES

ผลคือ — มี theoretical attack บางตัวที่ break AES ได้ — แต่ต้องใช้ data 2^126 block + เวลา 2^88 — ตัวเลขที่ใช้ทรัพยากรมากกว่าจักรวาลทั้งใบ. ในทางปฏิบัติ = ไม่ถูก break

นี่คือเหตุที่ AES ยังครองวงการในปี 2026. และในความเป็นไปได้สูงสุด — AES จะยังครองวงการต่อไปอีก 10-20 ปี ก่อนถึงยุค post-quantum crypto

มุมผู้บริหาร: ถ้าทีม IT บอกว่า “เราใช้ AES” — ถามต่อ 2 ข้อ — (1) “AES-128 หรือ AES-256?” (2) “Mode of Operation อะไร — ECB / CBC / GCM / CTR?”. ถ้าตอบ “AES-256 + GCM” = ✅ ดีที่สุดในปี 2026. ถ้าตอบ “AES + ECB” = 🚨 ผิดมาก (รายละเอียดในหัวข้อ 4). ถ้าตอบ “ไม่รู้ — library default” — ขอให้ dev ตรวจซะ. AES ไม่ใช่ความเสี่ยง — แต่ AES ที่ใช้ผิด mode = ความเสี่ยงระดับสูง

Block Cipher — เครื่องผลิตขนมที่ทำทีละกล่อง#

ลองนึกภาพโรงงานขนมที่มีเครื่องบรรจุที่ทำงานแบบนี้ — ใส่ขนม 16 ชิ้น → เครื่องทำงาน → ออกมาเป็นกล่อง 1 กล่อง. ถ้าคุณมีขนม 100 ชิ้น เครื่องทำ 7 รอบ (= 6 กล่องเต็ม + 1 กล่องเหลือ 4 ชิ้น). กล่องที่เหลือ 4 ชิ้น ต้องเติม filler (ฟองน้ำ) ให้เต็ม 16 ชิ้นก่อน เครื่องถึงจะทำงานได้

นี่คือ Block Cipher — AES คือตัวอย่างที่สำคัญที่สุด

AES ทำงานแบบ process 128 bit ต่อ 1 รอบ. แปลภาษาคน — input 16 byte (= 128 bit) → คำนวณ → output ciphertext 16 byte. ถ้า plaintext ของคุณมีขนาด 100 byte AES ทำงาน 7 รอบ (6 block เต็ม + 1 block สุดท้ายที่ต้องเติม padding ให้ครบ 16 byte ก่อน)

ใน 1 รอบของ AES มี 10 / 12 / 14 รอบย่อย (สำหรับ AES-128 / 192 / 256 ตามลำดับ). แต่ละรอบย่อยทำ 4 operation — SubBytes (เปลี่ยน byte ตาม lookup table), ShiftRows (เลื่อนแถว), MixColumns (คณิตศาสตร์ใน Galois field), AddRoundKey (XOR กับ key). คุณไม่ต้องจำขั้นตอน แค่รู้ว่ามันซับซ้อนพอที่จะกัน statistical analysis

จุดสำคัญที่ผู้บริหารต้องรู้คือ Block Cipher ดีสำหรับข้อมูลขนาดที่ทราบล่วงหน้า (ไฟล์, database row, ข้อความ) แต่อาจไม่ดีที่สุดสำหรับ streaming data (วิดีโอ live, conversation real-time) ที่ไม่รู้ขนาดล่วงหน้า

Stream Cipher — สายพานต่อเนื่องที่ผลิตทีละชิ้น#

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

นี่คือ Stream Cipher — ChaCha20 คือตัวอย่างยอดนิยมในปี 2026

Stream Cipher ทำงานแบบ — สร้าง keystream ยาวๆ จาก key + nonce → XOR keystream กับ plaintext ทีละ bit → ได้ ciphertext. การถอดรหัส = ทำเหมือนกันอีกครั้ง (XOR เหมือนเดิม — ทาง 2 ทาง)

ChaCha20 — สร้างโดย Daniel J. Bernstein (DJB — นักวิจัย crypto ที่เคยฟ้องชนะรัฐบาลอเมริกาเรื่อง crypto export ในยุค 90s) ในปี 2008. ตัว Bernstein ออกแบบให้ — เร็วบน CPU mobile ที่ไม่มี hardware acceleration สำหรับ AES

อ้าว ทำไม mobile ถึงเป็นปัญหา?

ทำไม Google เลือก ChaCha20 สำหรับ Android — เรื่องของ hardware#

ตั้งแต่ Intel ออก AES-NI instruction set ในปี 2010 — CPU ทำ AES ได้เร็วมากในระดับ hardware. PC, laptop, server ทั้งหมดในยุคนี้มี AES-NI = AES เร็วมาก

แต่ — และนี่คือ “แต่” สำคัญ — CPU mobile (โดยเฉพาะรุ่นถูกสำหรับ developing market) บางตัวไม่มี hardware acceleration สำหรับ AES. ผลคือ — AES ทำงานช้าบน CPU mobile ราคาถูก = battery หมดเร็ว + lag

ในปี 2014 — Google เลือก ChaCha20 (จับคู่กับ Poly1305 สำหรับ integrity — รวมเป็น ChaCha20-Poly1305) เป็น cipher default ของ Chrome สำหรับ mobile. ทำไม? — ChaCha20 บน CPU ไม่มี AES-NI → เร็วกว่า AES 3 เท่า. แปลภาษาคน — มือถือราคาถูกในแอฟริกา/อินเดีย/ลาตินอเมริกาก็เปิด HTTPS ได้เร็วเหมือนเดิม

ในปี 2026 — ChaCha20-Poly1305 เป็น cipher option หลักใน TLS 1.3 คู่กับ AES-GCM. Server ปกติ support ทั้ง 2. Browser เลือกตามที่เหมาะกับ CPU ของ user

สรุปสั้นๆ — ใช้ตัวไหนเมื่อไหร่?#

• AES-GCM = default ในปี 2026 — ดีที่สุดถ้า CPU มี AES-NI
• ChaCha20-Poly1305 = ตัวเลือกที่ดีสำหรับ mobile + IoT + embedded device ที่ไม่มี hardware acceleration

ทั้งคู่ปลอดภัยพอๆ กัน. ไม่มีตัวไหน “ดีกว่า” ในเรื่อง security — แค่ performance ต่างกันบน hardware ต่างกัน

มุมผู้บริหาร: ถ้าทีม IT บอก “เราใช้ AES” — ผู้บริหารไม่ต้องบังคับให้เปลี่ยน. AES = standard. แต่ถ้าบริษัทคุณทำ mobile app — ถามต่อ “support ChaCha20-Poly1305 ในฝั่ง server ไหม?”. ถ้า support — user ที่ใช้มือถือราคาถูกในต่างจังหวัดจะได้ experience ที่ลื่นขึ้น. ต้นทุน — ฟรี (configuration ของ TLS server). ผลตอบแทน — ดีต่อ UX. นี่คือเรื่องเล็กแต่สำคัญสำหรับ business ที่มี user หลากหลายระดับ

ECB (Electronic Code Book) — DANGEROUS — ห้ามใช้#

ECB = mode ที่ง่ายที่สุด. แต่ละ block encrypt อิสระต่อกัน — ใช้ key เดียวกัน ใส่เข้าฟังก์ชัน encrypt ตรงๆ — ได้ ciphertext block ต่อ block

ฟังดูสมเหตุผลใช่ไหมครับ? แต่ปัญหาใหญ่คือ ถ้า plaintext มี block ที่ซ้ำกัน ciphertext ก็จะมี block ที่ซ้ำกันด้วย

ลองนึกภาพ — ถ้าคุณ encrypt ภาพสีดำล้วนขนาด 1,000 × 1,000 pixel ทุก block ของ pixel จะเหมือนกัน → ทุก block ของ ciphertext จะเหมือนกัน → โจรเห็น pattern ของภาพต้นฉบับใน ciphertext

นี่คือที่มาของภาพสอนที่เปลี่ยนวงการ — ECB Penguin

ECB Penguin — ภาพสอนที่ดังที่สุดในวงการ crypto#

ในปี 2003 มีนักวิจัยใน Wikipedia สร้างภาพประกอบเพื่อสอนนักเรียน security. ขั้นตอนคือ:

1. เอาภาพ Tux (mascot penguin ของ Linux — เพนกวินสีดำ-ขาว) เป็นต้นฉบับ
2. Encrypt ภาพนี้ด้วย AES ใน mode ECB
3. มอง ciphertext เป็นภาพ (interpret byte เป็น pixel)

ผลคือ — คุณยังเห็น penguin อยู่! สีอาจเปลี่ยน, pattern อาจสับสนเล็กน้อย แต่ภาพรวมยังเห็นเป็น penguin ชัดเจน

ทำไม? เพราะภาพ Tux มี region ที่สีเหมือนกันเป็นแถบใหญ่ (ท้องสีขาว, หลังสีดำ). region สีเหมือนกัน = plaintext block ซ้ำกัน = ciphertext block ซ้ำกัน → pattern ของ shape ยังคงอยู่ใน ciphertext

ภาพ ECB Penguin นี้ ตั้งแต่ปี 2003 กลายเป็นภาพสอน security ที่ดังที่สุดในประวัติศาสตร์. ใช้สอนนักเรียน computer science ทั่วโลก. ทุกหนังสือ crypto มีภาพนี้ครับ

แปลภาษาคน — ECB = encrypt แต่ pattern ของต้นฉบับยังเห็นได้. ถ้า plaintext มี structure ซ้ำๆ (เช่น header ของ file format, database row ที่ field ซ้ำกัน, ภาพ, รหัสบัตรประชาชนที่ขึ้นต้นด้วยจังหวัดเดียวกัน) ECB เปิดเผยข้อมูลเหล่านี้ทั้งหมด

ในปี 2026 — ECB = ห้ามใช้เด็ดขาด. ทุกตำราเรียน security ตั้งแต่ปี 2005 บอกตรงกัน. ทุก library crypto ที่ดีจะ warn เมื่อ dev เลือก ECB. แต่ในวงการบริษัทไทย ยังเจอ ECB ในระบบ legacy เยอะ. นี่คือ pattern คลาสสิคของวงการที่ผู้บริหารต้องระวัง

CBC (Cipher Block Chaining) — แก้ ECB ด้วย “ลูกโซ่”#

CBC = mode ที่ใช้กันแพร่หลายในยุค 2000s-2010s. แก้ปัญหา ECB ด้วยการ — ผูก block ต่อๆ กันเป็นลูกโซ่

ขั้นตอน:

1. ใส่ค่าสุ่ม IV (Initialization Vector) เป็น “block แรก” (สมมุติ)
2. Block 1 ของ plaintext XOR กับ IV → encrypt → ได้ ciphertext block 1
3. Block 2 ของ plaintext XOR กับ ciphertext block 1 → encrypt → ได้ ciphertext block 2
4. Block 3 → XOR กับ ciphertext block 2 → encrypt → ได้ ciphertext block 3
5. และต่อไปเรื่อยๆ

ผลคือ — block ที่ซ้ำกันใน plaintext จะให้ ciphertext ต่างกัน เพราะ XOR กับ block ก่อนหน้าที่ต่างกัน. ปัญหา ECB หายไป

CBC ครองวงการ TLS / VPN / file encryption มา 15 ปี. แต่ — มีปัญหา 2 ข้อที่ทำให้วงการเริ่มเลิกใช้:

1. Padding Oracle Attack — ในปี 2002 (ทฤษฎี) และปี 2010 (เคสจริง — ASP.NET) — นักวิจัยพบวิธี break CBC ผ่านการ exploit padding ที่ block สุดท้าย. รายละเอียดซับซ้อน — แต่ผลคือ — ถ้า server เปิดเผย error message ของ padding → โจรค่อยๆ decrypt ciphertext ทีละ byte ได้
2. Sequential — ไม่ parallelize — เพราะ block N ต้องรอ block N-1 จึงจะคำนวณได้ → encrypt ทีละ block ตามลำดับ → ช้าใน modern CPU multi-core

ในปี 2026 — CBC = ยังใช้ได้ ถ้า implement ถูกต้อง — แต่วงการแนะนำให้เปลี่ยนเป็น GCM

GCM (Galois/Counter Mode) — มาตรฐานใหม่ของวงการในปี 2026#

GCM = mode ที่ครองวงการในปี 2026. ออกแบบให้ — encrypt + integrity ในขั้นตอนเดียว — เรียกว่า Authenticated Encryption

ทำไม Authenticated Encryption สำคัญ? — เพราะ CBC + ECB ทำหน้าที่ confidentiality (อ่านไม่ออก) อย่างเดียว — แต่ไม่ทำ integrity (ตรวจว่าถูกแก้ไขหรือไม่). ผลคือ — โจรที่ไม่อ่าน plaintext ก็จริง — แต่เขา flip bit ใน ciphertext ได้ → ทำให้ decrypt ออกมาเป็น plaintext ที่ผิด → ระบบรับไปใช้โดยไม่รู้ตัว

GCM แก้เรื่องนี้ด้วยการ — คำนวณ authentication tag ติดมาด้วยกับ ciphertext. ตอน decrypt → ตรวจ tag ก่อน → ถ้า tag ผิด = reject ทันที. โจร flip bit = tag เปลี่ยน = reject

นอกจากนี้ GCM ยัง parallelize ได้ — encrypt แต่ละ block พร้อมกันได้ใน multi-core CPU → เร็วกว่า CBC มาก

ในปี 2026 — AES-GCM = default ของวงการ. TLS 1.3 บังคับใช้ Authenticated Encryption (GCM หรือ ChaCha20-Poly1305 เท่านั้น). WhatsApp / Signal / iMessage ทั้งหมดใช้ AES-GCM

CTR (Counter Mode) — block cipher ที่ทำตัวเหมือน stream#

CTR = mode ที่เปลี่ยน block cipher ให้ทำงานเหมือน stream cipher. หลักการคือ — ใช้ counter (1, 2, 3, …) + key → encrypt → ได้ keystream → XOR กับ plaintext → ได้ ciphertext

จุดเด่นของ CTR:

• parallelize ได้ — แต่ละ block อิสระจาก block อื่น
• ไม่ต้อง padding — เพราะทำงานเหมือน stream
• ใช้กับ streaming data ได้ดี — ไม่ต้องรอครบ block

ในวงการ — GCM ภายในใช้ CTR เป็นหัวใจ (Galois ภายนอก + Counter ภายใน). ดังนั้นถ้าคุณใช้ GCM = ใช้ CTR ทางอ้อมอยู่แล้ว

สรุปฉบับผู้บริหาร — ตารางคำตอบ CIO#

มุมผู้บริหาร: คำถาม stress test สำหรับ IT meeting ครั้งหน้า — “ระบบที่เราใช้ encryption — ใช้ AES mode อะไร? ขอเห็น code หรือ config ที่แสดง mode ที่ใช้จริง”. ถ้า dev ตอบ “ใช้ AES” อย่างเดียวโดยไม่บอก mode — = ทีมยังไม่เข้าใจ. ถ้าเจอ ECB ในระบบใดๆ ที่เก็บข้อมูลสำคัญ — 🚨 ต้องเปลี่ยนทันที. ภาพ ECB Penguin เป็นภาพที่ผู้บริหารควรขอให้ dev เปิดให้ดูในประชุม — เพื่อให้ทุกคนเห็นภาพชัดเจนว่า “ECB ที่ผิดวิธี — ภาพต้นฉบับยังเห็นได้”. ทุกคนจะจำเรื่องนี้ไปตลอดชีวิต

DES — ตายในวงการตั้งแต่ปี 1999#

DES (Data Encryption Standard) — เกิดปี 1976. ใช้ key 56 bit. ครองวงการ 20 ปี

ตายในปี 1999 เมื่อ EFF สร้าง Deep Crack แตก DES ภายใน 22 ชั่วโมง (เล่าไปแล้วในหัวข้อ AES)

ในปี 2026 — DES = ห้ามใช้เด็ดขาด. ทุก browser, ทุก library, ทุก compliance framework ห้ามใช้

3DES (Triple DES) — Deprecated โดย NIST ในปี 2023#

3DES — เป็นความพยายามต่อชีวิต DES ด้วยการ — ใช้ DES 3 ครั้งซ้อนกับ key ต่างกัน 3 ตัว. ผลคือ effective key size = 112 bit (ดีกว่า DES 56 bit)

3DES ครองวงการการเงิน + ATM + smart card ในยุค 2000s. ทำไม? — เพราะ hardware เก่าที่ใช้ DES อยู่แล้ว — upgrade เป็น 3DES ง่ายกว่าเปลี่ยนเป็น AES

แต่ปัญหาคือ — 3DES ช้ามาก (เพราะใช้ DES 3 ครั้ง) + มี theoretical attack ที่ใหม่ขึ้นเรื่อยๆ. ในปี 2017 — Sweet32 attack ทำให้ 3DES practical break ได้ในบางสถานการณ์

ในปี 2023 — NIST ประกาศ 3DES เป็น deprecated อย่างเป็นทางการ. ห้ามใช้ในระบบใหม่ตั้งแต่ปี 2023. ระบบเก่าต้อง migrate ภายในปี 2030

แปลภาษาคน — ถ้าระบบของบริษัทคุณยังใช้ 3DES ในปี 2026 — มีเวลาอีก 4 ปีในการ migrate. และนี่ไม่ใช่เรื่องเลือก — เป็นเรื่องบังคับสำหรับใครที่อ้างถึง NIST compliance

RC4 — Stream Cipher ที่ตายแล้วในปี 2015#

RC4 — Stream Cipher ที่ Ron Rivest (R ใน RSA) สร้างในปี 1987. เร็วมาก. ใช้กันแพร่หลายใน SSL/TLS ในยุคแรก, WEP (WiFi เก่า), MS Office encryption

แต่ RC4 มี bias ทางสถิติที่นักวิจัยพบตั้งแต่ปี 2001. ในปี 2013 — มี practical attack ที่ recover plaintext ของ TLS session ได้

ในปี 2015 — IETF ประกาศห้ามใช้ RC4 ใน TLS. ทุก browser ถอน RC4 support

ในปี 2026 — RC4 = ตายสมบูรณ์. แต่ในวงการบริษัทไทย — ยังเจอ RC4 ใน MS Office file ที่ถูก encrypt ก่อนปี 2015 อยู่บ่อย. และในระบบ WiFi เก่า (WEP) ที่บริษัทขนาดเล็กยังใช้

สรุป — algorithm ที่ใช้ได้ในปี 2026#

มุมผู้บริหาร: คำถามที่ผู้บริหารควรขอให้ทีม IT ตอบใน 30 วัน — “ระบบใดของเรายังใช้ DES / 3DES / RC4 อยู่บ้าง?” ถ้าตอบไม่ได้ = ทีมยังไม่มี encryption inventory ของบริษัท — และนี่เป็น control พื้นฐานที่ทุก audit framework (ISO 27001 / NIST CSF / PCI DSS) ตรวจสอบ

WhatsApp + Signal — AES-256-GCM ใน Signal Protocol#

WhatsApp (2 พันล้าน user ทั่วโลก) + Signal (app messaging ที่นักข่าวสายสืบสวน + activist ใช้) ทั้งคู่ใช้ Signal Protocol — protocol ที่ถูกออกแบบโดย Moxie Marlinspike ในปี 2013-2016

หัวใจของ Signal Protocol คือ — End-to-End Encryption ด้วย AES-256-GCM. ทุกข้อความที่คุณส่งใน WhatsApp — ถูก encrypt ด้วย AES-256-GCM ที่เครื่องคุณก่อนส่งไป server. WhatsApp server อ่านไม่ออก. ถอดรหัสได้แค่เครื่องของผู้รับเท่านั้น

แต่ — และนี่คือจุดที่ Symmetric เจอข้อจำกัด — key ที่ใช้ AES-256 มาจากไหน?. คำตอบคือ — Diffie-Hellman key exchange (Asymmetric) ที่เกิดขึ้นก่อนการสนทนา. นี่คือ hybrid system ที่ผมเล่าในหัวข้อ 1. EP.21 จะเจาะลึก Diffie-Hellman + RSA

Apple — AES ทุกที่ใน ecosystem#

Apple ใช้ AES ทั้ง stack:

• FileVault (encryption ของ MacBook hard disk) = AES-XTS (mode พิเศษสำหรับ disk)
• iCloud = AES-256 (สำหรับ data at rest)
• iMessage = AES-256 (กับ Asymmetric key exchange)
• Apple Pay = AES สำหรับ tokenization

ที่น่าสนใจ — Apple เป็นบริษัทที่ใส่ Hardware AES Acceleration ใน chip ตั้งแต่ปี 2010 (Apple A4). ทำให้ AES บน iPhone เร็วมาก = encryption แทบไม่กิน battery

บริษัทไทย — ใช้ AES ยังไง?#

ในวงการบริษัทไทย — pattern คลาสสิคในปี 2026 (ใน “เมือง” ฉบับไทยของเรา) เป็นแบบนี้ครับ:

• Banking — ทุกธนาคารใหญ่ใช้ AES-256 (PCI DSS บังคับ)
• Telco — AES สำหรับ SIM card + voice traffic
• eCommerce ใหญ่ — AES-GCM ใน TLS 1.3
• SME + Government legacy — ยังเจอ DES / 3DES / SHA-1 / Plain Text ตามที่เล่าใน EP.12

ถ้าบริษัทคุณยังอยู่ฝั่ง legacy — นี่คือ tech debt ที่ต้องวางแผน migrate เป็น priority สูง

2 Leader Takeaways#

Takeaway 1: ถามคำถามให้ถูก — “AES mode อะไร” สำคัญกว่า “ใช้ AES ไหม”

ในประชุม IT — เลิกถามแค่ “เราใช้ encryption ไหม”. เริ่มถาม “ใช้ AES mode อะไร — ECB / CBC / GCM?”. ความเข้าใจในระดับนี้ทำให้คุณเป็นผู้บริหารที่ทีม IT เคารพ. และเป็นเหตุที่หลายบริษัทไทยรอด breach ได้ — เพราะ executive ถามคำถามที่ทำให้ dev ต้องตรวจ implementation จริงๆ

Takeaway 2: encryption inventory คือพื้นฐาน — ทุก algorithm ที่ใช้ในบริษัท ต้องมี list

ผู้บริหารควรขอให้ทีม IT ทำ encryption inventory ของระบบทั้งหมด — algorithm อะไร / mode อะไร / key size เท่าไหร่ / key เก็บที่ไหน. ถ้าทีมตอบไม่ได้ — = ยังไม่มี basic security hygiene. ใน 30 วันแรก inventory ต้องเสร็จ. ใน 90 วันแรก migration plan ของ legacy algorithm ต้องมี. ไม่มี audit framework ไหนยอม company ที่ตอบเรื่อง encryption ไม่ได้

ปิดเรื่อง — และเปิดประตูสู่ EP.21#

Symmetric ดี + เร็ว — แต่ key distribution ยังเป็นปัญหา

ตลอด EP นี้ ผมเล่าซ้ำหลายครั้ง — Symmetric เก่งทุกอย่างยกเว้น “ส่งกุญแจให้กันยังไงให้ปลอดภัย”. นี่คือปัญหาที่วงการ crypto ใช้เวลามากกว่า 2,000 ปีจึงหาทางออกได้

คำตอบของปัญหานี้ — Asymmetric Cryptography — กล่องที่ 2 ของ 3 ตระกูลที่เราเล่าใน EP.19. EP.21 ผมพาคุณเดินออกจากกล่อง Symmetric — ไปยังอีกซอกของ “เมือง” ที่เราเดินกันมา — และเปิดกล่องนี้ — RSA + Diffie-Hellman — ที่จะตอบคำถาม “ส่งกุญแจให้กันยังไงโดยไม่ต้องเคยเจอกันมาก่อน”. เป็นเรื่องที่จะเปลี่ยนความเข้าใจของคุณเรื่อง security ทั้งหมด

คำตอบ — Asymmetric — EP.21 เจาะ