SHARE THE PERSPECTIVE
การเดินหน้าสายโซ่ต่อข้อความกับการรีเฟรชยุคหลังควอนตัม แก้ปัญหาคนละส่วนของแรตเช็ต

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

Livara อธิบายแนวทางนี้สำหรับ LVR1 โดยใช้ P-256 และ ML-KEM-768 การเข้าใจการออกแบบต้องแยกการตั้งกุญแจเริ่มต้น การอัปเดตสายโซ่ข้อความตามปกติ และการรีเฟรชหลังควอนตัมเป็นระยะออกจากกัน สิ่งเหล่านี้ไม่ใช่การดำเนินการเดียวกันที่เกิดขึ้นกับทุกข้อความ

จากความลับร่วมสู่กุญแจข้อความที่เปลี่ยนแปลง

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

NIST FIPS 203 กำหนด ML-KEM รวมถึงชุดพารามิเตอร์ ML-KEM-768 กลไกนี้สร้างความลับร่วม ส่วนรหัสลับแบบมีการรับรองความถูกต้อง เช่น AES-GCM ใช้เข้ารหัสเพย์โหลดข้อความ การยืนยันความถูกต้องและวิธีผสานองค์ประกอบต่าง ๆ เป็นเรื่องของโปรโตคอลในภาพรวม

ภาพรวมความปลอดภัยของ Livara อธิบายการตั้งกุญแจแบบไฮบริด รากแบบดั้งเดิมและหลังควอนตัมที่เป็นอิสระต่อกัน สายโซ่ส่งและรับทางเดียวที่เดินหน้าตามข้อความ และการอัปเดตยุค ML-KEM เป็นระยะ โดยระบุว่ากุญแจข้อความถูกผสานกับรากหลังควอนตัมปัจจุบันก่อนนำไปป้องกันเนื้อหาและส่วนหัว

ไม่ควรเขียนคำอธิบายนี้ใหม่ว่า “เกิดการแลกเปลี่ยน P-256 ใหม่และการห่อหุ้ม ML-KEM ใหม่ในทุกข้อความ” การเดินหน้าสายโซ่อาจเป็นขั้นตอนอนุพันธ์กุญแจที่มีต้นทุนค่อนข้างต่ำ

ยุคหนึ่งเปลี่ยนแปลงอะไร

ยุคหรือ epoch คือช่วงของสถานะโปรโตคอลที่สัมพันธ์กับการรีเฟรชครั้งหนึ่ง การกำหนดเวลาส่งข้อความตั้งกุญแจขนาดใหญ่กระจายไปตามยุคอาจลดภาระการสื่อสารซ้ำ ๆ ได้ แต่ก็ทำให้กฎการรีเฟรชมีความสำคัญต่อความปลอดภัยด้วย

ผู้ตรวจสอบควรถามว่า:

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

การนำไปใช้ต้องมีคำตอบที่ชัดเจน คำว่า “เป็นระยะ” เพียงอย่างเดียวไม่ใช่ข้อกำหนดการฟื้นตัวหรือการทำงานร่วมกันที่ครบถ้วน

วัดขนาดองค์ประกอบพื้นฐานโดยไม่แต่งผลทดสอบ

FIPS 203 กำหนดขนาดกุญแจห่อหุ้มของ ML-KEM-768 ที่ 1,184 ไบต์ และขนาดข้อความรหัสลับที่ 1,088 ไบต์ นี่คือขนาดการเข้ารหัสแทนค่าขององค์ประกอบพื้นฐาน ไม่ใช่ขนาดรวมของข้อความหรือการจับมือของ Livara ส่วนหัวโปรโตคอล ลายเซ็น การจัดกรอบ และความถี่ที่ส่งแต่ละค่าคือตัวกำหนดปริมาณข้อมูลจริง

ขนาดกุญแจ P-256 ก็ขึ้นอยู่กับรูปแบบการแทนค่า ตัวอย่างเช่น จุดบนเส้นโค้งที่บีบอัดกับจุดที่ไม่บีบอัดมีความยาวเมื่อเข้ารหัสแทนค่าต่างกัน การเปรียบเทียบ “ขนาดกุญแจ P-256” ที่ไม่ระบุรูปแบบกับข้อความรหัสลับ ML-KEM จึงไม่ใช่การวิเคราะห์แบนด์วิดท์ที่ครบถ้วน

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

การรักษาความลับย้อนหลังและการฟื้นตัวหลังถูกเจาะ

การรักษาความลับย้อนหลังหรือ forward secrecy มุ่งป้องกันข้อความก่อนหน้าเมื่อความลับบางอย่างในภายหลังถูกเปิดเผย โดยมีเงื่อนไขว่าความลับเก่าที่จำเป็นถูกลบแล้ว ความปลอดภัยหลังถูกเจาะหรือ post-compromise security เกี่ยวข้องกับการกลับมามีการป้องกันหลังผู้โจมตีไม่ได้ควบคุมปลายทางอีกต่อไป และมีวัสดุลับใหม่ที่ผู้โจมตีไม่รู้เข้าสู่โปรโตคอล

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

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

รักษาขอบเขตของฟีเจอร์ให้ชัดเจน

ในเอกสารของ Livara กุญแจผู้ส่งของกลุ่ม LGS1 ถูกแจกจ่ายผ่านเซสชัน LVR1 แบบคู่ต่อคู่ นั่นไม่ได้หมายความว่าสายโซ่ผู้ส่งของกลุ่มมีโครงสร้างเหมือนแรตเช็ตคู่ของแชตโดยตรง หน้าความปลอดภัยปัจจุบันยังยกเว้นกลุ่มเก่าที่ไม่เข้ากันออกจาก E2EE และกำหนดให้สมาชิกพร้อมก่อนสร้างกลุ่มเข้ารหัสใหม่

ไฟล์แนบมีกุญแจเนื้อหาของตนเองซึ่งส่งภายในบทสนทนาที่ได้รับการป้องกัน การโทรและการบันทึกบนเซิร์ฟเวอร์แบบเลือกใช้ต้องได้รับการตรวจสอบแยกต่างหาก อย่าอนุมานว่าสื่อได้รับการป้องกันหลังควอนตัมเพียงเพราะเส้นทางสัญญาณใช้เซสชันแบบไฮบริด ช่องสาธารณะและเมทาดาทาด้านปฏิบัติการอยู่นอกขอบเขตความลับของเนื้อหาส่วนตัว

อะไรจะช่วยเพิ่มความมั่นใจ?

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

Proof Lab ของ Livara สาธิตองค์ประกอบพื้นฐานแบบดั้งเดิมที่เลือกไว้ และยกเว้นการผสาน LVR1/LGS1 แบบเต็มออกจากชุดทดสอบในเครื่องนั้นอย่างชัดเจน แบบจำลองภัยคุกคามยังเป็นบริบทที่จำเป็น เอกสารเหล่านี้ร่วมกันช่วยกำหนดคำถาม แต่ไม่ควรนำเสนอแทนการประเมินโปรโตคอลและการนำไปใช้อย่างครบถ้วน

สำรวจแบบจำลองภัยคุกคามของ Livara
CONTINUE THE THREADPost-quantum encryption ↗
YOU’VE REACHED THE ENDBack to the reading room ↗