OpenSSH การเข้ารหัสหลังควอนตัม

• OpenSSH รองรับ อัลกอริทึมเข้ารหัสหลังควอนตัม เพื่อรับมือกับการโจมตีจากคอมพิวเตอร์ควอนตัม
• ตั้งแต่เวอร์ชัน 9.0 เป็นต้นมา โดยค่าเริ่มต้นใช้ sntrup761x25519-sha512 และตั้งแต่ 10.0 ใช้ mlkem768x25519-sha256 เป็นรูปแบบการเชื่อมต่อเริ่มต้น
• เริ่มตั้งแต่เวอร์ชัน 10.1 หากมีการใช้การแลกเปลี่ยนคีย์ที่ไม่ใช่หลังควอนตัม จะมีการแสดง ข้อความเตือน
• อัลกอริทึมลายเซ็นแบบดั้งเดิมส่วนใหญ่ (เช่น RSA, ECDSA ฯลฯ) จะมีการเพิ่มการรองรับในอนาคต
• เพื่อปกป้องทราฟฟิกเดิมอย่างปลอดภัย จำเป็นต้องใช้ อัลกอริทึมหลังควอนตัม ทั้งฝั่งเซิร์ฟเวอร์และไคลเอนต์

---

การนำเข้าการเข้ารหัสหลังควอนตัมใน OpenSSH

OpenSSH รองรับอัลกอริทึมการแลกเปลี่ยนคีย์หลายตัวที่ยังปลอดภัยต่อการโจมตีด้วยคอมพิวเตอร์ควอนตัม
แนะนำให้ใช้โมเดลอัลกอริทึมเหล่านี้ในทุกการเชื่อมต่อ SSH

ตั้งแต่ OpenSSH 9.0 (ปี 2022) เป็นต้นมา ได้รองรับการแลกเปลี่ยนคีย์หลังควอนตัม (KexAlgorithms) แบบเริ่มต้นผ่าน sntrup761x25519-sha512 และตั้งแต่เวอร์ชัน 9.9 ได้เพิ่ม mlkem768x25519-sha256
mlkem768x25519-sha256 ถูกกำหนดให้เป็น อัลกอริทึมการเข้ารหัสหลัก ตั้งแต่ OpenSSH 10.0

เพื่อกระตุ้นการนำอัลกอริทึมหลังควอนตัมมาใช้ OpenSSH 10.1 เป็นต้นไปจะแสดงข้อความเตือนหากไม่ได้ใช้ การแลกเปลี่ยนคีย์ต้านคิวท์

** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html

ข้อความเตือนนี้จะแสดงตามค่าเริ่มต้น แต่สามารถปิดได้ด้วยตัวเลือก WarnWeakCrypto ของ ssh_config(5)

พื้นหลัง

คอมพิวเตอร์ควอนตัม คืออุปกรณ์ที่คำนวณโดยเข้ารหัสข้อมูลเป็นสถานะควอนตัม
สามารถแก้ปัญหาคณิตศาสตร์เฉพาะบางชนิดได้อย่างรวดเร็ว ซึ่งคอมพิวเตอร์ทั่วไปไม่สามารถทำได้

รากฐานการเข้ารหัสของอัลกอริทึมหลายตัวพึ่งพาปัญหาคณิตศาสตร์ที่คอมพิวเตอร์ควอนตัมสามารถแก้ได้ง่าย
หากมีคอมพิวเตอร์ควอนตัมที่มีประสิทธิภาพมากพอ (ถึงระดับสำคัญเชิงการเข้ารหัส) ปรากฏขึ้น อัลกอริทึมเหล่านี้อาจถูกทำลายได้
โดยเฉพาะอัลกอริทึมที่ใช้กับ การแลกเปลี่ยนคีย์ และ ลายเซ็นดิจิทัล จะได้รับผลกระทบมากที่สุด

แม้ว่าคอมพิวเตอร์ควอนตัมดังกล่าวยังไม่เกิดขึ้นจริงในตอนนี้ แต่ผู้เชี่ยวชาญคาดการณ์ว่าจะปรากฏตัวในอีก 5~20 ปี หรือช่วงกลางทศวรรษ 2030

