การส่งข้อความแบบต้านทานควอนตัมทำงานอย่างไรเมื่อผู้ติดต่อออฟไลน์

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

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

พรีคีย์แก้ปัญหาเรื่องจังหวะเวลา

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

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

สำหรับบทสนทนาที่สร้างเซสชันไว้แล้ว แอปอาจใช้สถานะเซสชันเดิม แทนที่จะทำขั้นตอนเริ่มต้นซ้ำทุกข้อความ การเริ่มเซสชันกับการเลื่อนสถานะกุญแจข้อความเป็นคนละกระบวนการ

KEM ที่ต้านทานควอนตัมเพิ่มอะไร

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

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

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

ตัวอย่าง: PQXDH ไม่ใช่พิมพ์เขียวสำหรับทุกผลิตภัณฑ์

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

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

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

แรตเชตไม่ใช่สิ่งเดียวกับคลังพรีคีย์

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

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

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

สิ่งที่ Livara ระบุไว้ และสิ่งที่ยังต้องมีหลักฐาน

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

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

วิธีประเมินคำกล่าวอ้างเรื่องการส่งข้อความถึงผู้รับออฟไลน์

ขอหลักฐานจากผู้ขายหรือผู้ตรวจสอบที่ครอบคลุมกรณีเหล่านี้:

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

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

คำถามที่พบบ่อย

ผู้รับออฟไลน์ขณะที่ฉันส่งได้หรือไม่?

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

กุญแจ KEM ที่ใหญ่ขึ้นทำให้แชตช้าลงอย่างเห็นได้ชัดเสมอหรือไม่?

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

พรีคีย์ที่มีลายเซ็นพิสูจน์ตัวบุคคลที่อยู่หลังบัญชีได้หรือไม่?

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

การเข้ารหัสต้านทานควอนตัมทำงานโดยไม่มีการเชื่อมต่อใดเลยได้หรือไม่?

การคำนวณบางอย่างในเครื่องทำงานแบบออฟไลน์ได้ แต่การส่งข้อความยังต้องมีเส้นทางสื่อสาร การเข้ารหัสไม่ได้สร้างเส้นทางนั้นให้