คำถามที่ได้ยินบ่อยที่สุดเรื่องควอนตัมคือ “แล้วมันจะมาเมื่อไร” · แต่คำถามที่ใช้วางแผนได้จริง คือ “ข้อมูลของเราต้องเป็นความลับไปอีกกี่ปี” เพราะภัยที่เกิดขึ้นแล้ววันนี้ ไม่ใช่เครื่องควอนตัม แต่คือการที่ผู้โจมตีดักเก็บข้อมูลที่เข้ารหัสไว้ก่อน แล้วรอถอดเมื่อเครื่องพร้อม · บทความนี้ไม่ใช่บทวิเคราะห์เทคโนโลยีควอนตัม แต่เป็นชุดเครื่องมือและมาตรฐานที่คุณเอาไปสแกนและประเมินองค์กรตัวเองได้ตั้งแต่วันนี้

52% ของทราฟฟิกผู้ใช้จริงผ่าน Cloudflare ใช้การแลกกุญแจแบบ ต้านควอนตัมแล้ว1
2030 · 2035 ปีที่ NIST เสนอให้เลิกใช้ และห้ามใช้ RSA-2048 / ECC-2563
1 ม.ค. 2027 เส้นตายที่ระบบความมั่นคงสหรัฐฯ ต้องจัดซื้อของที่ รองรับ PQC4
2569–2578 ช่วงโรดแมป 10 ปีของร่างกรอบความมั่นคงควอนตัมไทย5

01ภัยไม่ใช่ควอนตัม แต่คือการเก็บไว้ก่อน

กลยุทธ์ที่เรียกว่า Harvest Now, Decrypt Later (HNDL) คือการที่ผู้โจมตี ดักและเก็บทราฟฟิกที่เข้ารหัสไว้ตั้งแต่วันนี้ โดยยังถอดไม่ได้ แล้วรอจนกว่าจะมี คอมพิวเตอร์ควอนตัมที่แรงพอ — ที่วงการเรียกว่า CRQC (Cryptographically Relevant Quantum Computer) · หน่วยงาน CISA, NSA และ NIST ออกเอกสารร่วมกันเตือนเรื่องนี้และแนะให้ทุกองค์กรเริ่มทำโรดแมปความพร้อม โดยไม่ต้องรอให้เครื่องเกิดขึ้นจริง2

ผลที่ตามมาคือ ข้อมูลที่ต้องเป็นความลับยาวนานเสี่ยงที่สุด — เวชระเบียน สัญญาระยะยาว ข้อมูลลูกค้า ความลับทางการค้า กุญแจที่ฝังในอุปกรณ์ ที่จะใช้ไปอีกสิบปี · ส่วนข้อมูลที่หมดอายุเร็วอย่างรหัส OTP แทบไม่ได้รับผลกระทบจาก HNDL การจัดลำดับความสำคัญจึงต้องดูที่ อายุของความลับ ไม่ใช่ขนาดของระบบ

สำหรับกรอบเวลาของ CRQC เอง · ปัจจุบัน ยังไม่มีเครื่องที่ทำได้จริง และการประเมินยังกระจายตัวกว้าง · รายงานของ Global Risk Institute ให้ค่าประมาณ ราว 28–49% ที่จะมีเครื่องระดับนั้นภายในสิบปี ซึ่งเป็นตัวเลขสูงที่สุด เท่าที่รายงานฉบับนี้เคยให้มา6

02วัดความเร่งด่วนด้วยสูตรของ Mosca

เครื่องมือวางแผนที่ใช้กันเป็นมาตรฐานคือ Mosca’s Theorem ซึ่งเปลี่ยนคำถามที่ตอบไม่ได้ (“ควอนตัมมาเมื่อไร”) ให้เป็นการเทียบตัวเลขสามตัว ที่องค์กรประเมินเองได้6

สูตรที่ใช้ตัดสินใจได้ใน 10 นาที
ถ้า X + Y > Z แปลว่าคุณช้าไปแล้ว

X = ข้อมูลของคุณต้องเป็นความลับอีกกี่ปี · Y = ใช้เวลากี่ปีในการย้ายระบบทั้งหมด (องค์กรทั่วไปมักอยู่ที่ 3–7 ปี) · Z = อีกกี่ปีกว่าจะมี CRQC

ตัวอย่าง: ถ้าข้อมูลต้องลับ 10 ปี (X=10) และประเมินว่าย้ายระบบเสร็จใน 5 ปี (Y=5) รวมเป็น 15 ปี · ขณะที่ค่ากลางของ Z อยู่ราวปี 2030–2035 หรือ 4–9 ปีจากนี้ · ผลคือคุณควรเริ่มไปแล้ว — ไม่ใช่เพราะควอนตัมใกล้มา แต่เพราะข้อมูลของคุณอายุยาว