ความเป็นส่วนตัวของการเชื่อมต่อ SSH พึ่งพาอยู่ที่อัลกอริทึมการแลกเปลี่ยนคีย์
หากผู้โจมตีสามารถทำลายอัลกอริทึมการแลกเปลี่ยนคีย์ได้ จะสามารถถอดรหัสเนื้อหาทั้งหมดของเซสชันได้
นอกจากนี้ แม้ไม่ใช่การโจมตีแบบเรียลไทม์ ผู้โจมตีสามารถเก็บ เซสชันทริฟฟิกเข้ารหัส ไว้ แล้วในอนาคตเมื่อมีคอมพิวเตอร์ควอนตัมสามารถถอดรหัสได้ผ่านการโจมตีแบบ 'store now, decrypt later'

OpenSSH กำลังเสริมความเข้มแข็งในการรองรับการเข้ารหัสหลังควอนตัมเพื่อรับมือกับการโจมตีประเภทนี้

FAQ

Q: ได้รับการแจ้งเตือนว่า ssh มีคำเตือน ควรทำอย่างไร?

• OpenSSH 10.1 ขึ้นไปจะแจ้งเตือนผู้ใช้เมื่อใช้การเข้ารหัสที่ไม่ปลอดภัยแบบ post-quantum
• กรณีนี้หมายถึงเซิร์ฟเวอร์ที่เชื่อมต่อไม่รองรับอัลกอริทึมการแลกเปลี่ยนคีย์แบบหลังควอนตัม (mlkem768x25519-sha256, sntrup761x25519-sha512)
• คำแนะนำที่ดีที่สุดคืออัปเดตเซิร์ฟเวอร์เป็น OpenSSH 9.0 ขึ้นไป (ตัวหลังควรเป็น 9.9 ขึ้นไป) และตรวจสอบว่าใน KexAlgorithms อัลกอริทึมที่เกี่ยวข้องไม่ได้ถูกปิดใช้งาน
• หากไม่สามารถอัปเดตเซิร์ฟเวอร์ได้ หรือยอมรับความเสี่ยงได้ สามารถซ่อนเฉพาะข้อความเตือนด้วยตัวเลือก WarnWeakCrypto ใน ssh_config(5) ได้
• หากจำเป็น แนะนำให้ใช้ค่าตั้งค่าสำหรับโฮสต์ที่เจาะจงดังนี้

  Match host unsafe.example.com
      WarnWeakCrypto no
  

Q: แม้ยังไม่มีคอมพิวเตอร์ควอนตัม ก็ยังต้องเตรียมพร้อมตั้งแต่ตอนนี้หรือ?

• เพราะเป็นเพราะการโจมตีแบบ "store now, decrypt later" ที่กล่าวถึงก่อนหน้านี้
• การจราจรที่ส่งไปในวันนี้อาจมีความเสี่ยงถูกถอดรหัสในอนาคตได้ จึงแนะนำให้เชื่อมต่อแบบ post-quantum-safe ล่วงหน้า

Q: คุณบอกว่าลายเซ็นอัลกอริทึมก็เสี่ยง ทำไมไม่ใช่ปัญหาใหญ่?

• ปัจจุบันอัลกอริทึมลายเซ็นส่วนใหญ่ (RSA, ECDSA ฯลฯ) ก็อาจถูกทำให้ใช้การไม่ได้ด้วยคอมพิวเตอร์ควอนตัมได้
• อย่างไรก็ตาม กรณีนี้ไม่เกิดการเก็บทราฟฟิกเดิมไว้แล้วมาถอดรหัสในภายหลัง
• เรื่องที่ต้องรีบของอัลกอริทึมลายเซ็นคือการเกษียณคีย์ลายเซ็นเดิมเมื่อคอมพิวเตอร์ควอนตัมเข้ามาใกล้ระดับใช้งานได้จริง
• OpenSSH จะรองรับอัลกอริทึมลายเซ็นหลังควอนตัมในอนาคต

Q: ผมคิดว่าคอมพิวเตอร์ควอนตัมคงเกิดเป็นไปไม่ได้ ทำไมสิ่งนี้จึงสำคัญ?

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

Q: อัลกอริทึมหลังควอนตัมของคุณเองอาจยังมีช่องโหว่หรือไม่?

