ตัวอย่างที่ 1 — ทหาร 2 ฝ่ายที่ต้องส่งข้อความลับ#

ทหารฝ่าย A อยู่ที่กรุงเทพ ต้องส่งคำสั่งลับให้ทหารฝ่าย B ที่ภูเก็ต. ถ้าใช้ Symmetric — ทั้ง 2 ฝ่ายต้องมี กุญแจดอกเดียวกัน

คำถาม — กุญแจถูกส่งจากกรุงเทพไปภูเก็ตยังไง?

วิธีเดียวก่อน 1976 — ส่งคนถือกระเป๋าใส่กุญแจไปด้วยตัวเอง (พร้อมเครื่องบิน / รถยนต์ / นักการทูต / ตู้เซฟ). NSA ในยุค Cold War มี courier dedicated ที่บินทั่วโลกตลอดเวลา — แค่เพื่อส่ง encryption key ระหว่างฐานทัพ. ค่าใช้จ่ายมหาศาล — และยังไม่ปลอดภัย 100% (courier ถูก compromise ได้)

ตัวอย่างที่ 2 — ปัญหา N-squared#

ถ้าบริษัทมี 100 คนที่ต้องคุยกันแบบ encrypted — ใช้ Symmetric — ต้องการกุญแจกี่ดอก?

สูตรคือ N × (N-1) / 2 = 4,950 ดอก สำหรับ 100 คน

ถ้าบริษัทเพิ่มเป็น 1,000 คน → ต้องการ 499,500 ดอก. 10,000 คน → 49,995,000 ดอก. ตัวเลขมัน scale ไม่ได้. คน 1 คนต้องเก็บกุญแจ 999 ดอก (ที่ใช้คุยกับเพื่อนคนอื่นแต่ละคน) — และทุกครั้งที่มีคนใหม่เข้าบริษัท — ต้องสร้างกุญแจใหม่ N-1 ดอก + ส่งให้คนใหม่อย่างปลอดภัย

นี่คือ N-squared problem ที่ทำให้ Symmetric ใช้ในสเกลใหญ่ไม่ได้

Cold War + NSA — งานวิจัยที่ปิดลับ#

ในยุค 1960-1970 — NSA (National Security Agency ของสหรัฐ) เป็นองค์กรที่มี cryptographer มากที่สุดในโลก. งานวิจัยทั้งหมด เป็นความลับระดับชาติ — ห้ามตีพิมพ์ ห้ามแชร์ ห้ามแม้แต่บอกว่าตัวเองทำงาน NSA

มี ทฤษฎีที่ยังถกเถียงกัน ว่า — GCHQ (หน่วยข่าวกรองของอังกฤษ) จริงๆ แล้วค้นพบ public-key cryptography ก่อน Diffie-Hellman ประมาณ 5 ปี — โดยนักวิจัยชื่อ James Ellis, Clifford Cocks, Malcolm Williamson — แต่ ปิดลับ เป็นความลับทางทหารจน 1997 ถึงเปิดเผย. แปลว่า ถ้าเรื่องนี้จริง — โลกเรา อาจจะได้ใช้ Asymmetric ช้าไป 20 ปี เพราะรัฐบาลซ่อนไว้

1976 — Diffie-Hellman ออกเปเปอร์#

Whitfield Diffie เป็น cryptographer แนวคิด anti-establishment — เชื่อว่า cryptography เป็นของประชาชน ไม่ใช่ของรัฐบาล. เขาเดินทางทั่วอเมริกาเพื่อหาคนคิดเหมือนกัน — จนเจอ Martin Hellman ที่ Stanford. ทั้งคู่ทำงานด้วยกันจนคลอด เปเปอร์ “New Directions in Cryptography” ในเดือนพฤศจิกายน 1976

เปเปอร์นี้เสนอ idea ที่ฟังดูเป็นไปไม่ได้ — กุญแจ 2 ดอกที่จับคู่กัน ที่ดอกหนึ่งใช้ ล็อก อีกดอกใช้ เปิด — แต่ คนที่มีแค่ดอกล็อก เปิดของตัวเองไม่ได้

NSA ตกใจมาก. หลังเปเปอร์ออก — NSA พยายามขู่นักวิจัยให้หยุดวิจัย public key — ขู่ฟ้องว่าละเมิด export control. แต่ Diffie-Hellman ยืนยันว่ามันคืองานวิจัยพื้นฐาน — ไม่หยุด

1977 — RSA พิสูจน์ว่ามันทำได้จริง#

Diffie-Hellman เสนอ idea — แต่ตัวเขาเอง ยังไม่มีอัลกอริทึม ที่ทำได้จริง. 1 ปีต่อมา ที่ MIT — นักวิจัย 3 คน — Ron Rivest + Adi Shamir + Len Adleman — ใช้ คุณสมบัติของจำนวนเฉพาะขนาดใหญ่ (large primes) สร้าง algorithm ตัวแรกที่ทำงานได้จริง

