ตัวอย่างที่ 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 (หรือชื่อทางวิชาการ Digital Envelope) — pattern ที่ใช้ทุกที่ในวงการ. ลึกเรื่องนี้ section ถัดไปครับ

Digital Envelope / Hybrid Encryption — pattern ที่ทุกระบบใช้#

ก่อนเข้าเรื่อง ลองนึกปัญหาที่เรามีตอนนี้ครับ:

• Symmetric (AES) เร็ว 1,000 เท่า แต่ ส่งกุญแจให้คนอื่นไม่ได้ (chicken-and-egg ของ EP.20)
• Asymmetric (RSA) ส่งกุญแจได้ แต่ ช้า + encrypt data ใหญ่ไม่ได้ (245 bytes/operation สำหรับ RSA-2048)

ดูเหมือนทั้ง 2 ตัวมีจุดแข็ง + จุดอ่อนคนละมุม. คำถาม — ทำไมไม่ใช้ทั้งคู่รวมกันให้ตอบโจทย์ทั้ง 2 ฝั่ง?

นี่คือ insight ที่ทำให้ pattern Digital Envelope เกิดขึ้นครับ

flowchart LR
    A["📄 Data ใหญ่<br/>(500 MB)"] --> B["🔐 AES Encrypt<br/>(ด้วย session key สุ่ม)"]
    K1["🔑 Session Key<br/>(สุ่มใหม่ 256 bits)"] --> B
    K1 --> C["🔒 RSA Encrypt<br/>(ด้วย public key<br/>ของผู้รับ)"]

    B --> E1["📦 Encrypted Data"]
    C --> E2["✉️ Encrypted Key<br/>(Digital Envelope)"]

    E1 --> S["📤 ส่งทั้ง 2 ก้อนไปพร้อมกัน"]
    E2 --> S

    classDef data fill:#1e3a5f,stroke:#4a9eff,color:#fff
    classDef key fill:#5a3a1f,stroke:#a07040,color:#fff
    classDef out fill:#3a4a2a,stroke:#6a8050,color:#fff
    class A,E1 data
    class K1,E2 key
    class B,C,S out

flowchart LR
    E2["✉️ Envelope<br/>(Encrypted Session Key)"] --> D1["🔓 RSA Decrypt<br/>(ด้วย private key<br/>ของผู้รับ)"]
    D1 --> K2["🔑 Session Key<br/>(ได้คืน)"]
    E1["📦 Encrypted Data"] --> D2["🔓 AES Decrypt<br/>(ด้วย session key)"]
    K2 --> D2
    D2 --> A2["📄 Data ใหญ่ (อ่านได้)"]

    classDef data fill:#1e3a5f,stroke:#4a9eff,color:#fff
    classDef key fill:#5a3a1f,stroke:#a07040,color:#fff
    classDef out fill:#3a4a2a,stroke:#6a8050,color:#fff
    class A2,E1 data
    class K2,E2 key
    class D1,D2 out

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 เดือน