• OpenSSH ก็ก้าวเข้าหาเรื่องนี้อย่างระมัดระวังเช่นเดียวกัน
• แม้เลือกเฉพาะอัลกอริทึมที่ผ่านการรีวิวย้อนหลังอย่างเข้มข้นในหลายปีที่ผ่านมา ก็ยังมีความเป็นไปได้ที่พบวิธีโจมตีใหม่
• เพื่อเตรียมรับสถานการณ์นี้ จึงเลือกใช้เฉพาะอัลกอริทึมที่มีมาร์จิ้นความปลอดภัยกว้าง เพื่อลดความเสี่ยงที่ความปลอดภัยเชิงปฏิบัติจะลดลงหากมันอ่อนกว่าที่คาด
• นอกจากนี้ อัลกอริทึมหลังควอนตัมทั้งหมดของ OpenSSH เป็นแบบ "hybrid" เสียทุกตัว
  • ตัวอย่างเช่น mlkem768x25519-sha256 ผสมผสานอัลกอริทึม ML-KEM (หลังควอนตัม) และอัลกอริทึมคลาสสิก ECDH/x25519
  • ด้วยเหตุนี้ หากอัลกอริทึมหลังควอนตัมถูกทำลายในอนาคต ก็ยังคงรักษาระดับความปลอดภัยอย่างน้อยเทียบเท่าเดิมได้

[GN⁺]

ความคิดเห็นบน Hacker News

• เนื้อหาสำคัญถูกซ่อนอยู่ที่ด้านล่างสุดของหน้า. อัลกอริทึมโพสต์ควอนตัมทั้งหมดที่นำไปใช้กับ OpenSSH นั้นเป็นแบบ "ไฮบริด" โดยใช้การแลกเปลี่ยนคีย์โพสต์ควอนตัม (เช่น ML-KEM) และวิธีเดิม (x25519) ไปพร้อมกัน. การใช้สองอัลกอริทึมร่วมกันหมายความว่าหากในอนาคตอัลกอริทึมโพสต์ควอนตัมล่มสลายทั้งหมด เราก็ยังคงความปลอดภัยระดับเดียวกับระบบเดิมได้. ใจความสำคัญคือแนวทางไฮบริดช่วยให้ไม่สูญเสียความปลอดภัยเมื่อเทียบกับเดิม

  • ข้อดีของโหมดไฮบริดคือ หากอัลกอริทึมทางหนึ่งถูกเจาะ อีกด้านหนึ่งยังคงให้ความทนทานได้. แต่ในทางกลับกัน ความเสี่ยงจากบั๊กในการนำไปใช้และการรั่วไหลของช่องทางด้านข้างก็สูงขึ้นเกินเท่าตัว. ในความเป็นจริง ภัยคุกคามจากคอมพิวเตอร์ควอนตัมยังไม่เกิดขึ้นจริง แต่บั๊กและช่องโหว่เหล่านั้นเป็นปัญหาในโลกปัจจุบันทันที. อย่างไรก็ตามใน 10 ปีที่ผ่านมามีการวิจัยและการตรวจสอบความปลอดภัยอย่างมหาศาล จึงเห็นได้ว่าการแลกเปลี่ยนผลตอบแทนนี้ยังพอรับได้

  • อุตสาหกรรมส่วนใหญ่กำลังขยับไปสู่โครงสร้าง PQC-คลาสสิกแบบไฮบริด. ก่อนที่คอมพิวเตอร์ควอนตัมจะมาถึงระดับที่สามารถเจาะ RSA, ECC และ DH แบบเดิมได้จริง วิธีที่ระมัดระวังที่สุดในตอนนี้น่าจะคือการใช้กุญแจสองดอกแบบขนานควบคู่กัน. แต่อีกด้านหนึ่ง คำแนะนำของอัลกอริทึม CNSA 2.0 โดย NSA (ลิงก์) ระบุว่าใช้เฉพาะตระกูลโพสต์ควอนตัมเท่านั้น และใน FAQ อย่างเป็นทางการระบุว่าไม่จำเป็นต้องมีโหมดไฮบริด