อัลกอริทึมตัวนี้ใช้ตัวอักษรของนามสกุล 3 คน — RSA. ตีพิมพ์ในปี 1977 — และครองโลก crypto จนถึงปี 2026 (49 ปี — และยังไม่ตาย)

ทั้ง 3 คน ได้ Turing Award (Nobel Prize ของวงการ Computer Science) ในปี 2002

มุมผู้บริหาร: เรื่องราว Diffie-Hellman + RSA เป็นเครื่องเตือนใจว่า innovation ที่เปลี่ยนโลก มักมาจากนักวิจัยที่ไม่ฟังคำขู่ของรัฐบาล. ถ้าคุณคิดว่า cybersecurity ของบริษัทคุณ ไม่ต้องลงทุนใน research / training เพราะ “ใช้ของที่มีอยู่ก็พอ” — ลองคิดใหม่. TLS, HTTPS, Bitcoin, Apple Pay, iMessage — ทุกอย่างที่บริษัทคุณใช้ทุกวัน — เกิดเพราะนักวิจัย 5 คนที่กล้าตีพิมพ์งานที่รัฐบาลไม่อยากให้ตีพิมพ์. การสนับสนุน open research + cryptographer community = investment ที่ตอบแทนระยะยาวที่สุดในวงการ tech

Master metaphor — ตู้ไปรษณีย์ในเมือง#

ลองนึกครับ. ในเมืองของเรา (ที่ผมพาคุณดูตั้งแต่ EP.01) — ทุกบ้านมี ตู้ไปรษณีย์ หน้าบ้าน. ตู้นี้มี 2 ส่วน:

• ช่องบน (Public slot) — เปิดได้ตลอดเวลา — ใครก็เดินผ่านมาหย่อนจดหมายเข้าได้ — ไม่ต้องขออนุญาต ไม่ต้องนัด
• กุญแจล่าง (Private lock) — มีแค่ กุญแจ 1 ดอก ที่เปิดได้ — เจ้าของบ้านเก็บคนเดียว — ห้ามแจก

ถ้าผมต้องการส่งจดหมายลับให้คุณ:

1. ผมเดินไปหน้าบ้านคุณ — ใส่จดหมายเข้าช่องบน — เดินกลับ
2. โจรเดินผ่าน — ไม่สามารถดึงจดหมายออกจากช่องได้ (ออกแบบไว้แล้ว — ใส่ได้อย่างเดียว ไม่มีทางดึงคืน)
3. คุณกลับบ้าน — ใช้กุญแจล่างเปิด — อ่านจดหมาย

คำถามสำคัญ — ผมต้อง นัดกุญแจกับคุณก่อนไหม? — ไม่ต้อง. ตู้ไปรษณีย์เปิดอยู่หน้าบ้าน — ใครก็ใส่ได้

คำถามที่สอง — ถ้าโจรขโมยช่องบนทั้งช่อง ไปทำเลียนแบบ — โจรเปิดของในบ้านคุณได้ไหม? — ไม่ได้ — เพราะกุญแจล่างยังอยู่กับคุณ

คำถามที่สาม — ถ้าผมรู้ว่าช่องบนของคุณ “หน้าตา” ยังไง — ผมเดาได้ไหมว่ากุญแจล่างหน้าตายังไง? — ไม่ได้ — ออกแบบมาให้เดาไม่ออก (ตรงนี้คือคณิตศาสตร์ที่ Diffie-Hellman + RSA ค้นพบ)

นี่คือ Asymmetric encryption ในภาษาคน. ช่องบน = Public key. กุญแจล่าง = Private key

คณิตศาสตร์ที่ทำให้มันเวิร์ค — One-Way Function#

ทำไมมันเวิร์คได้จริง? — เพราะ math ของ one-way function — สิ่งที่ คำนวณไปข้างหน้าง่าย แต่ คำนวณย้อนกลับยากมาก

ตัวอย่างที่จับต้องได้ — ลองนึก ขวดน้ำสีที่ผสมกัน:

• เอาน้ำสีแดง + น้ำสีน้ำเงิน เทผสม = ได้น้ำสีม่วง (ง่ายมาก — เด็กก็ทำได้)
• แต่ถ้าเอา น้ำสีม่วง มา แล้วบอก — “แยกออกเป็นแดงกับน้ำเงินคืน” = ยากมาก ถ้าไม่มีเครื่องเคมีพิเศษ

Math ที่ RSA ใช้ เป็น one-way แบบนี้:

• คูณจำนวนเฉพาะ 2 ตัวใหญ่ๆ = ง่ายมาก. เอา prime A × prime B = N
• แยก N กลับเป็น A × B (factoring) = ยากมาก ถ้า N ใหญ่พอ. คอมพิวเตอร์ปัจจุบันใช้เวลาเป็น พันล้านปี factor RSA-2048