03สแกนจากข้างนอก · ทำได้ในห้านาทีแรก

จุดเริ่มที่ง่ายที่สุดคือดูว่าเว็บและ API ของคุณ ต่อรองการแลกกุญแจแบบต้านควอนตัมได้แล้วหรือยัง · มาตรฐานที่ใช้กันจริงบนอินเทอร์เน็ตตอนนี้คือแบบผสม (hybrid) ชื่อ X25519MLKEM768 ซึ่งจับคู่ X25519 แบบเดิมเข้ากับ ML-KEM-768 ตาม FIPS 203 — ออกแบบให้ปลอดภัยแม้ตัวใดตัวหนึ่งถูกเจาะ · Chrome, Edge และ Firefox เปิดใช้เป็นค่าเริ่มต้นแล้ว7

ถ้ามี OpenSSL 3.5 ขึ้นไป (เวอร์ชันแรกที่รองรับ ML-KEM ในตัว) ตรวจได้ด้วยคำสั่งเดียว8

# ถามเซิร์ฟเวอร์ตรง ๆ ว่ารับ hybrid PQ key exchange ไหม openssl s_client -groups X25519MLKEM768 \ -connect example.com:443 </dev/null 2>/dev/null \ | grep "Negotiated TLS1.3 group" # ผลที่ต้องการเห็น: Negotiated TLS1.3 group: X25519MLKEM768 # ถ้าได้ผลเป็น x25519 หรือ secp256r1 เฉย ๆ = ยังไม่พร้อม

อยากได้ภาพรวมทั้งเว็บรวมถึง cipher, ใบรับรอง และกลุ่มการแลกกุญแจในครั้งเดียว ใช้ testssl.sh ซึ่งเป็นสคริปต์โอเพนซอร์สรันได้บนเครื่องตัวเอง ไม่ต้องส่งข้อมูลออกไปที่บริการภายนอก และเวอร์ชันปัจจุบันรายงานกลุ่ม PQ แบบผสมแล้ว9

# สแกนเต็มรูปแบบ · รันบนเครื่องเรา ไม่ส่งข้อมูลออกนอก ./testssl.sh --full example.com

ส่วนภาพระดับประเทศและอุตสาหกรรม · Cloudflare Radar เปิดหน้าสถิติ การใช้การเข้ารหัสต้านควอนตัมแบบสาธารณะ ใช้เทียบได้ว่าองค์กรคุณตามหรือนำค่าเฉลี่ย10 · ตัวเลขล่าสุดคือทราฟฟิกผู้ใช้จริงเกินครึ่งได้รับการปกป้องแล้ว ขณะที่ฝั่ง origin server ยังอยู่ราว 10% เท่านั้น เพิ่มจากไม่ถึง 1% เมื่อต้นปี 20251 — ช่องว่างตรงนี้คือการบ้านของฝั่งองค์กร ไม่ใช่ของเบราว์เซอร์

อ่านผลให้ถูก

การที่เบราว์เซอร์ขึ้นแม่กุญแจ ไม่ได้แปลว่าปลอดภัยจากควอนตัม · และการเปิด hybrid TLS ได้ก็ ยังไม่ใช่การย้ายไป PQC — มันแก้เฉพาะข้อมูลที่วิ่งบนสาย (data in transit) เท่านั้น ยังไม่แตะลายเซ็นดิจิทัล ใบรับรอง กุญแจที่เก็บไว้ หรือข้อมูลที่เข้ารหัสไว้ในฐานข้อมูล ซึ่งเป็นงานก้อนใหญ่กว่ามาก

04ทำ CBOM · รู้ว่ารหัสอยู่ตรงไหนบ้าง

งานที่กินเวลาที่สุดของการย้ายไป PQC ไม่ใช่การเปลี่ยนอัลกอริทึม แต่คือ การหาให้เจอว่าตอนนี้ใช้อะไรอยู่ตรงไหน · เอกสาร NIST SP 1800-38B ของศูนย์ NCCoE ถึงกับแยกเรื่องนี้ออกมาเป็นเล่มต่างหากในชื่อ Cryptographic Discovery พร้อมแผนทดสอบเครื่องมือค้นหา11