• เมื่อพิจารณาบทความที่มีแนวโน้มเยาะเย้ยและน่าสนใจที่ตีพิมพ์ล่าสุด (ลิงก์) ก็อดถามไม่ได้ว่าปัจจุบันการนำคริปต์โพสต์ควอนตัมเข้ามาอย่างเร่งด่วนจำเป็นจริงหรือไม่. จากที่ทราบ ข้อมูลคีย์โพสต์ควอนตัมมีขนาดใหญ่กว่าระบบเดิมมาก ทำให้ปริมาณทราฟฟิกเครือข่ายและการใช้ CPU เพิ่มขึ้นอย่างมาก

  • เนื้อหานี้พูดถึงการใช้ PQC เฉพาะในขั้นตอนแลกเปลี่ยนคีย์ของการเชื่อมต่อ SSH เท่านั้น ดังนั้น overhead จึงค่อนข้างน้อยมาก. และอย่างที่มีใน FAQ คำถาม "แล้วทำไมต้องเตรียมตัวก่อนหน้านี้ ทั้งที่คอมพิวเตอร์ควอนตัมยังไม่มี" ตอบได้ว่าคือเพราะทราฟฟิกที่ส่งวันนี้อาจถูกถอดรหัสในอนาคตได้ (การโจมตีแบบ “store now, decrypt later”). มีคนบางคนเชื่อว่าคอมพิวเตอร์ควอนตัมไม่อาจเกิดขึ้นได้ แต่การถ่วงช้าหลักไม่ใช่ฟิสิกส์ เป็นปัญหาด้านวิศวกรรม. ถ้าคอมพิวเตอร์ควอนตัมเกิดขึ้นจริง มันหมายถึงสามารถปกป้องข้อมูลผู้ใช้จำนวนมหาศาลได้. บทความนี้อ่านเล่นสักครั้งก็สนุก แต่ไม่ควรรับเฉพาะความเย้ยหยันล้วนๆ

  • บทความนี้อาจอ่านแล้วขำได้ แต่ไม่น่าจะเป็นเพียงเรื่องให้ล้อเล่นเท่านั้น แท้จริงมีความก้าวหน้าที่มีนัยสำคัญเกิดขึ้นจริง ผมแนะนำงานนำเสนอของ Sam Jacques ใน PQCrypto 2025 (ลิงก์). ตลอด 10 ปีที่ผ่านมา ต้นทุนในการประกอบการแยกตัวประกอบบนคอมพิวเตอร์ควอนตัมลดลงราว 1000 เท่า และอัตราความผิดพลาดด้านฮาร์ดแวร์ก็ลดลงอย่างมาก (ลิงก์ 1, ลิงก์ 2, ลิงก์ 3, ลิงก์ 4). หากอยากติดตามพัฒนาการของคอมพิวเตอร์ควอนตัม ให้จับตามองความก้าวหน้าเชิงความทนทานทีละขั้น. แหล่งปัญหาคือ noise และเมื่อประเด็นคุณภาพด้านสองฝั่งได้รับการแก้ไขแล้ว คาดว่าการพัฒนาที่แท้จริงจะตามมาเร็ว

  • บทความนั้นดูเหมือนจะเป็นเรื่องตลกเกินไป แต่นำมาคิดเชิงวิจารณ์จริงจังก็คล้ายกับการบ่นเมื่อปี 1951 ว่าไตรสโซลิดไม่สามารถคำนวณค่าพายได้เลย. การมีหรือไม่จำเป็นของ PQC ก็ขึ้นอยู่กับ 2 คำถาม: 1) คุณเชื่อว่าจะไม่มีกำเนิดคอมพิวเตอร์ควอนตัมในชีวิตคุณหรือไม่ 2) คุณให้คุณค่ากับความสำคัญของข้อมูลที่ฝากไว้มากแค่ไหน หากไม่ใส่ใจทั้งสองข้อ PQC อาจเป็นการสูญเปล่าของเวลา แต่ในฐานะคนที่ดูแลระบบเข้ารหัส ผมไม่เชื่อว่าสามารถมองข้ามคุณค่าข้อมูลผู้ใช้ได้

  • การอภิปรายส่วนใหญ่ในตอนนี้อยู่กับเรื่องการแลกเปลี่ยนคีย์. การแลกเปลี่ยนคีย์เกิดไม่บ่อยและโดยทั่วไป overhead ไม่ได้เป็นภาระ. สรุปประเด็นหลักคือ: 1) อัลกอริทึม PQ (ลายเซ็น, การแลกเปลี่ยนคีย์) มีขนาดคีย์ใหญ่มากขึ้นแต่ความเร็วในการคำนวณเร็วขึ้นหรือตรงกัน. 2) โปรโตคอลส่วนใหญ่เช่น TLS และ SSH จะทำ key exchange เฉพาะตอนเชื่อมต่อครั้งแรก จึงไม่ค่อยมีปัญหากับคีย์ขนาดใหญ่มากนัก แต่ประเด็นเรื่องความเข้ากันได้เช่นการเกิน TCP MTU ยังคงเป็นไปได้. ในโปรโตคอลที่ทำการแลกเปลี่ยนคีย์บ่อยมากอย่าง Signal และ MLS จึงมีการใช้ PQ บ้างเฉพาะบางครั้งเท่านั้น (อ้างอิง). 3) ในกรณี TLS ประเด็นที่ใหญ่ขึ้นกลับเป็นขนาดข้อความลายเซ็น เพราะใน chain ใบรับรองมีลายเซ็นจำนวนมาก จึงมีความกังวลมากขึ้นว่าการนำ PQ-signature ไปใช้กับ TLS จะใช้งานได้จริงมากน้อยเพียงใด (อ้างอิง)

  • นอกเหนือจากข้อมูลสาธารณะ ความจริงที่หน่วยข่าวกรองของเราแนะนำให้ใช้ PQ ในระบบที่ต้องการความลับเกิน 20 ปีถือเป็นปัจจัยความน่าเชื่อถือ. เอกสารอ้างอิง: ในปี 2014 หน่วยข่าวกรองของเนเธอร์แลนด์ระบุช่วง 2030~2040 และปี 2021 ระบุว่าความเป็นไปได้ก่อนปี 2030 แม้ต่ำแต่ไม่ควรเพิกเฉย. ปี 2025 องค์กร 18 ประเทศออกแถลงการณ์ร่วมว่าให้เตรียมรับมือการโจมตีแบบ store now, decrypt later จนถึงปี 2030 (เอกสาร 1, เอกสาร 2, แถลงการณ์ร่วม)