Math ที่ Diffie-Hellman ใช้ เป็น discrete logarithm — คล้ายกัน. คำนวณไปข้างหน้าง่าย — ย้อนกลับยาก

นี่คือเหตุผลที่ public key เปิดเผยได้ แต่ private key ดูจาก public key ไม่ออก — เพราะ math ออกแบบให้มัน ไม่สมมาตร

ทำไมเรียก “Asymmetric”#

ใน Symmetric (EP.20) — กุญแจ 1 ดอก ใช้ ทั้งล็อกและเปิด — สมมาตร (symmetric)

ใน Asymmetric — กุญแจ 2 ดอกที่ ทำหน้าที่ตรงข้ามกัน:

• ใส่ encryption ด้วย public → ถอด decryption ด้วย private
• เซ็น sign ด้วย private → ตรวจ verify ด้วย public

2 อย่างนี้ ใช้งานคนละ scenario แต่ใช้ math เดียวกัน. ตู้ไปรษณีย์ใช้สำหรับ encryption (ใครก็ส่งของลับให้คุณได้). Digital signature (หัวข้อท้าย EP) ใช้ตรงข้ามกัน — คุณเซ็นด้วย private — ใครก็ตรวจ verify ได้ด้วย public ของคุณ

มุมผู้บริหาร: หัวใจของ Asymmetric ที่ผู้บริหารต้องเข้าใจคือ — public key ไม่ใช่ความลับ. มันถูกออกแบบมาให้ แจกได้ทั่วโลก. ถ้าคุณเห็นทีม IT ของบริษัท “ปิดบัง public key” หรือ “ไม่ยอมแชร์ certificate” — แสดงว่าทีมยังไม่เข้าใจหลักการของ Asymmetric. ที่ต้องปิดเป็นความลับมีอย่างเดียว — private key. ความสับสนตรงนี้เป็น pattern คลาสสิคของบริษัทที่ใช้ encryption ใหม่ๆ — เคสที่เจอได้ทั่วไปคือ พนักงานเอา private key อัปขึ้น GitHub โดยไม่รู้ตัว = ระบบ encryption พังทันที

RSA ทำงานยังไง (intuition)#

ผมจะไม่พาคุณคำนวณสมการ. ขอแค่ให้คุณเข้าใจ 3 ขั้นตอน:

1. เลือก prime 2 ตัวใหญ่ๆ — สมมุติ p และ q (ขนาด 1024 bits แต่ละตัว สำหรับ RSA-2048)
2. คูณ p × q = N — N เรียกว่า modulus. N นี้เป็นส่วนหนึ่งของ public key (เปิดเผยได้)
3. คำนวณกุญแจคู่ — ได้ public exponent (e) + private exponent (d) ที่จับคู่กันด้วยสูตร math

Public key = (N, e) → แจกได้ Private key = (N, d) → เก็บลับ

ความปลอดภัยของ RSA = ยากที่จะ factor N กลับเป็น p × q. ถ้า attacker factor ได้ → คำนวณ d ออกได้ → พังทันที

Key size = ความปลอดภัย#

ตัวเลขที่เห็นใน RSA-NNNN = ขนาด N เป็น bits. ยิ่งใหญ่ — ยิ่ง factor ยาก

ในปี 2026 — มาตรฐานวงการ:

• RSA-1024 — deprecated — ห้ามใช้แล้ว. computer สมัยใหม่ + cloud computing factor ได้ในเวลาที่ยอมรับได้. NIST + ทุก compliance ห้ามใช้ตั้งแต่ 2013
• RSA-2048 — มาตรฐานปัจจุบัน สำหรับใช้ทั่วไป. ปลอดภัยถึงประมาณ 2030
• RSA-3072 — recommended สำหรับ ข้อมูลที่ต้องอยู่นานกว่า 2030 (long-lived secrets, root CA certificate)
• RSA-4096 — ใช้สำหรับ root CA / ระบบทหาร / ระบบที่ paranoid เป็นพิเศษ. แต่ช้ามาก — ไม่เหมาะกับ web traffic ปริมาณสูง

ทุกๆ การเพิ่ม bit ใน RSA — ช้าลงเป็นสัดส่วน cubic (เพิ่มเลข 2 เท่า = ช้าลง 8 เท่า). นี่คือเหตุที่บริษัท web traffic สูง — ไม่ใช้ RSA-4096 ทุกที่

RSA ใช้ทำอะไรในวงการจริง#

ในโลก 2026 — RSA ใช้ใน:

