کلید مخصوص یک فایل، به معنی مشاهده یک‌باره یا پس‌گرفتن نسخه گیرنده نیست.
برای محافظت از یک پیوست، پیام‌رسان می‌تواند فایل را روی دستگاه فرستنده با کلیدی تصادفی رمز کند، نسخه رمز‌شده را بارگذاری کند و کلید فایل را داخل پیام سرتاسری رمزنگاری‌شده به گیرنده برساند. به این الگو گاهی رمزنگاری پاکتی گفته می‌شود: فایل بزرگ و اطلاعات کوچکِ لازم برای بازکردن آن، مسیرهای متفاوت اما مرتبط دارند.
این توضیح درباره پیوست در گفت‌وگوی دارای E2EE است؛ ارسال فایل در هر برنامه یا هر نوع کانال الزاماً همین حفاظت را ندارد.
مسیر یک عکس خصوصی از دستگاه تا گیرنده
- دستگاه فرستنده برای فایل، کلید محتوا تولید می‌کند.
- فایل با رمزنگاری احرازشده رمز می‌شود؛ گیرنده باید تغییر غیرمجاز در داده را تشخیص دهد.
- نسخه رمز‌شده روی سرویس ذخیره فایل قرار می‌گیرد.
- نشانی یا شناسه فایل و کلید لازم در پیام محافظت‌شده برای گیرنده فرستاده می‌شود.
- دستگاه گیرنده فایل را دریافت، اعتبارسنجی و سپس باز می‌کند.
مستندات امنیت لیوارا برای پیوست‌ها کلید تصادفیِ مخصوص فایل و انتقال آن در نشست پیام را توصیف می‌کند. این مقاله آن معماری اعلام‌شده را توضیح می‌دهد، نه نتیجه ممیزی پیاده‌سازی را.
«کلید مخصوص فایل» با «فایل فقط یک‌بار باز می‌شود» فرق دارد
کلیدی که برای یک فایل تولید می‌شود ممکن است برای چند بار خواندن همان فایل لازم باشد. اختصاصی‌بودن کلید به معنی دور انداختن فوری آن پس از اولین مشاهده، حذف خودکار فایل یا جلوگیری از ذخیره توسط گیرنده نیست.
همچنین یک‌بارمصرف‌بودن کلید پیام و استفاده از کلید محتوا برای یک پیوست دو مفهوم متفاوت‌اند. نباید ویژگی‌هایی مانند View Once یا پیام ناپدیدشونده را صرفاً از نام الگوریتم نتیجه گرفت.
چرا کلید و nonce هر دو اهمیت دارند؟
AES-GCM علاوه بر محرمانگی، بررسی اصالت داده را فراهم می‌کند؛ اما استفاده درست از آن ضروری است. استاندارد NIST SP 800-38D قواعد GCM را شرح می‌دهد. تکرار ترکیب کلید و nonce برای داده‌های متفاوت می‌تواند امنیت را به خطر بیندازد.
برای کاربر، نتیجه عملی این است: عبارت «AES-256» به‌تنهایی کافی نیست. مشخصات مدیریت کلید، تولید تصادفی، اعتبارسنجی فایل و رسیدگی به خطا نیز باید بررسی شوند. تغییر یک بایت باید به رد فایل نامعتبر منجر شود، نه نمایش محتوای دستکاری‌شده به‌عنوان فایل سالم.
گیرنده، سرور و برنامه گالری چه می‌بینند؟
| محل | پرسش امنیتی |
|---|---|
| سرویس ذخیره فایل | آیا فقط بایت‌های رمز‌شده دارد یا کلید هم در دسترس آن است؟ |
| پیام حاوی کلید | آیا کلید، نام فایل و توضیح آن در گفتگوی E2EE محافظت می‌شوند؟ |
| دستگاه گیرنده | فایل پس از بازشدن در حافظه، کش یا گالری کجا می‌ماند؟ |
| پشتیبان ابری | آیا نسخه ذخیره‌شده وارد پشتیبان عکس‌ها می‌شود و آن پشتیبان چه حفاظتی دارد؟ |
رمزنگاری حین انتقال، نسخه‌ای را که گیرنده در گالری ذخیره می‌کند کنترل نمی‌کند. پیش از ارسال مدرک حساس، بخش‌های غیرضروری تصویر، نوشته‌های پس‌زمینه و اطلاعات مکانی فایل را نیز بررسی کنید.
فایل در گروه خصوصی چه تفاوتی دارد؟
تعداد دارندگان مجاز کلید بیشتر می‌شود. لیوارا پوشش پیوست گروه خصوصیِ سازگار در حالت E2EE را در LGS1 توضیح می‌دهد؛ این ادعا را نباید به کانال عمومی تعمیم داد. هر عضوی که فایل را دریافت کرده ممکن است نسخه‌ای نگه دارد. حذف عضو یا چرخش کلید آینده، نسخه قبلی او را پس نمی‌گیرد.
چک‌لیست ارسال فایل حساس
- فضای گفتگو و مخاطبان را دوباره بررسی کنید.
- اگر هویت مخاطب مهم است، اثر انگشت کلید را از مسیر مورد اعتماد تأیید کنید.
- فقط اطلاعات لازم را بفرستید؛ عکس کامل یک سند همیشه لازم نیست.
- درباره ذخیره در گالری، دانلود خودکار و پشتیبان ابری با گیرنده هماهنگ شوید.
- فایل رمزگشایی‌شده را روی دستگاه مشترک یا بدون قفل رها نکنید.
پرسش‌های رایج
آیا کلید مخصوص فایل، ارسال را تضمین‌شده امن می‌کند؟
خیر. سلامت دستگاه‌ها، احراز هویت گیرنده و پیاده‌سازی درست نیز لازم‌اند. مدل تهدید لیوارا را همراه با مشخصات رمزنگاری بخوانید.
آیا تصویر کانال عمومی همان حفاظت را دارد؟
طبق مرز اعلام‌شده لیوارا، کانال‌ها عمومی و قابل خواندن‌اند؛ برای آن‌ها وعده محرمانگی پیوست خصوصی داده نمی‌شود.
آیا لینک فایل به‌تنهایی کافی است؟
به طراحی سرویس بستگی دارد. لینک، کلید و مجوز دسترسی را جداگانه بررسی کنید؛ صرف طولانی یا تصادفی‌بودن یک URL اثبات E2EE نیست.