• แอป Secretive สำหรับ macOS เก็บ SSH key ใน Secure Enclave. เนื่องจากอัลกอริทึมที่รองรับใช้งานจึงใช้ ecdsa-sha2-nistp256 และดูเหมือนว่า Secure Enclave อาจยังไม่รองรับอัลกอริทึม PQ. จึงสงสัยว่าถ้ารวมเป็นแบบไฮบริดเช่น mlkem768×ecdsa-sha2-nistp256 ให้ SE ดำเนินการเฉพาะส่วน ECDSA ได้หรือไม่ (Secretive GitHub)

  • ที่นี่หมายถึงประกาศเกี่ยวกับการแลกเปลี่ยนคีย์ (หรือเรียกว่า KEX: Key Exchange) ไม่เกี่ยวข้องโดยตรงกับคีย์ SSH เอง. ในตัวเลือกของ SSH, ecdsa-sha2-nistp256 ไม่อยู่ใน KexAlgorithms โดยแท้จริง และทางเลือกแทนคือ ecdh-sha2-nistp256 (อ้างอิง 1, อ้างอิง 2)

• ผมคิดว่าควรเพิ่มรายการเช็กอัลกอริทึมเชิงทฤษฎี (PQC ไฮบริด) ในเครื่องมือ ssh-audit (ลิงก์). ดูเหมือนว่าถึงแม้จะล็อกเฉพาะอัลกอริทึมเดียวไว้ ก็ยังคงได้คะแนน "A" อยู่เช่นเดิม. ตอนนี้ใช้เฉพาะ ChaCha

• สงสัยว่ามีอัลกอริทึมไฮบริด PQC สำหรับ OpenSSH ที่สอดคล้องกับ FIPS 140-3 หรือไม่

  • ใบรับรอง FIPS จะครอบคลุมโมดูลเข้ารหัสทั้งหมด (รวมฮาร์ดแวร์และซอฟต์แวร์). ดังนั้นคำว่า "OpenSSH ที่ผ่าน FIPS" จึงแทบเป็นคำที่ใช้ผิด แน่นอนว่าต้องได้รับการรับรองในสภาพแวดล้อม OS และฮาร์ดแวร์เฉพาะที่ใส่ OpenSSH ลงไป. FIPS มีข้อกำหนดให้ใช้บางอัลกอริทึม และ ML-KEM อยู่ในรายการที่ NIST รับรอง. จากที่ผมเข้าใจ NIST ก็ยอมรับ KEM แบบไฮบริดด้วย ดังนั้นผมจึงเชื่อว่าตัวอัลกอริทึมที่ OpenSSH รองรับอย่าง mlkem768x25519-sha256 ก็สามารถขอรับรองได้ แต่ผมไม่ใช่นักตรวจสอบ FIPS