• TLS certificate ของเว็บไซต์ — ส่วนใหญ่ยังเป็น RSA-2048 (กำลังย้ายไป ECC)
• Code signing — Windows / macOS ใช้ RSA ตรวจว่า software มาจากผู้ผลิตจริง
• iMessage E2EE — Apple ใช้ RSA-1280 (older) + AES สำหรับเข้ารหัสข้อความ
• PGP / GPG — สำหรับ encrypt email + เซ็น software releases
• SSH key — ที่ developer ใช้ login server ทุกวัน (ssh-rsa)
• JWT signing — RS256 algorithm ใน JWT คือการเซ็น token ด้วย RSA

ข้อจำกัดของ RSA — ช้า + ใหญ่#

RSA มีข้อเสียที่ engineering team ทุกที่รู้กัน:

• ช้า — RSA-2048 encryption operation ช้ากว่า AES-256 ประมาณ 1,000 เท่า
• encrypt ข้อมูลขนาดใหญ่ไม่ได้โดยตรง — RSA-2048 encrypt ได้แค่ 245 bytes ต่อ operation
• key size ใหญ่ — RSA-2048 public key = 256 bytes. ECC-256 public key = 32 bytes (8 เท่า)

วิธีแก้ในวงการจริง — Hybrid encryption — ใช้ RSA แค่เพื่อ encrypt symmetric key แล้วใช้ symmetric key (เช่น AES-256) encrypt data ตัวจริง. คือ Asymmetric ทำงาน “ส่งกุญแจ” + Symmetric ทำงาน “เข้ารหัสข้อมูลจริง”

นี่คือ pattern ที่ใช้ทุกที่ — TLS, iMessage, WhatsApp, PGP, S/MIME

Quantum threat — RSA จะตายเมื่อไหร่#

RSA พึ่งพา prime factorization ยาก — แต่ในปี 1994 นักคณิตศาสตร์ Peter Shor เสนอ algorithm ที่ quantum computer ใช้ factor ได้เร็ว (เรียกว่า Shor’s algorithm)

ในปี 2026 — quantum computer ยัง ไม่มีขนาดใหญ่พอ จะ factor RSA-2048. แต่ทุก expert ในวงการเห็นพ้องว่า ในช่วง 10-20 ปีข้างหน้า มันจะมา. NIST จึงประกาศ Post-Quantum Cryptography (PQC) มาตรฐานในปี 2024 — algorithms ใหม่ที่ทนต่อ quantum (CRYSTALS-Kyber, CRYSTALS-Dilithium)

มุมผู้บริหาร: RSA จะไม่ตายเร็ว — แต่ผู้บริหารต้องวางแผน crypto agility — ความสามารถของระบบในการ เปลี่ยน algorithm ได้โดยไม่ rewrite ทั้งระบบ. pattern คลาสสิคของบริษัทไทยคือ — hardcode “RSA-2048” ในโค้ดทุกที่ — วันที่ต้องย้ายไป PQC = rewrite 6 เดือน. คำถามที่ผู้บริหารควรถามทีม dev: “ถ้าวันหนึ่ง NIST ประกาศว่า RSA-2048 ไม่ปลอดภัยแล้ว — บริษัทเราใช้เวลากี่วันในการเปลี่ยน?” ถ้าคำตอบมากกว่า 90 วัน = คุณมีหนี้ technical ที่อันตราย

ECC คืออะไร (intuition)#

ECC ใช้ math คนละชุดกับ RSA — แทนที่จะใช้ prime factorization ECC ใช้ discrete logarithm บน elliptic curve (เส้นโค้งวงรี)

intuition ที่จับต้องได้:

• ใน RSA — security มาจาก “factor prime ใหญ่ๆ ยาก”
• ใน ECC — security มาจาก “คำนวณ point บน elliptic curve ย้อนกลับยาก”

ทั้งคู่เป็น one-way function — แต่ math ของ ECC มี efficiency สูงกว่า — ต้องการ bits น้อยกว่ามาก ในระดับความปลอดภัยเท่ากัน

ตารางเปรียบเทียบที่สำคัญที่สุดของหัวข้อนี้#

อ่านตารางนี้แล้วเห็นภาพได้ทันที — ECC-256 ให้ความปลอดภัยเทียบเท่า RSA-3072 — แต่ key size เล็กกว่า 12 เท่า

ทำไม ECC ครอง mobile + cloud#

ในปี 2026 — เกือบทุกระบบใหม่ที่ design ใน 5 ปีที่ผ่านมา ใช้ ECC. เหตุผล:

1. เล็กกว่า — เร็วกว่า — ส่ง public key ผ่าน network เร็วกว่า, sign/verify operation เร็วกว่า. สำหรับมือถือที่มี bandwidth + CPU + battery จำกัด = เปลี่ยนชีวิต
2. ประหยัด battery — มือถือทำ crypto operation น้อยลง = แบตอยู่ได้นานกว่า
3. TLS 1.3 มาตรฐาน — IETF ผลักดัน ECC เป็นมาตรฐานหลักของ TLS 1.3
4. HTTPS handshake เร็วขึ้น — เว็บที่ใช้ ECC โหลดเร็วกว่าเว็บที่ใช้ RSA (ในการ handshake ครั้งแรก)

