Score:1

อัลกอริทึมและโปรโตคอลแบบคลาสสิกเทียบกับควอนตัมปลอดภัย / แนวทางแอปพลิเคชัน

ธง us
Moo

มีการสำรวจข้อเสนอต่างๆ สำหรับใบรับรอง X509 V3 ในโลกของ Post Quantum Cryptography (PQC)

ปัจจุบัน สิ่งเหล่านี้รวมถึงเพียงการมีใบรับรองสำหรับคลาสสิกและ PQ การมีใบรับรองแบบผสมสำหรับคลาสสิกและ PQ โดยใช้ส่วนขยาย X509 หรือใบรับรองแบบผสมที่เชื่อมลายเซ็นจำนวนมากเข้าด้วยกันเป็นหยดเดียวตามต้องการ ถ้าฉันเข้าใจถูกต้อง สองวิธีแรกคือ an หรือ function นั่นคือคุณใช้ลายเซ็นแบบคลาสสิกหรือแบบหลังควอนตัมเท่านั้น วิธีการผสมสามารถใช้ลายเซ็นทั้งหมด ดังนั้นผู้ใช้จะต้องตรวจสอบลายเซ็นทั้งหมดที่ใช้ในหยด

ความเข้าใจนี้ถูกต้องหรือไม่?

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

อุตสาหกรรมพิจารณา TLS อย่างไร มี TLS แบบคลาสสิกและ PQC TLS หรือไม่ มีโปรโตคอลเพียงสองรูปแบบซึ่งดูเหมือนว่าจะละเมิดความคล่องตัวของการเข้ารหัสลับหรือไม่? หากมีสองสิ่งที่จำเป็นในการสลับระหว่างพวกเขาในการสร้างอินสแตนซ์จริง

อีกวิธีหนึ่งคือการมี TLS แบบไฮบริดที่อนุญาตให้เลือกอัลกอริทึมแบบคลาสสิกหรือแบบ PQC ในการเจรจาต่อรอง อย่างไรก็ตาม ตัวแปรดังกล่าวต้องใช้เวลากี่ปีในการสร้างโดยร่างมาตรฐาน เนื่องจากสิ่งนี้จะเพิ่มความซับซ้อนอย่างมาก แต่นั่นอาจเป็นประเด็นโปรดทราบว่าฉันทราบเกี่ยวกับ Open Quantum Safe (https://openquantumsafe.org/) โครงการ แต่ดูเหมือนว่าทั้งหมดจะสร้างตัวแปร PQ เท่านั้น นอกจากนี้ ในบางจุด คุณจะเลิกใช้อัลกอริทึมแบบคลาสสิกและสนับสนุนเฉพาะอัลกอริทึม PQ เท่านั้น การเปลี่ยนแปลงดังกล่าวจะเกิดขึ้นได้อย่างไร?

สามารถถามคำถามประเภทเดียวกันเกี่ยวกับ SSH, OpenSSL, gnu utils และโปรโตคอลหรือแอปพลิเคชันอื่นๆ ที่ใช้อัลกอริทึมแบบคลาสสิกเทียบกับแบบปลอดภัยควอนตัม

สิ่งเหล่านี้ยังไม่ได้รับการแก้ไขและต้องใช้เวลาหลายปีกว่าที่นักพัฒนาโปรโตคอลและแอปพลิเคชันจะจัดการประชุมคณะทำงานเพื่อตัดสินใจว่าจะทำสิ่งนี้ในทางเทคนิค ลอจิสติกส์ และอื่น ๆ อย่างไร

Score:1
ธง my

มีการสำรวจข้อเสนอต่างๆ สำหรับใบรับรอง X509 V3 ในโลกของ Post Quantum Cryptography (PQC)

ความเข้าใจนี้ถูกต้องหรือไม่?

ในมุมมองของฉัน มีสองวิธีหลักในการมีทั้งแบบคลาสสิกและหลังควอนตัมพร้อมใบรับรอง:

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

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

ฉันไม่เห็นความเห็นเป็นเอกฉันท์ว่าตัวเลือกใดในสองตัวเลือกนี้เหมาะสมกว่ากัน ฉันจะไม่แปลกใจเลยหากการใช้ใบรับรองที่แตกต่างกันอาจใช้วิธีการที่แตกต่างกัน

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

อุตสาหกรรมพิจารณา TLS อย่างไร

ฉันจะถือว่าส่วนนี้กำลังพูดถึงด้านความเป็นส่วนตัวมากกว่าการรับรองความถูกต้อง

สำหรับ TLS 1.3 (และในขณะนี้ดูเหมือนจะมีเหตุผลเล็กน้อยในการแก้ไข TLS เวอร์ชันก่อนหน้า) ส่วนใหญ่แล้วค่อนข้างจะได้ผล: เราจะเพิ่ม 'กลุ่มที่มีชื่อ' [1] เพิ่มเติมซึ่งเป็นอัลกอริทึมการแลกเปลี่ยนคีย์ที่ใช้ นอกเหนือจากที่มีอยู่ (เช่น X25519) เราจะเพิ่มชื่อ 'NTRU' (ซึ่งจะแสดงรายการชุดพารามิเตอร์ NTRU) เช่นเดียวกับ 'X25519+NTRU' สิ่งหลังจะทำคือใช้ทั้ง X25519 และ NTRU ควบคู่กันไป คีย์ที่ใช้ร่วมกันคือ X25519 และคีย์ที่ใช้ร่วมกันของ NTRU ต่อกัน และความลับที่ใช้ร่วมกันคือ X25519 และคีย์ที่ใช้ร่วมกันของ NTRU เชื่อมติดกัน (TLS 1.3 มี KDF ที่แข็งแกร่ง ดังนั้นการต่อข้อมูลจึงทำงานได้ดี) นี้มีรายละเอียดอยู่ใน ร่าง IETF ฉบับนี้

สิ่งนี้ทำให้เส้นทางการอัพเกรดง่ายขึ้น ลูกค้าจะเสนอชื่อกลุ่ม X25519+NTRU และ X25519; เซิร์ฟเวอร์ที่เข้าใจ postquantum จะยอมรับเซิร์ฟเวอร์แรก เซิร์ฟเวอร์ที่ไม่สามารถถอยกลับไปที่สอง จากนั้น เมื่อถึงเวลาที่จะยกเลิกคลาสสิก ลูกค้าก็จะเริ่มเสนอ NTRU (เท่านั้น); เส้นทางการอัปเกรดเดียวกันก็ใช้งานได้เช่นกัน

ฉันเชื่อว่า OpenSSH กำลังเดินไปตามเส้นทางที่คล้ายกัน (เฉพาะกับ NTRUprime); อย่างไรก็ตามฉันยังไม่ได้ดูรายละเอียดเพื่อความแน่ใจ


[1]: 'กลุ่มที่มีชื่อ' ตอนนี้กลายเป็นชื่อเรียกที่ผิด เนื่องจากอัลกอริทึมหลังควอนตัมไม่ได้ขึ้นอยู่กับกลุ่ม...

โพสต์คำตอบ

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