پیش‌کلیدها اجازه می‌دهند گیرنده هنگام برقراری نشست آفلاین باشد، اما نیاز به مسیر تحویل یا مدیریت دقیق چرخهٔ عمر کلید خصوصی را از بین نمی‌برند.
گیرندهٔ آفلاین می‌تواند پیام رمزنگاری‌شده را بعداً دریافت کند، چون دستگاهش از پیش مواد کلید عمومی را منتشر کرده است. فرستنده همچنان به یک سرویس تحویلِ در دسترس نیاز دارد؛ «رمزنگاری ناهمگام» به این معنا نیست که پیام‌ها از قطعی شبکه عبور می‌کنند یا فوراً روی گوشیِ قطع‌شده از شبکه ظاهر می‌شوند.
طراحی‌های پساکوانتومی این ایده را با یک سازوکار کپسوله‌سازی کلید گسترش می‌دهند. پرسش‌های مهم این است که راز اولیه چگونه برقرار می‌شود، کلیدهای خصوصی قدیمی چگونه بازنشسته می‌شوند و پیام‌های بعدی چگونه امنیت را تازه می‌کنند.
پیش‌کلیدها مشکل زمان‌بندی را حل می‌کنند
فرض کنید وقتی سام گفت‌وگویی تازه را آغاز می‌کند، مایا آفلاین است. دستگاه مایا قبلاً پیش‌کلیدهای عمومی را بارگذاری کرده است. سام می‌تواند آن مواد را دریافت کند، بخش فرستندهٔ توافق کلید را انجام دهد و نخستین پیام رمزنگاری‌شده را بفرستد. مایا پس از اتصال دوباره، با کلیدهای خصوصیِ نگهداری‌شده روی دستگاه خود، آن را پردازش می‌کند.
بنابراین سرور اطلاعات عمومی را ارائه می‌کند و داده‌های رمزنگاری‌شده را در صف می‌گذارد؛ لازم نیست راز پیامِ حاصل را در اختیار داشته باشد. مشخصات X3DH سیگنال شرحی دست‌اول از این طراحی ناهمگام است. پیش‌کلید امضاشده و پیش‌کلید یک‌بارمصرف عمر و نقش متفاوتی دارند؛ «پیش‌کلید» به معنای گذرواژه‌ای محرمانه نیست که روی سرور بارگذاری شود.
برای گفت‌وگویی که از قبل برقرار شده، برنامه ممکن است از وضعیت موجود نشست استفاده کند، نه اینکه برای هر پیام راه‌اندازی اولیه را تکرار کند. آغاز نشست و پیش‌برد کلیدهای پیام آن، دو عملیات جدا هستند.
یک KEM پساکوانتومی چه چیزی اضافه می‌کند؟
سازوکار کپسوله‌سازی کلید سه عملیات پایه دارد: تولید کلید، کپسوله‌سازی با کلید عمومی و کپسوله‌گشایی با کلید خصوصی متناظر. کپسوله‌سازی هم یک راز مشترک و هم یک متن رمز تولید می‌کند. متن رمز می‌تواند بعداً تحویل داده شود؛ خود راز به‌صورت آشکار فرستاده نمی‌شود.
NIST FIPS 203 استاندارد ML-KEM را تعریف می‌کند. در ML-KEM-768، کلید عمومی کپسوله‌سازی ۱٬۱۸۴ بایت، متن رمز ۱٬۰۸۸ بایت و راز مشترک ۳۲ بایت است. این‌ها اندازه‌های سطح الگوریتم هستند، نه اندازهٔ یک بستهٔ کامل پیام‌رسانی. امضاها، کلیدهای کلاسیک، شناسه‌ها و قاب‌بندی انتقال سربار اضافه می‌کنند؛ کلید عمومیِ ذخیره‌شده در حافظهٔ نهان ممکن است همراه هر پیام ارسال نشود.
در یک ساختار ترکیبی، پروتکل مواد محرمانهٔ کلاسیک و پساکوانتومی را بر اساس برنامهٔ مشخصِ مشتق‌سازی کلید ترکیب می‌کند. صرف کنار هم گذاشتن نام الگوریتم‌ها، امنیت این ترکیب را ثابت نمی‌کند. پیوند با هویت، اعتبارسنجی، جداسازی دامنه و مدیریت شکست به مشخصات و بازبینی نیاز دارند.
یک نمونه: PQXDH، نه یک الگوی جهان‌شمول
مشخصات PQXDH سیگنال پیش‌کلیدهای یک‌بارمصرف پساکوانتومیِ امضاشده و یک کلید ذخیرهٔ نهاییِ امضاشده را توصیف می‌کند. فرستنده امضاهای ارائه‌شده را بررسی می‌کند، توافق کلید را انجام می‌دهد و متن رمز KEM و شناسه‌های کلید را همراه نخستین پیام رمزنگاری‌شده می‌فرستد. گیرنده بعداً همان راز را مشتق می‌کند و پیام را پردازش می‌کند.
کلید ذخیرهٔ نهایی امکان راه‌اندازی را هنگام نبود کلیدهای یک‌بارمصرف KEM فراهم می‌کند، اما تحلیل امنیت در صورت افشای کلید یکسان نیست. حذف و چرخش کلید خصوصی بر حفاظت از نشست‌های پیشین اثر می‌گذارند. این مشخصات همچنین محرمانگی پیشروِ پساکوانتومی را از احراز هویت در برابر مهاجم فعال کوانتومی جدا می‌کند. این جزئیات نباید با عبارت «روش جایگزین هیچ هزینهٔ امنیتی ندارد» جایگزین شوند.
PQXDH یک ساختار مشخص و مستند است. منحنی‌ها، امضاها و انتخاب پارامترهای دقیق آن نباید در توصیف محصول دیگری کپی شوند، مگر اینکه آن محصول همان موارد را مستند کرده باشد.
رچت با مخزن پیش‌کلید یکسان نیست
پیش‌کلیدها از برقراری نشست پشتیبانی می‌کنند. پروتکل رچت در طول گفت‌وگو رازها را تغییر می‌دهد. مشخصات Double Ratchet تحول کلید پیام و ساختارهای جدیدتر رچت پساکوانتومی را توضیح می‌دهد؛ از جمله طراحی‌هایی که با هر پیام برنامه، یک تبادل کامل پساکوانتومی ارسال نمی‌کنند.
محرمانگی پیشرو به حفاظت پیام‌های قبلی پس از افشای بعدی کلید مربوط است. امنیت پس از نفوذ به بازیابی امنیت ارتباطات آینده پس از قطع دسترسی مهاجم و وارد شدن مواد محرمانهٔ تازه مربوط می‌شود. هیچ‌یک به این معنا نیست که بدافزار بتواند برای همیشه روی گوشی بماند و رمزنگاری به‌نوعی متن آشکار آن گوشی را از بدافزار پنهان کند.
حذف یک پیش‌کلید عمومی از سرور مانع استفادهٔ مجدد معمول آن می‌شود؛ این کار معادل حذف کلید خصوصی متناظر از نقطهٔ پایانی نیست. ممیزی مفید هم قواعد چرخهٔ عمر و هم رفتار پیام‌های تأخیردار را بررسی می‌کند.
Livara چه چیزی را مستند می‌کند و چه چیزهایی هنوز به شواهد نیاز دارند؟
صفحهٔ امنیت Livara برقراری نشست ترکیبی با کلیدهای یک‌بارمصرف در صورت موجود بودن، پیش‌برد عادی زنجیرهٔ پیام و دوره‌های متناوب ML-KEM را شرح می‌دهد. این با ادعای قدیمیِ انجام یک تبادل کامل و تازهٔ ML-KEM برای هر پیام تفاوت دارد. این‌ها گفته‌های مستندات محصول هستند، نه تأیید مستقل پیاده‌سازی.
از این گفته‌ها سیاست مشخصی برای جایگزین هنگام اتمام کلیدها، فاصلهٔ زمانی تأمین دوبارهٔ کلیدها یا عددی برای تأخیر شبکه استنباط نکنید. چنین پرسش‌هایی به مستندات پروتکل مختص هر نسخه یا نتایج اندازه‌گیری نیاز دارند. Proof Lab نیز آزمونی کامل برای راه‌اندازی ناهمگام، اتمام کلید یا بازیابی پیام تأخیردار نیست.
چگونه ادعاهای پیام‌رسانی آفلاین را ارزیابی کنیم؟
از عرضه‌کننده یا بررسی‌کننده شواهدی بخواهید که این موارد را پوشش دهد:
| مورد آزمایش | چه چیزی را مشاهده کنیم |
|---|---|
| نخستین پیام به مخاطبِ قطع‌شده از شبکه | چه مواد کلید عمومی استفاده شده و گیرنده واقعاً چه زمانی پیام را دریافت می‌کند |
| تمام شدن پیش‌کلیدهای یک‌بارمصرف | آیا راه‌اندازی متوقف می‌شود یا از روش جایگزین مستند پیروی می‌کند، و موازنهٔ امنیتی اعلام‌شدهٔ آن چیست |
| نصب دوباره یا تغییر هویت گیرنده | آیا پیام‌های قدیمیِ صف همچنان رمزگشایی می‌شوند و تغییر کلید قابل مشاهده است |
| پیام‌های تأخیردار یا جابه‌جاشده در ترتیب | محدودیت نگهداری، مدیریت کلیدهای ردشده و خطاهای قابل فهم |
| بازگشت پس از غیبتی طولانی | تازه‌سازی امن کلید، پردازش دارای حد مشخص و وضعیت دقیق تحویل |
| مقایسهٔ کارایی | دستگاه، نسخهٔ برنامه، شبکه، اندازهٔ محموله و اندازه‌گیری جداگانهٔ راه‌اندازی اولیه در برابر نشست برقرارشده |
از حساب‌ها و پیام‌های آزمایشی غیرحساس استفاده کنید. آزمون موفق تحویل، همان سناریو را نشان می‌دهد، نه تمام ویژگی‌های رمزنگاری را. در مقابل، تحویل ناموفق ممکن است مسئلهٔ شبکه یا چرخهٔ عمر باشد، نه شکستن رمز.
پرسش‌های متداول
آیا هنگام ارسال من، گیرنده می‌تواند آفلاین باشد؟
بله، اگر برنامه مواد عمومی لازم و زیرساخت تحویل و ذخیره‌سازی را داشته باشد. گیرنده تا زمانی که دستگاهش نتواند پیامِ صف را دریافت و پردازش کند، نمی‌تواند آن را بخواند.
آیا کلیدهای بزرگ‌تر KEM همیشه چت را به‌شکل محسوسی کندتر می‌کنند؟
از اندازهٔ کلید به‌تنهایی نمی‌توان حکمی کلی دربارهٔ زمان داد. دفعات راه‌اندازی، پردازش دسته‌ای، حافظهٔ نهان، پیاده‌سازی و شرایط شبکه مهم هستند. به‌جای وعدهٔ سربار صفر، نتیجهٔ بنچمارک منتشر کنید.
آیا پیش‌کلید امضاشده شخص پشت حساب را ثابت می‌کند؟
این پیش‌کلید، مواد را نسبت به یک هویت امضاکننده اصالت‌سنجی می‌کند. اینکه آن هویت چگونه به فردی که قصد تماس با او را دارید پیوند می‌خورد، پرسش جداگانه‌ای دربارهٔ اعتماد و راستی‌آزمایی است.
آیا رمزنگاری پساکوانتومی بدون هیچ اتصالی کار می‌کند؟
برخی محاسبات محلی می‌توانند آفلاین اجرا شوند. تحویل پیام همچنان به مسیر ارتباطی نیاز دارد؛ رمزنگاری چنین مسیری فراهم نمی‌کند.