รูปแบบมาตรฐานสำหรับบันทึกผลคือ CBOM (Cryptography Bill of Materials) ซึ่งถูกผนวกเข้าสเปก CycloneDX 1.6 แล้ว — คิดง่าย ๆ ว่าเป็น SBOM แต่เก็บรายการอัลกอริทึม ความยาวกุญแจ โปรโตคอล ใบรับรอง และความสัมพันธ์ ว่าส่วนไหนของระบบเรียกใช้อะไร12

เครื่องมือโอเพนซอร์สที่ใช้ได้เลย

ข้อควรรู้: เครื่องมือพวกนี้ไม่ได้เห็นทุกอย่าง · รหัสที่ฝังใน firmware อุปกรณ์เครือข่าย HSM หรือระบบของผู้ให้บริการภายนอก ต้องใช้วิธีถามและตรวจสัญญาเอา — ซึ่งนำไปสู่ข้อถัดไป

05มาตรฐานที่ใช้อ้างอิงกับผู้บริหารได้

เวลาต้องของบประมาณหรือตอบผู้ตรวจสอบ การชี้ไปที่เอกสารที่มีสถานะชัดเจนช่วยได้มาก · ชุดที่ควรรู้จักมีดังนี้

06ไทย · Quantum-Ready 2030

ฝั่งไทยมีทิศทางระดับชาติแล้ว · สกมช. ผลักดันนโยบาย “Quantum-Ready 2030” เพื่อเตรียมประเทศรับยุคควอนตัม โดยวางเป็น สี่เสาหลัก ได้แก่ การสำรวจและเปลี่ยนผ่านระบบรหัส · การเตรียมโครงสร้างพื้นฐาน · การพัฒนาบุคลากร · และการวางธรรมาภิบาลกับมาตรฐาน16

ควบคู่กันคือ ร่างกรอบความมั่นคงปลอดภัยควอนตัม ที่วางโรดแมป 10 ปีช่วง พ.ศ. 2569–2578 · จุดที่น่าสนใจเชิงนโยบายคือไทยเลือกแนวทาง ใช้ PQC เป็นหลัก ซึ่งเป็นการปรับซอฟต์แวร์และทยอยเปลี่ยนผ่านได้ โดยไม่ผูกกับการลงทุนโครงสร้าง QKD5 — สอดคล้องกับทิศทางสากล

สิ่งที่ควรระวังเวลาถูกเสนอขาย

ยังไม่มี CRQC ในโลกวันนี้ · ใครก็ตามที่รับประกันว่า “ป้องกันควอนตัมได้ 100%” หรือบอกว่าต้องซื้อ QKD เท่านั้นถึงจะรอด ควรถูกตั้งคำถาม · คำถามที่ควรถามผู้ขายคือ “รองรับ FIPS 203 และ 204 เมื่อไร และออก CBOM ให้เราได้ไหม” ไม่ใช่ “มีแผนไหม”

07เป้าหมายจริงคือเปลี่ยนอัลกอริทึมได้

สิ่งที่ควรตั้งเป็นเป้าระยะยาวไม่ใช่ “ย้ายไป ML-KEM ให้เสร็จ” แต่คือ crypto agility — ความสามารถในการเปลี่ยนอัลกอริทึมในโปรโตคอล แอปพลิเคชัน ซอฟต์แวร์และฮาร์ดแวร์ ได้โดยยังรักษาความปลอดภัยและการทำงานต่อเนื่องไว้ ซึ่ง NIST ออกเอกสารเฉพาะเรื่องนี้เมื่อธันวาคม 202515

เหตุผลตรงไปตรงมา · PQC รอบนี้ไม่ใช่ครั้งสุดท้ายที่เราต้องเปลี่ยนรหัส · องค์กรที่เจ็บที่สุดในรอบนี้คือพวกที่ ฝังชื่ออัลกอริทึมไว้ในโค้ดทุกซอกทุกมุม จนแก้ทีต้องรื้อทั้งระบบ · สิ่งที่ควรทำระหว่างย้ายคือแยกงานรหัสออกเป็นชั้นเดียว ทำการหมุนกุญแจและใบรับรองให้เป็นงานอัตโนมัติ และเลิกผูกตรรกะธุรกิจกับอัลกอริทึมเฉพาะตัว

