هزینهٔ یک عملیات مشخص و شواهد مربوط به یک تهدید مشخص را مقایسه کنید، نه فقط نمودار درخت را با نمودار کلید فرستنده.
Messaging Layer Security یا MLS و LGS1 متعلق به Livara، دو گواهی قابل جایگزین برای امنیت چت گروهی نیستند. MLS یک استاندارد پروتکل IETF است؛ LGS1 طراحی مختص محصول Livara است که مستنداتش منتشر شده است. مقایسهٔ منصفانهٔ آن‌ها مستلزم تفکیک معماری، شواهد پیاده‌سازی و رفتاری است که کاربران واقعاً تجربه می‌کنند.
تفاوت اصلی، وضعیت مشترک گروه مبتنی بر درخت در برابر کلیدهای فرستنده‌ای است که از طریق نشست‌های دونفره توزیع می‌شوند. هیچ‌یک از این نام‌ها به‌تنهایی نمی‌گوید آیا یک برنامهٔ مشخص با عضو حذف‌شده، دستگاه دارای وضعیت قدیمی یا کلید افشاشده درست برخورد می‌کند.
تفاوت معماری
RFC 9420 پروتکل MLS را برای برقراری ناهمگام کلید گروهی مشخص می‌کند. این پروتکل از درخت رچت و دوره‌های گروه استفاده می‌کند و تحت شرایط بیان‌شده، محرمانگی پیشرو و امنیت پس از نفوذ را فراهم می‌آورد. ساختار درختی با بزرگ‌تر شدن گروه، برخی هزینه‌های به‌روزرسانی کلید را کاهش می‌دهد.
مستندات امنیتی Livara پروتکل LGS1 را یک زنجیرهٔ فرستندهٔ امضاشده برای هر عضو توصیف می‌کند که از طریق نشست‌های دونفرهٔ LVR1 توزیع و هنگام تغییر عضویت تعویض می‌شود. این ادعای محصول است، نه شاهدی بر انطباق LGS1 با MLS یا برخورداری آن از همان تحلیل.
| پرسش | MLS | مستندات Livara LGS1 |
|---|---|---|
| ساختار مشترک | درخت رچت و دوره‌ها | زنجیره‌های جداگانه برای هر فرستنده |
| به‌روزرسانی کلید | ثبت تغییرات وضعیت گروه در یک دورهٔ جدید | توزیع کلیدهای تازهٔ فرستنده میان اعضا |
| وضعیت مشخصات | استاندارد IETF، یعنی RFC9420 | شرح منتشرشدهٔ مختص محصول |
| آنچه همچنان نیاز به ارزیابی دارد | یکپارچه‌سازی با برنامه و پیاده‌سازی | مشخصات کامل، پیاده‌سازی و شواهد مستقل |
این جدول دسته‌های طراحی را توصیف می‌کند؛ بنچمارک یا رتبه‌بندی امنیت نیست.
«لگاریتمی» چه معنایی دارد و چه معنایی ندارد؟
یک به‌روزرسانی رمزنگاری می‌تواند از تعداد لگاریتمی اجزای رمزنگاری‌شدهٔ مسیر درخت استفاده کند، بدون آنکه تمام کارهای سامانه لگاریتمی شوند. پیام‌ها همچنان باید توزیع شوند، کلاینت‌ها وضعیت نگه می‌دارند و رفتار به ساختار گروه و عملیات بستگی دارد. مقایسهٔ قدیمیِ «MLS به O(log N) پیام نیاز دارد اما همه‌چیز در LGS1 سریع‌تر است» هزینه‌های متفاوت را با هم مخلوط می‌کرد و اندازه‌گیری‌ای ارائه نمی‌داد.
معماری MLS در RFC 9750 سرویس تحویل را جدا از برقراری رمزنگاری‌شدهٔ کلید بررسی می‌کند و دربارهٔ توزیع پیام و ترتیب تغییرات گروه بحث می‌کند. این جداسازی مهم است: محاسبات کلاینت، تعداد بایت در یک کامیت، مجموع ارسال‌های سرور به گیرندگان و ترافیک اتصال دوباره، معیارهای متفاوتی هستند.
یک گزارش معنادار کارایی باید این موارد را مشخص کند:
- اندازهٔ گروه و تعداد دستگاه‌های هر فرد؛
- اینکه عملیات، پیام عادی، حذف عضو، به‌روزرسانی کلید یا اتصال دوباره است؛
- بایت‌های ارسالی کلاینت آغازگر در برابر کل ترافیک تحویل؛
- زمان سپری‌شده، مدل دستگاه، نسخهٔ پیاده‌سازی و شرایط شبکه؛
- هزینهٔ به‌روزرسانی‌های ازدست‌رفته و تغییرات مکرر عضویت.
بدون این جزئیات، ادعاهای «میلی‌ثانیه‌ای»، «سربار کمِ وضعیت» یا برتری در اندازهٔ مشخصی از گروه اثبات نشده‌اند.
حذف عضو یک آزمون چرخهٔ عمر است
حذف حساب توسط مدیر تنها بخشی از ماجرای امنیت است. کلاینت‌ها باید دربارهٔ وضعیت جدید عضویت توافق کنند، کلیدهای تازهٔ مناسب به کار ببرند و آن کلیدها را به دستگاه‌های حذف‌شده ندهند. کسی که از قبل متن آشکار یا کلیدهای قدیمی را دارد ممکن است همچنان به محتوای قدیمی دسترسی داشته باشد؛ حذف نمی‌تواند نسخه‌های او را ناپدید کند.
برای هر دو سامانه، آزمون مفید می‌پرسد: پس از تکمیل حذف، آیا دستگاه حذف‌شده می‌تواند یک پیام آزمایشی غیرحساسِ جدید را رمزگشایی کند؟ آیا عضوی که آفلاین بوده با ایمنی به وضعیت روز می‌رسد؟ آیا همهٔ دستگاه‌های یک حساب پوشش داده می‌شوند؟ آیا رابط کاربری شکست‌ها یا تغییرات عضویت را آشکار می‌کند؟
این‌ها پرسش‌های پیشنهادی برای ارزیابی‌اند، نه نتایج آزمایش‌هایی که اینجا انجام شده باشند. مقایسهٔ محصول باید نتیجهٔ مشاهده‌شده و نسخهٔ آزمایش را منتشر کند، نه اینکه کلیک موفق مدیر را معادل حذف رمزنگارانه بداند.
محرمانگی پیشرو و بازیابی مشروط هستند
حفاظت از پیام‌های قدیمی پس از افشای بعدی کلید، به بازنشسته کردن مواد محرمانهٔ قدیمی وابسته است. بازیابی حفاظت پیام‌های آینده به وارد کردن رازهای تازه پس از قطع دسترسی مرتبط مهاجم بستگی دارد. در MLS، پردازش به‌روزرسانی‌های گروه بخشی از این بازیابی است؛ صرف ارسال به‌روزرسانی، به معنای اعمال آن توسط همهٔ اعضا نیست. ملاحظات امنیتی RFC 9420 را ببینید.
در طراحی کلید فرستنده بپرسید وضعیت افشاشدهٔ هر فرستنده چگونه جایگزین و دوباره توزیع می‌شود. یک زنجیرهٔ یک‌طرفه به‌تنهایی نباید به‌عنوان ترمیم خودکار در برابر مهاجمی توصیف شود که وضعیت کنونی آن را می‌داند. حفاظت دونفره هنگام توزیع دوباره مهم است، اما جای تحلیل کامل در سطح گروه را نمی‌گیرد.
ادعاهای پساکوانتومی به مجموعهٔ رمز و دامنهٔ مشخص نیاز دارند
مجموعه‌های رمز تعریف‌شده در RFC9420 پایه از سازوکارهای کلاسیک کلید عمومی استفاده می‌کنند. MLS توسعه‌پذیر است؛ بنابراین ادعا دربارهٔ یک پیاده‌سازی مشخص باید مجموعهٔ رمز و افزونه‌های واقعی آن را مشخص کند، نه اینکه همهٔ استقرارهای MLS را برای همیشه کلاسیک بداند.
استفادهٔ مستند LGS1 از توزیع ترکیبی LVR1، ادعایی متفاوت از تضمین پساکوانتومیِ مستقلاً تحلیل‌شده برای تمام عملیات گروه است. FIPS 203 الگوریتم ML-KEM را استاندارد می‌کند؛ پروتکل گروهی کاملی را که از آن استفاده می‌کند تأیید نمی‌کند. احراز هویت، تغییر عضویت، افشای کلید و پیاده‌سازی را با هم ارزیابی کنید، نه فقط نام KEM را.
پیش از تصمیم دربارهٔ محصول چه بخواهیم؟
مشخصات فعلی پروتکل، بردارهای آزمون و بررسی مستقل مختص نسخه را، همراه با یافته‌های حل‌نشده، بخواهید. سپس نیازهای معمول محصول را مقایسه کنید: دستگاه‌های پشتیبانی‌شده، رفتار به‌روزرسانی، بازیابی، نقش‌های مدیریت و داده‌های نگهداری‌شده توسط سرورها.
معماری MLS صراحتاً سرویس‌های برنامه و فرض‌های اعتماد آن‌ها را در نظر می‌گیرد. به همین شکل، مدل تهدید Livara باید کنار ادعاهای محصول خوانده شود. رمزنگاری مشارکت‌کنندگان مجاز را قابل اعتماد نمی‌کند، جلوی اسکرین‌شات را نمی‌گیرد و تمام اشکال فراداده را حذف نمی‌کند.
اگر شواهدی وجود ندارد، «اثبات نشده» ثبت کنید، نه اینکه خودکار طراحی را ناامن یا برتر بنامید. تصمیم باید خطرهای گروه شما و کیفیت شواهد موجود را منعکس کند.
پرسش‌های متداول
آیا LGS1 پیاده‌سازی MLS است؟
شرح‌های منتشرشده معماری‌های متفاوتی را نشان می‌دهند. این مقاله LGS1 را پیاده‌سازی MLS معرفی نمی‌کند و ادعای تعامل‌پذیری ندارد.
آیا MLS نیاز دارد همهٔ اعضا هم‌زمان آنلاین باشند؟
خیر. استفادهٔ ناهمگام بخشی از طراحی آن است. برنامه‌ها همچنان به سیاست‌هایی برای به‌روزرسانی تأخیردار، وضعیت قدیمی و اعضای مدت‌طولانی آفلاین نیاز دارند.
آیا توزیع کلید پساکوانتومی امنیت گروه را حل می‌کند؟
خیر. این کار بخشی از برقراری کلید را پوشش می‌دهد. هویت، عضویت، چرخهٔ عمر کلید، امنیت نقطهٔ پایانی و پیاده‌سازی همچنان به شواهد نیاز دارند.
کدام طراحی سریع‌تر است؟
در این مقاله بنچمارکی که برنده‌ای تعیین کند وجود ندارد. عملیات و محیط استقراری را اندازه‌گیری کنید که برای گروه شما اهمیت دارند.
