پرسش پشت اصطلاح
رمزنگاری زمانی سرتاسری است که متن ساده و کلید خواندن آن نزد دستگاه شرکتکنندگان مورد نظر بماند. TLS یک گام شبکه و رمزنگاری سرور فضای ذخیره را محافظت میکند، اما سرویس همچنان می‌تواند محتوا را بخواند.
رویکرد قابل بازبینی
ساخت کلید، تأیید هویت، مشتق‌سازی کلید پیام، رمزنگاری احرازشده، فایل، چرخش و بازیابی را مستند کنید. پروتکل را با حالت‌های رابط برای کلید گمشده، اثرانگشت تغییرکرده و تاریخچه غیرقابل بازیابی همراه کنید.
- تعریف نقطه پایانی و مهاجم
- احراز متن رمز و بافت
- توقف امن در نبود هویت لازم
- آزمون بازیابی و چرخش در کلاینت‌ها
مرزی که باید دیده شود
رمزنگاری سرتاسری امنیت دستگاه، حذف فراداده یا برابری همه نوع گفتگو را ثابت نمی‌کند. رمزنگاری ترکیبی هم به بازبینی پیاده‌سازی نیاز دارد؛ نام الگوریتم پساکوانتومی تضمین مستقل نیست.
رمزنگاری سرتاسری دقیقاً چیست؟
در رمزنگاری سرتاسری (E2EE)، فرستنده محتوا را پیش از خروج از دستگاه خود رمز میکند و تنها دستگاههای گیرندگان مورد نظر کلید گشودن آن را دارند. سرویس انتقال و ذخیره‌سازی، متن رمز را جابه‌جا میکند. HTTPS همچنان لازم است، اما فقط مسیر تا سرور را محافظت میکند؛ اگر سرور پیام را باز کند، حفاظت محتوا سرتاسری نیست.
برای ارزیابی یک پیام‌رسان بپرسید متن خوانا کجا ساخته می‌شود، چه کسی به کلید محتوا دسترسی دارد و دستگاه تازه چگونه وارد گفتگو می‌شود. رمزکردن پایگاه داده و ارتباط شبکه کنترل‌های مفیدی‌اند، اما وقتی سرویس کلید خواندن پیام را دارد، جای رمزگذاری سرتاسری را نمی‌گیرند.
کلید، هویت و مسیر یک پیام
مسیر ساده‌شده چنین است: هویت دستگاه گیرنده بررسی می‌شود، دو طرف راز مشترک را برقرار یا نوسازی می‌کنند، کلید پیام مشتق می‌شود، محتوا با رمزنگاری احرازشده بسته می‌شود و متن رمز تحویل می‌گردد. احراز متن رمز، دستکاری دادهٔ محافظت‌شده را آشکار میکند؛ اما به‌تنهایی ثابت نمی‌کند کلید عمومی واقعاً متعلق به همان شخص است.
برای تأیید هویت، شمارهٔ ایمنی یا اثرانگشت کلید را از راهی مستقل و مورد اعتماد با مخاطب مقایسه کنید، به‌خصوص پس از تغییر کلید. نام و تصویر آشنا شاهد رمزنگارانه نیستند. هنگام تعویض دستگاه نیز باید روشن باشد کدام تاریخچه و کلیدها قابل بازیابی‌اند و کدام پیام‌ها دیگر باز نمی‌شوند.
مرز حفاظت: فراداده، دستگاه و نوع گفتگو
رمزنگاری سرتاسری از محتوای یک نوع گفتگوی مشخص حفاظت میکند؛ لزوماً اتصال حساب، طرف‌های ارتباط، زمان تحویل یا اندازهٔ تقریبی متن رمز را پنهان نمی‌کند. دستگاه باز یا آلوده می‌تواند محتوای رمزگشایی‌شده را آشکار کند و گیرنده هم می‌تواند آنچه را دریافت کرده کپی کند.
پیام مستقیم، گروه خصوصی، کانال عمومی، تماس، ضبط، پشتیبان، جستجو و اعلان را جداگانه بررسی کنید. یک نشان «رمزنگاری‌شده» برای همهٔ این حالت‌ها کافی نیست. در مستندات لیوارا چت، LVR1 برای محتوای مستقیم و LGS1 برای گروه خصوصی سازگار شرح داده شده است؛ محتوای کانال عمومی برای سرور خواناست. ضبط اختیاری سرور نیز مرز تماس را تغییر می‌دهد و حالت جداگانه‌ای دارد.
ML-KEM-768 چه نقشی دارد و چه چیزی را ثابت نمی‌کند؟
ML-KEM-768 سازوکاری استاندارد برای برقراری کلید مشترک است، نه نام الگوریتم رمزکردن همهٔ پیام. در طرح منتشرشدهٔ پیام مستقیم لیوارا چت، سهم آن در LVR1 با مادهٔ کلید کلاسیک P-256 ترکیب می‌شود. هدف از ترکیب، وابسته‌نبودن به تنها یک خانواده از فرض‌های برقراری کلید است؛ درستی اتصال هویت، نگهداری کلید، پیاده‌سازی و امنیت دستگاه همچنان ضروری‌اند.
نام یک استاندارد، گواهی امنیت برنامه نیست. مشخصات پروتکل، نسخهٔ منتشرشده، رفتار بازیابی و وضعیت بازبینی مستقل را جدا بررسی کنید. این صفحات ادعای ممیزی مستقل امنیت محصول ندارند.
منابع و مطالعه بیشتر
پرسش‌های رایج
آیا HTTPS همان رمزنگاری سرتاسری است؟
خیر. HTTPS مسیر تا سرور را محافظت میکند. در رمزنگاری سرتاسری، کلید خواندن محتوای پیام نزد دستگاههای شرکتکنندگان مورد نظر میماند.
آیا رمزگذاری سرتاسری فراداده را هم پنهان میکند؟
لزومی ندارد. حساب، مسیریابی، عضویت، زمان و اندازهٔ متن رمز می‌توانند برای سرویس قابل مشاهده بمانند.
پس از تغییر دستگاه مخاطب چه باید کرد؟
هشدار تغییر کلید را بررسی کنید، اثرانگشت جدید را از مسیر مستقل با مخاطب بسنجید و رفتار بازیابی تاریخچه را بخوانید.