ECC ในของจริงที่คุณใช้ทุกวัน#

• TLS 1.3 / HTTPS — ทุกเว็บไซต์ใหญ่ในปี 2026 ใช้ ECDHE (ECC variant ของ Diffie-Hellman) + ECDSA signature
• Bitcoin / Ethereum — wallet ของ blockchain ทั้งหมด ใช้ ECC secp256k1 (ตัวเดียวกันทั้ง 2 ระบบ) เซ็น transaction
• Apple Secure Enclave — chip security ของ iPhone ใช้ ECC สำหรับ key ที่เก็บใน hardware
• Google Titan key — security key ของ Google ใช้ ECC
• WhatsApp / Signal — Signal protocol ใช้ Curve25519 (ECC variant) สำหรับ key exchange
• SSH key สมัยใหม่ — ssh-ed25519 (ECC) แทน ssh-rsa เพราะเล็กกว่า + เร็วกว่า
• JWT ES256 — JWT ที่เซ็นด้วย ECC แทน RS256

ECC ไม่ใช่ algorithm เดียว — มี curve หลายแบบ#

ในวงการมี elliptic curve มาตรฐาน หลายชุด — แต่ที่นิยมจริงๆ คือ:

• secp256r1 (P-256) — มาตรฐาน NIST. ใช้ใน TLS เป็นหลัก
• secp256k1 — มาตรฐานที่ Bitcoin + Ethereum ใช้ (Koblitz curve)
• Curve25519 (Ed25519 for signatures) — โดย Daniel J. Bernstein. ออกแบบให้ปลอดภัย + เร็ว + ทน side-channel attack. WhatsApp / Signal / SSH สมัยใหม่ใช้ตัวนี้

ในวงการ — มี suspicion ว่า NIST curves (P-256) อาจถูก NSA fix parameter ให้มี backdoor (เรื่อง Dual_EC_DRBG ในปี 2013 ทำให้คนสงสัย). คนที่ paranoid ใช้ Curve25519 เพราะ Bernstein ออกแบบเปิดเผยทั้งหมด

มุมผู้บริหาร: ถ้าบริษัทคุณกำลังจะ build product ใหม่ที่ใช้ encryption — default คือ ECC ไม่ใช่ RSA. RSA ยังใช้ต่อสำหรับ legacy compatibility — แต่ทุก system ใหม่ที่ design ในปี 2026 ควรเริ่มที่ ECC. ลองถามทีม dev ของคุณ — “ระบบเราใช้ ECC หรือ RSA?” — ถ้าคำตอบคือ “RSA-2048” สำหรับ product ใหม่ปี 2024+ = ทีม dev ใช้ pattern เก่า — ควร upgrade. ECC ลด cost ของ infrastructure + cloud bandwidth ได้จริง (เคสที่เจอได้ทั่วไป — เว็บที่ traffic สูง ย้ายจาก RSA ไป ECC ลด CPU cost บน load balancer 30-40%)

ปัญหาที่ Diffie-Hellman แก้#

ผมยกตัวอย่างให้เห็นภาพ — TLS handshake ของ HTTPS

ตอนคุณเปิดเว็บ google.com — มันเกิดอะไรขึ้น:

1. Browser คุณ + Google server ต้อง agree on symmetric key เพื่อใช้ AES encrypt traffic ทั้ง session
2. แต่ 2 ฝ่ายยังไม่เคยคุยกันมาก่อน — ไม่มี shared secret
3. คำถาม — สร้าง symmetric key ร่วมกันได้ยังไง โดยไม่ส่งกุญแจผ่าน network?

Diffie-Hellman magic — สร้างกุญแจร่วมโดยไม่ส่งกุญแจ#

นี่คือ magic ที่ Diffie-Hellman คิดในปี 1976. ผมจะใช้ analogy ที่จับต้องได้ — น้ำสีที่ผสมกัน

ลองนึกครับ. Alice + Bob ต้องการสร้าง กุญแจสีลับ ร่วมกัน. โจร (Eve) แอบดูทุกขั้นตอน

1. Alice + Bob agree publicly ว่าใช้ “สีเหลือง” เป็นสีฐาน (ทุกคนเห็นได้ — รวมถึง Eve)
2. Alice เลือกสีลับของตัวเอง = สีแดง (Eve ไม่เห็น). ผสมเหลือง + แดง = ส้ม — ส่งส้มให้ Bob
3. Bob เลือกสีลับของตัวเอง = สีน้ำเงิน (Eve ไม่เห็น). ผสมเหลือง + น้ำเงิน = เขียว — ส่งเขียวให้ Alice
4. Alice เอา เขียว ที่ได้ + แดง ลับของตัวเอง ผสม → ได้สีน้ำตาล
5. Bob เอา ส้ม ที่ได้ + น้ำเงิน ลับของตัวเอง ผสม → ได้สีน้ำตาล (เหมือนกัน!)
6. Alice + Bob ได้ สีน้ำตาลร่วมกัน ทั้งคู่ — โดยที่ไม่เคยส่งสีน้ำตาลผ่าน network

