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

ในระบบ 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 เจาะ