• การเตรียมการล่วงหน้าเป็นแนวทางที่สมเหตุสมผล โดยเฉพาะเมื่อการหมุนคีย์เป็นงานที่ค่อนข้างเล็ก ผมกังวลว่าอันไหนแน่นกว่า และคงเป็นว่า 512 ดูจะแข็งแกร่งกว่าหรือไม่

  • อัลกอริทึมสองตัวนี้ต่างกันโดยสิ้นเชิง. mlkem768x25519-sha256 เป็นโหมดไฮบริดที่ผสมการแลกเปลี่ยนคีย์ ML-KEM PQ เข้ากับ ECDH/x25519 แบบดั้งเดิม. ด้วยวิธีนี้ หากตัวใดตัวหนึ่งเสียหาย เรายังคงได้ความปลอดภัยแบบเดิม. เวอร์ชัน 256 (mlkem768) ปรากฏจริงหลังเวอร์ชัน 512 (sntrup761); OpenSSH รองรับ sntrup761x25519-sha512 ตั้งแต่ 9.0 และ mlkem768x25519-sha256 ตั้งแต่ 9.9

  • ขนาด 256 หรือ 512 ไม่ใช่เรื่องที่ต้องกังวลตอนนี้. พลังงานยังไม่พอสำหรับการสุ่มสำรวจพื้นที่ 128 บิตครบทุกค่าครับ และคอมพิวเตอร์ลักษณะนั้นก็ยังไม่อยู่. ยังไม่ถึงเวลากังวล

  • ในปัจจุบัน ML-KEM เป็นค่าเริ่มต้นที่สมเหตุสมผลที่สุด เพราะมาตรฐานอุตสาหกรรมกำลังมุ่งไปทางนี้

• ผู้เขียนกำลังคิดว่าจะย้ายแอปไมโครบล็อก/แชตบนเทอร์มินัลของตัวเองไปโหมดความปลอดภัยโพสต์ควอนตัมหรือไม่ โดยได้ดูสัมภาษณ์ Paul Durov หลายรอบและฟังสิ่งที่เขาเจอจนยิ่งคิดมากขึ้น

  • อยากรู้ว่าเขาเจออะไรเป็นกรณีเฉพาะ และอีกอย่างว่า ทำไมในบล็อกถึงต้องใช้ SSH

• สงสัยว่าตัวไหนดีกว่าระหว่าง sntrup761x25519-sha512 กับ mlkem768x25519-sha256

  • ML-KEM768 ให้ประสิทธิภาพและคีย์ที่เล็กกว่า ขณะที่ SNTRUP761 มีสมมติฐานความปลอดภัยที่แข็งแกร่งกว่า และความทนทานต่อการโจมตีเชิงวิเคราะห์มากกว่า

  • NTRU Prime (sntrup) เข้ารวมมาด้วยเหตุผลด้านประวัติศาสตร์ (ตอนนั้นยังไม่มี mlkem). ใช้อันใดก็ได้สักอัน แต่ sntrup ตอนนี้ดูคล้ายเป็นค่าเริ่มต้นชั่วคราวเหมือนสมัยที่ GPG ใช้ CAST เป็นค่าเริ่มต้น

• อยากรู้ว่าเมื่อไรจะมีการให้บริการใบรับรอง PQ (สำหรับการรับรองโฮสต์/ผู้ใช้)

  • เรื่องนี้มีการพูดไว้ในหน้านั้นแล้ว

• การออกแรงก้าวหน้าไปก่อนเป็นเรื่องดี ในโลกที่มีทางเลือกที่ปลอดภัยกว่าปรากฏขึ้นในอนาคต หากไม่แย่ลงกว่าสถานการณ์ปัจจุบัน ความพยายามเช่นนี้ก็ยังมีความหมาย

  • หากคุณเข้าถึงเซิร์ฟเวอร์ผ่านเครือข่ายที่คุณไม่ควบคุมได้ 100% ก็ต้องสมมติว่าทราฟฟิกจะถูกเก็บไว้ที่ใดที่หนึ่งเสมอ ในที่สุดเมื่อเข้าสู่ยุคโพสต์ควอนตัม ทราฟฟิกนั้นอาจถูกถอดรหัสได้ และว่าสิ่งนี้เป็นประเด็นที่ต้องกังวลจริงหรือไม่ ขึ้นกับสถานการณ์ของแต่ละผู้ใช้