Eve เห็นอะไร? — เห็นแค่ เหลือง / ส้ม / เขียว. เพื่อจะได้สีน้ำตาล — Eve ต้อง แยก ส้ม ออกเป็น เหลือง + แดง (one-way function — ทำไม่ได้). หรือ แยก เขียว ออกเป็น เหลือง + น้ำเงิน (ทำไม่ได้เช่นกัน)

นี่คือ Diffie-Hellman key exchange ในภาษาคน. ใน reality — สีคือ ตัวเลขใหญ่ๆ ที่คำนวณด้วย discrete logarithm

Diffie-Hellman = ส่งกุญแจ Symmetric#

หัวใจของ DH คือ — มัน ไม่ใช่ encryption ของข้อมูล. มันคือ กลไกในการสร้าง shared secret ระหว่าง 2 ฝ่ายที่ไม่เคยรู้จักกัน

ใน TLS — DH สร้าง shared secret → ใช้ shared secret เป็น AES key → ใช้ AES encrypt traffic ทั้ง session

นี่คือ hybrid ตัวจริงของ web — Asymmetric (DH) ใช้สร้างกุญแจ + Symmetric (AES) ใช้ encrypt data

ECDH — Diffie-Hellman บน Elliptic Curve#

ECDH = ECC version ของ Diffie-Hellman. ใช้ elliptic curve แทน discrete logarithm — เร็วกว่า + เล็กกว่า

ใน TLS 1.3 — ECDHE (E = Ephemeral — สร้างใหม่ทุก session) เป็น default key exchange. ทุก HTTPS handshake ในปี 2026 ใช้ ECDHE

Perfect Forward Secrecy (PFS) — มหาคุณสมบัติของ Ephemeral#

ผมขอเน้นจุดนี้ — เพราะมันคือสิ่งที่ผู้บริหารต้องเข้าใจที่สุดของ EP นี้

Perfect Forward Secrecy (PFS) = คุณสมบัติที่ ถ้าวันหนึ่ง private key ของ server หลุด — session ในอดีตที่ encrypt ด้วย shared secret จาก DH — ยัง decrypt ไม่ได้

ลองนึก scenario นี้ครับ:

• 2024 — บริษัท X ใช้ HTTPS — Eve บันทึก encrypted traffic ทุกอย่างไว้
• 2027 — Eve hack ได้ private key ของ server บริษัท X
• คำถาม — Eve decrypt traffic ปี 2024 ได้ไหม?

ไม่มี PFS (static RSA key exchange ของ TLS 1.2 รุ่นเก่า) → decrypt ได้ — เพราะ traffic ปี 2024 encrypt ด้วย key ที่ derive จาก private key ของ server. private key หลุด = decrypt ของเก่าได้หมด

มี PFS (TLS 1.3 ECDHE) → decrypt ไม่ได้ — เพราะแต่ละ session ใช้ ephemeral key ที่ ถูกทิ้งหลังจาก session จบ. private key ของ server ไม่ได้ใช้ encrypt traffic — ใช้แค่ authenticate ว่า server คือใคร

นี่คือเหตุที่ TLS 1.3 บังคับ PFS — และ TLS 1.2 หลายๆ cipher suite ที่ไม่มี PFS ถูก deprecated ใน compliance ทุกตัว (PCI-DSS, FIPS)

PFS ในของจริง#

• TLS 1.3 — บังคับ ECDHE — PFS by default
• Signal Protocol — ใช้ Double Ratchet — สร้าง ephemeral key ทุกข้อความ (ไม่ใช่แค่ทุก session)
• WhatsApp — ใช้ Signal Protocol — มี PFS ทุก message
• WireGuard VPN — ใช้ ECDH key rotation ทุก 2 นาที — PFS เต็มรูปแบบ
• TLS 1.2 cipher suite ที่มี “DHE” หรือ “ECDHE” ในชื่อ — มี PFS. cipher suite ที่ขึ้นต้นด้วย “RSA_” — ไม่มี PFS (deprecated)

