
JEP 527: TLS 1.3 แบบ hybrid กันควอนตัมใน JDK 27
ข้อมูลที่เข้ารหัสวันนี้ อาจถูกเก็บไว้ถอดวันหลังเมื่อเครื่องควอนตัมเก่งพอ นี่คือเหตุผลที่คนเรียกภัยแบบ harvest now, decrypt later
JEP 527 ซึ่งถูกส่งมอบในสาย JDK 27 เพิ่ม hybrid key exchange ให้ TLS 1.3 ผ่าน API javax.net.ssl Hybrid คือการผสมอัลกอริทึมต้านควอนตัมกับอัลกอริทึมดั้งเดิม เพื่อให้ยังปลอดภัยถ้าอย่างใดอย่างหนึ่งยังไม่พัง
สิ่งที่ JDK จะเปิดให้โดยค่าเริ่มต้น
JEP ระบุสาม named group แบบ hybrid:
X25519MLKEM768SecP256r1MLKEM768SecP384r1MLKEM1024
ฝั่งไคลเอนต์ TLS 1.3 ของ JDK จะวาง X25519MLKEM768 ไว้หน้าสุดของรายการตามค่าเริ่มต้น ดังนั้นแอปที่ใช้ javax.net.ssl ปกติและไม่ได้ล็อกกลุ่มคีย์เอง จะได้ประโยชน์เมื่อคู่สื่อสารรองรับ โดยไม่ต้องแก้โค้ด
กลุ่ม hybrid อีกสองตัวไม่ได้เปิดเป็นค่าเริ่มต้น แต่เลือกผ่าน jdk.tls.namedGroups หรือ SSLParameters.setNamedGroups ได้ ตามตัวอย่างใน JEP
สิ่งที่ JEP ไม่ทำ
ไม่ครอบคลุม TLS รุ่นอื่นนอก 1.3 และไม่ใส่สคีม ML-KEM แบบ pure (ไม่ hybrid) ในรอบนี้ ผู้เขียนระบุว่า hybrid เป็นที่ต้องการมากกว่าในตอนนี้
Recap
- อัปไป JDK 27 RC/EA แล้วดูการเจรจา TLS กับเซิร์ฟเวอร์จริง
- ถ้าเคยล็อก named groups เอง ให้ทบทวนว่าจะใส่ hybrid หรือยังพึ่งค่าเริ่มต้น
- อย่าคาดว่าทุกเซิร์ฟเวอร์คู่สายรองรับ hybrid ในวันแรก
- อ่าน JEP 527 ทั้งไฟล์ก่อนเปลี่ยนพร็อพเพอร์ตี้ใน production ครับ