NIP-104: การส่งข้อความแบบ E2EE โดยใช้โปรโตคอล Message Layer Security (MLS)
โดย NIP นี้ได้นำเสนอ E2EE หรือการส่งข้อความที่มีการเข้ารหัสตั้งแต่ต้นทางไปจนถึงปลายทาง โดยเสนอให้มีการเพิ่มไปทั้งแชทส่วนตัวหรือแชทกลุ่ม โดยการใช้โปรโตคอล Messaging Layer Security (MLS)
เดิมทีการส่งข้อความตรงแบบหนึ่งต่อหนึ่ง (DMs) ใน Nostr เกิดขึ้นผ่านรูปแบบที่กำหนดไว้ใน NIP-04 แต่ NIP นี้ไม่ได้รับการแนะนำ เพราะแม้ว่ามันจะเข้ารหัสเนื้อหาของข้อความแต่ความเป็นส่วนตัวของเราและคู่สนทนานั้นกลับไม่มีอยู่เลย
แต่ด้วยการมาของ NIP-44 ทำให้เรามีรูปแบบการเข้ารหัสที่อัปเดตซึ่งปรับปรุงการรับประกันความลับ แต่ก็ไม่ได้กำหนดรูปแบบใหม่สำหรับการส่งข้อความตรง โดยใช้รูปแบบการเข้ารหัสนี้ ดังนั้น จึงแทบจะไม่สร้างความแตกต่างใด ๆ กับความเป็นส่วนตัว
และล่าสุดนี้ NIP-17 ได้รวมการเข้ารหัส NIP-44 และ warp ด้วย NIP-59 เพื่อซ่อนข้อความตรงที่เข้ารหัสไว้ภายในชุดของกิจกรรมอื่น ๆ เพื่อให้แน่ใจว่าไม่สามารถมองเห็นได้ว่าใครกำลังคุยกับใคร และเมื่อใดที่ข้อความถูกส่งผ่านระหว่างผู้ใช้ ซึ่งส่วนใหญ่จะช่วยแก้ปัญหารั่วไหลของข้อมูล ในขณะที่ยังคงเป็นไปได้ที่จะเห็นว่าผู้ใช้กำลังรับ event ที่ warp แต่คุณไม่สามารถบอกได้ว่ามาจากใคร และ event ประเภทใดที่อยู่ภายใน event ที่ถูก warp ซึ่งจะช่วยให้ปฏิเสธได้ในระดับหนึ่ง แต่ก็ไม่ได้แก้ปัญหาการรักษาความลับล่วงหน้าหรือความปลอดภัยหลังการถูกบุกรุก กล่าวคือ หากกุญแจส่วนตัวของผู้ใช้ (หรือกุญแจการสนทนาที่คำนวณร่วมกันระหว่างผู้ใช้สองคนที่ใช้ในการเข้ารหัสข้อความ) ถูกโจมตี ผู้โจมตีจะสามารถเข้าถึง DMs ทั้งหมดที่ส่งผ่านระหว่างผู้ใช้เหล่านั้นได้อย่างสมบูรณ์ทั้งในอดีตและอนาคต
นอกจากนี้ ทั้ง NIP-04 หรือ NIP-17 ต่างก็ไม่ได้พยายามแก้ปัญหาของการส่งข้อความในแชทกลุ่ม
แล้วทำไมมันถึงสำคัญละ?
เพราะว่าหากปราศจาก E2EE ที่เหมาะสม Nostr จะไม่สามารถใช้เป็นโปรโตคอลสำหรับไคลเอนต์การส่งข้อความที่ปลอดภัยได้ ในขณะที่ไคลเอนต์อย่าง Signal ทำงานได้อย่างยอดเยี่ยมกับ E2EE แต่ก็ยังคงอาศัยเซิร์ฟเวอร์ส่วนกลาง ซึ่งอาจถูกปิดกั้นโดยผู้ที่มีอำนาจ และเป้าหมายของ Nostr ไม่ใช่แค่การป้องกันหน่วยงานส่วนกลางจากการเซ็นเซอร์คุณและการสื่อสารของคุณ แต่ยังรวมถึงการป้องกันไม่ให้ผู้ที่มีอำนาจระดับรัฐสามารถหยุดยั้งบริการประเภทนี้ได้ตั้งแต่แรก การแทนที่เซิร์ฟเวอร์ส่วนกลางด้วยรีเลย์แบบกระจายศูนย์ทำให้ผู้ที่มีอำนาจแทบจะเป็นไปไม่ได้เลยที่จะหยุดการสื่อสารระหว่างผู้ใช้แต่ละรายได้อย่างสมบูรณ์
แล้วทำไมต้องเป็น MLS?
การปรับใช้โปรโตคอล Message Layer Security (MLS) ให้เข้ากับการใช้งาน Nostr ลองคิดง่าย ๆ ว่า MLS เป็นวิวัฒนาการของ Signal Protocol ก็ได้ อย่างไรก็ตาม MLS ได้ปรับปรุงความสามารถในการขยายขนาดของการดำเนินการเข้ารหัสสำหรับการส่งข้อความกลุ่มขนาดใหญ่ได้อย่างมาก (linear -> log) โดยสร้างขึ้นเพื่อรองรับสภาพแวดล้อมแบบรวมศูนย์ และยังช่วยให้อัปเดตชุดรหัสและเวอร์ชันได้อย่างราบรื่นเมื่อเวลาผ่านไป นอกจากนี้ยังมีความยืดหยุ่นสูงและข้อความเข้ารหัสที่ส่งในระบบนั้นไม่ขึ้นอยู่กับเนื้อหาของข้อความที่ส่ง การอธิบายโปรโตคอล MLS นั้นอยู่นอกเหนือขอบเขตของ NIP นี้ แต่คุณสามารถอ่านเพิ่มเติมได้ในภาพรวมทางสถาปัตยกรรมหรือ RFC MLS กำลังอยู่ระหว่างการพัฒนาเป็นมาตรฐานอินเทอร์เน็ตภายใต้ IETF ดังนั้นโปรโตคอลจึงได้รับการตรวจสอบและวิจัยมาเป็นอย่างดี ซึ่งหมายความว่า MLS มีศักยภาพในการทำงานร่วมกันของการส่งข้อความข้ามเครือข่ายได้ในอนาคต เมื่อ MLS ได้รับการยอมรับมากขึ้น
MLS มีจุดเด่นอะไรที่จะมาช่วยพัฒนา Nostr ได้บ้าง?
- ความเป็นส่วนตัวและความปลอดภัย: แม้ว่าระบบการส่งข้อความส่วนตัวบน nostr ที่มีอยู่แล้วและมีความปลอดภัยที่สูง(NIP-04, NIP17) แต่ในแง่ของความเป็นส่วนตัวนั้นยังบกพร่องอยู่ ซึ่งในจุดนี้เองที่ MLS สามารถเข้ามาช่วยเพิ่มความเป็นส่วนตัวได้
- ความหยืดหยุ่น: MLS นั้นมีระบบการจัดการข้อความแบบกลุ่ม ซึ่งสามารถจัดการได้อย่างมีประสิทธิภาพสูง ซึ่งน่าจะเข้ามาช่วยเสริม
- การสอดคล้องกับการกระจายอำนาจ: การใช้ประโยชน์จากโครงสร้างพื้นฐานรีเลย์แบบกระจายอำนาจที่มีอยู่ของ Nostr สำหรับการส่งข้อความ MLS ทำให้สามารถส่งข้อความได้อย่างปลอดภัย และมีความเป็นส่วนตัวมากขึ้น
เป้าหมายของ NIP นี้
- ข้อความตรงและข้อความกลุ่มแบบส่วนตัวและเป็นความลับ
- ส่วนตัว หมายความว่าผู้สังเกตการณ์ไม่สามารถบอกได้ว่าอลิซและบ็อบกำลังคุยกันอยู่ หรืออลิซเป็นส่วนหนึ่งของกลุ่มใดกลุ่มหนึ่ง ซึ่งจำเป็นต้องมีการปกป้องข้อมูล
- เป็นความลับ หมายความว่าเฉพาะผู้รับที่ต้องการเท่านั้นที่สามารถดูเนื้อหาของการสนทนาได้
- การรักษาความลับล่วงหน้าและความปลอดภัยหลังการถูกบุกรุก
- การรักษาความลับล่วงหน้า หมายความว่าเนื้อหาที่เข้ารหัสในอดีตจะยังคงถูกเข้ารหัสอยู่ แม้ว่ากุญแจจะรั่วไหลก็ตาม
- ความปลอดภัยหลังการถูกบุกรุก หมายความว่าการรั่วไหลของคีย์ไม่อนุญาตให้ผู้โจมตีอ่านข้อความในอนาคตได้อย่างไม่มีกำหนด
- ปรับขนาดได้อย่างมีประสิทธิภาพสำหรับกลุ่มขนาดใหญ่
- อนุญาตให้ใช้อุปกรณ์/ไคลเอนต์หลายเครื่องในการสนทนา/กลุ่มเดียว