08เช็กลิสต์เริ่มสัปดาห์นี้

  1. รันคำสั่ง openssl s_client -groups X25519MLKEM768 กับโดเมนหลักขององค์กร · จดผลไว้เป็น baseline
  2. คำนวณ X + Y + Z ตามสูตร Mosca กับข้อมูลที่อายุยาวที่สุดที่คุณถือครอง
  3. ตั้ง sonar-cryptography หรือ CBOMkit สแกนโค้ดหลักหนึ่งระบบ เพื่อดูว่า CBOM ออกมาหน้าตาอย่างไร
  4. ทำบัญชีระบบที่เก็บข้อมูลอายุเกิน 5 ปี แล้วจัดลำดับตามอายุความลับ ไม่ใช่ตามขนาดระบบ
  5. เพิ่มข้อกำหนด PQC ลงในแบบฟอร์มจัดซื้อและสัญญาฉบับถัดไป (อ้าง FIPS 203/204 และขอ CBOM)
  6. เปิด hybrid TLS ที่ CDN หรือ load balancer ถ้ายังไม่ได้เปิด — เป็นของที่ได้มาแทบฟรี
  7. ใส่หัวข้อ “ความพร้อมด้านควอนตัม” ลงในรายงานความเสี่ยงต่อผู้บริหารรอบหน้า

การย้ายไป PQC เป็นงานหลายปี และไม่มีองค์กรไหนทำเสร็จในไตรมาสเดียว · แต่สิ่งที่ทำให้ต่างกันไม่ใช่ว่าใครย้ายเสร็จก่อน หากคือ ใครรู้ก่อนว่าตัวเองมีอะไรอยู่บ้าง · การสแกนครั้งแรกใช้เวลาไม่ถึงชั่วโมง และนั่นคือระยะห่างระหว่างองค์กรที่มีแผน กับองค์กรที่ยังเดาอยู่

แหล่งอ้างอิง
  1. Cloudflare · ทราฟฟิกผู้ใช้จริงที่ใช้การแลกกุญแจต้านควอนตัมเพิ่มจาก 29% เป็น 52% ในปี 2025 · ฝั่ง origin ราว 10% blog.cloudflare.com · 2025–2026
  2. CISA · NSA · NIST — Quantum-Readiness: Migration to Post-Quantum Cryptography (joint factsheet) cisa.gov
  3. NIST IR 8547 (Initial Public Draft) · Transition to Post-Quantum Cryptography Standards — เสนอเลิกใช้ 2030 ห้ามใช้ 2035 nvlpubs.nist.gov · csrc.nist.gov
  4. NSA · CNSA 2.0 Algorithms — การจัดซื้อระบบความมั่นคงใหม่ต้องรองรับตั้งแต่ 1 ม.ค. 2027 media.defense.gov · qusecure.com
  5. ร่างกรอบความมั่นคงปลอดภัยควอนตัมของไทย · โรดแมป 10 ปี พ.ศ. 2569–2578 · เลือกแนวทาง PQC ไม่ผูกกับ QKD bangkokbiznews.com · posttoday.com · 2026
  6. ค่าประมาณช่วงเวลาการมาถึงของ CRQC และการใช้สูตร Mosca จัดลำดับความเสี่ยง (อ้างรายงาน Global Risk Institute) encryptionconsulting.com · 2026
  7. X25519MLKEM768 · hybrid key exchange สำหรับ TLS 1.3 และการรองรับในเบราว์เซอร์ inside.java · goodtls.com · 2026
  8. OpenSSL 3.5 · รองรับ ML-KEM และ ML-DSA ในตัว พร้อมวิธีตรวจด้วย s_client cryptomathic.com
  9. testssl.sh · รายงานกลุ่มการแลกกุญแจที่ต่อรองได้ รวมกลุ่ม PQ แบบผสม github.com/testssl
  10. Cloudflare Radar · หน้าสถิติการใช้การเข้ารหัสต้านควอนตัมทั่วโลก radar.cloudflare.com
  11. NIST NCCoE · SP 1800-38 Migration to Post-Quantum Cryptography · เล่ม B ว่าด้วย Cryptographic Discovery nccoe.nist.gov · practice guide
  12. CycloneDX · Cryptography Bill of Materials (CBOM) ผนวกเข้าสเปก 1.6 · และ Tool Center cyclonedx.org · tool center
  13. sonar-cryptography · SonarQube plugin สแกนโค้ดออก CBOM · Java และ Python github.com/cbomkit · research.ibm.com
  14. CBOMkit ภายใต้ Post-Quantum Cryptography Alliance · สถาปัตยกรรมและเครื่องมือสแกน container pqca.org
  15. NIST CSWP 39 · Considerations for Achieving Crypto Agility (ธ.ค. 2025) nvlpubs.nist.gov · nist.gov
  16. สกมช. · นโยบาย Quantum-Ready 2030 และสี่เสาหลักการเตรียมประเทศรับยุคควอนตัม dailynews.co.th · brickinfotv.com · 2026