มุมผู้บริหาร: Perfect Forward Secrecy = insurance ระยะยาว ที่ผู้บริหารควรบังคับ. คำถามที่ควรถามทีม IT ของคุณ: “HTTPS ทั้งหมดของบริษัทเราใช้ TLS 1.3 ไหม? ถ้าใช้ TLS 1.2 — cipher suite ทั้งหมดมี ECDHE ไหม?”. ถ้าคำตอบไม่ชัดเจน = ลองตรวจด้วย SSL Labs Test (ฟรี). pattern คลาสสิคของวงการคือ — บริษัทมี HTTPS ครบทุกเว็บ — แต่ใช้ cipher ที่ไม่มี PFS — แปลว่าถ้า server โดน hack วันใด traffic ของลูกค้าทั้ง 5 ปีย้อนหลังที่ถูก record ไว้ — decrypt ได้หมด. PFS = control ที่ฟรี (แค่ config TLS) แต่ ROI สูงมาก

กลับด้าน — เซ็นด้วย Private, ตรวจด้วย Public#

ใน encryption — public ใช้ล็อก / private ใช้เปิด. ใน signature — กลับด้าน:

• Private key ใช้เซ็น (sign) — มีคนเดียวที่เซ็นได้ (เจ้าของ key)
• Public key ใช้ตรวจ (verify) — ใครก็ตรวจได้ว่า signature นี้มาจากเจ้าของ public key นั้นจริงไหม

ทำไมมันเวิร์ค? — เพราะ math ของ Asymmetric ออกแบบให้ 2 operation สมมูลกัน — sign กับ encrypt เป็นการดำเนินการเดียวกันแค่ “ฝั่งกลับกัน”

Analogy — ลายเซ็นด้วยกุญแจในเมือง#

ลองนึกครับ. ในเมืองของเรา — ทุกคนมี ตราประทับส่วนตัว (private key) — ที่ไม่มีใครปลอมได้. และทุกคน ลงทะเบียนตราประทับของตัวเอง ในระบบประจำเมือง (public key registry)

ผมต้องการเซ็นเอกสารให้คุณ:

1. ผม กดตราของผม ลงเอกสาร → เอกสารตอนนี้มี signature
2. ผมส่งเอกสารให้คุณ
3. คุณ ดึง public key ของผม จาก registry — เอามา ตรวจตราที่ติดเอกสาร
4. ถ้าตรงกัน → คุณรู้ว่า ผมเป็นคนเซ็นจริง (ไม่มีใครปลอมได้)

Magic = แค่ตรวจ public key ที่ทุกคนเห็น — ยืนยันได้ว่า private key ของผม (ที่ไม่มีใครเห็น) คือคนเซ็น

Hash + Sign — ของจริงเซ็น hash ไม่ได้เซ็นเอกสารทั้งฉบับ#

ในของจริง — ไม่ได้เซ็นเอกสารทั้งฉบับครับ (เพราะช้า + RSA encrypt ข้อมูลใหญ่ไม่ได้). ของจริงทำแบบนี้:

1. Hash เอกสารทั้งฉบับ (ด้วย SHA-256 — EP.22 จะเล่าละเอียด) → ได้ fingerprint สั้นๆ ขนาด 32 bytes
2. เซ็น hash นั้น ด้วย private key → ได้ digital signature
3. ส่ง เอกสาร + signature ไปด้วยกัน
4. ผู้รับ — hash เอกสารใหม่ + decrypt signature ด้วย public key → เทียบ 2 hash ตรงกันไหม

ถ้าตรง = เอกสารไม่ถูกแก้ + เซ็นโดยเจ้าของจริง

Digital Signature ทำอะไรในวงการจริง#

• Code Signing — Windows / macOS / iOS ตรวจว่า software จาก vendor จริงด้วย signature. ถ้า attacker แก้ไฟล์ exe = signature พัง = OS เตือน
• HTTPS certificate — certificate ของเว็บไซต์ถูก sign โดย CA. browser ตรวจ signature → ถ้า valid = trust เว็บไซต์นั้น (รายละเอียดใน EP.23 เรื่อง PKI)
• iMessage — Apple ใช้ ECDSA sign ทุกข้อความ — ตรวจว่ามาจาก iPhone ของคนที่อ้างจริง
• PGP / GPG email signing — เซ็น email + verify ผู้ส่ง
• Software update — Linux distribution (Debian / Ubuntu / Fedora) ใช้ GPG signature ตรวจว่า package มาจาก repo จริง
• Bitcoin / Ethereum transaction — ทุก transaction เซ็นด้วย private key ของ wallet — public network ตรวจ verify ได้
• เอกสาร PDF — Adobe ใช้ digital signature สำหรับเซ็น contract ตามกฎหมาย (พ.ร.บ. ธุรกรรมทางอิเล็กทรอนิกส์ของไทยรองรับ)

3 คุณสมบัติของ Digital Signature ที่บังคับใช้ในกฎหมาย#

Digital Signature ให้ 3 อย่างที่ลายเซ็นบนกระดาษให้ไม่ครบ:

1. Authenticity — ยืนยันได้ว่าใครเซ็น (เจ้าของ private key เท่านั้น)
2. Integrity — ยืนยันได้ว่าเอกสารไม่ถูกแก้หลังเซ็น (เพราะถ้าแก้ = hash เปลี่ยน = signature ไม่ตรง)
3. Non-repudiation — ผู้เซ็นปฏิเสธไม่ได้ว่าตัวเองเซ็น (เพราะ private key อยู่กับเขาคนเดียว — ใครจะเซ็นแทนไม่ได้)

3 คุณสมบัตินี้ทำให้ digital signature มีผลทางกฎหมายเทียบเท่าหรือมากกว่าลายเซ็นบนกระดาษ ในหลายประเทศ รวมถึงไทย (พ.ร.บ. ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544)

มุมผู้บริหาร: Digital signature ในปี 2026 เป็น เทคโนโลยีที่บริษัทไทยใช้ได้น้อยกว่าที่ควร — pattern ของวงการคือ บริษัทยังเซ็น contract บนกระดาษ → scan → email → print → เซ็นต่อ ทั้งที่ Digital Signature ตามกฎหมายไทยใช้ได้แล้ว 25 ปี. ลองทำ exercise ในบริษัทคุณ — กระดาษไหนของบริษัทที่เซ็นมือบ่อยที่สุด? (PO, contract, NDA, HR document). ROI ของ Digital Signature = ลด cost กระดาษ + storage + courier + เวลา approve. เครื่องมือพร้อม — DocuSign, Adobe Sign, ETDA Thailand. ราคาไม่แพง — แค่ตัดสินใจใช้

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — บังคับ Perfect Forward Secrecy ทุก HTTPS ของบริษัท. ตรวจด้วย SSL Labs Test

นี่คือ control ที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. PFS = insurance ระยะยาว ที่ฟรี — แค่ config TLS ให้ถูก. ถ้าวันหนึ่ง server ของบริษัทคุณโดน hack — PFS ป้องกัน traffic ในอดีต ของลูกค้าหลายปีที่ attacker อาจบันทึกไว้

3 step ที่ทำได้ในสัปดาห์นี้:

1. List เว็บไซต์ทั้งหมดของบริษัท — รวม subdomain ทั้งหมด — รวม API endpoint
2. ทดสอบทุก domain ด้วย SSL Labs Test (ฟรีที่ ssllabs.com/ssltest) — ขอ rating A หรือ A+ ทุกตัว
3. บังคับ TLS 1.3 หรือ TLS 1.2 + cipher suite ที่มี ECDHE เท่านั้น — disable TLS 1.0 / 1.1 / cipher ที่ไม่มี PFS

ถ้าทีม IT บอกว่า “ทำไม่ได้เพราะ legacy client” — ขอตัวเลข percentage ของ traffic ที่มาจาก legacy client ก่อน. ในปี 2026 — เกือบ 100% ของ browser + mobile รองรับ TLS 1.3 แล้ว. legacy client ที่ไม่รองรับ = ไม่ใช่ลูกค้า ก็เป็น scanner ของโจร

ข้อสอง — Crypto Agility = ความสามารถในการเปลี่ยน algorithm ที่บริษัทคุณต้องวางแผนวันนี้

Quantum computer จะมา. นั่นไม่ใช่คำถาม “ถ้า” — แต่เป็น “เมื่อไหร่”. 10 ปี? 20 ปี? — ไม่มีใครรู้แน่. แต่ที่แน่คือ บริษัทที่ไม่มี crypto agility = หนี้ technical ที่จะระเบิดวันนึง

คำถามที่ผู้บริหารควรถามทีม dev ในการประชุมถัดไป:

1. ระบบเราใช้ algorithm อะไรบ้าง? (RSA-2048? ECDSA P-256? Curve25519?)
2. ถ้า NIST ประกาศพรุ่งนี้ว่าต้องเปลี่ยน — เราใช้เวลากี่วัน?
3. algorithm ถูก hardcode ในโค้ดที่ไหนบ้าง? — ทุก hardcode = หนี้
4. มี certificate inventory + automation ในการ rotate ไหม?
5. เรารู้ไหมว่า system ไหน “เก่าเกินไป” ที่ upgrade crypto ไม่ได้?

3 ขั้นตอนสำหรับ crypto agility:

1. ขั้นที่ 1 — Inventory — list ทุก algorithm + key + certificate ในบริษัท. ส่วนใหญ่บริษัทไทย ไม่รู้ว่าตัวเองใช้อะไรอยู่
2. ขั้นที่ 2 — Abstraction — refactor code ให้ algorithm อยู่ใน config / library ไม่ใช่ hardcode
3. ขั้นที่ 3 — Automation — automate certificate rotation + key rotation + algorithm migration

บริษัทที่ทำ 3 ขั้นตอนนี้ในปี 2026 = เมื่อ Post-Quantum Crypto กลายเป็นมาตรฐาน — migrate ได้ใน 30 วัน แทน 12 เดือน