شرح التشفير من طرف إلى طرف: دليل المبتدئين

التشفير من طرف إلى طرف (E2EE) يعني أن ملفك يُشفَّر على جهازك بمفتاح لا يستطيع استعادته إلا المستلم. تنقل خدمة النقل نصاً مشفّراً دون أن تحتفظ بمفتاح فكّ التشفير، فلا يستطيع الموظفون ولا المهاجمون ولا أوامر المحكمة قراءة المحتوى. عملياً، يُنشئ متصفحك مفتاح AES عشوائياً بطول 256 بتاً، يُشفّر الملف محلياً، يرفع النص المشفّر، ويضع المفتاح في رابط المشاركة بعد رمز # — وهو الجزء الذي لا يرسله المتصفح إلى الخادم أبداً. هذه هي الحيلة بأكملها، وهي ما يفصل الخصوصية الحقيقية عن الدعاية التسويقية.

ما الذي تعنيه "من طرف إلى طرف" فعلاً

الطرفان هما أنت والمستلم. كل شيء بينهما — أجهزة توجيه مزود الخدمة، وحواف شبكة CDN، وخوادم شركة النقل، ومزود خدمة المستلم — يقع في المنتصف. مع E2EE، لا يرى هؤلاء الوسطاء إلا بايتات مشفّرة. قارن هذا بتشفير طبقة النقل وحده (TLS): يحمي TLS البيانات من متصفحك إلى الخادم، ثم يفكّ الخادم تشفيرها، ويخزّن النص الصريح، ويعيد تشفيره عند تنزيل المستلم. هكذا تعمل الخطة المجانية في WeTransfer — تستطيع الشركة (وبموجب القانون الأمريكي والأوروبي يجب عليها أحياناً) تسليم الملفات عند الطلب.

مع E2EE، حتى لو سلّم المدعون العامون المزوّد أمر تفتيش، لا يملك المزوّد ما يسلّمه سوى بايتات تبدو عشوائية. لهذا يصرّ الصحفيون والمحامون والأطباء على استخدامها بصورة متزايدة.

لماذا TLS وحده لا يكفي

TLS 1.3 ممتاز في ما يفعله: منع مهاجم في مقهى أو مزوّد خدمة متمرّد من التنصّت على الاتصال. لكن TLS ينتهي عند الخادم. حالما ينتهي النفق المشفّر، يعالج الخادم الملف الخام. إذا اخترق أحدهم ذلك الخادم — كما حدث لـ Dropbox عام 2022 حين تسرّب رمز مصدري وبعض بيانات العملاء — فإن TLS لا يوفّر حماية للملفات المخزّنة.

يضيف E2EE طبقة ثانية تصمد أمام اختراق الخادم. يُشفَّر الملف قبل أن يصل إلى الشبكة ويبقى مشفّراً حتى يفكّ متصفح المستلم تشفيره. حتى تفريغ كامل قاعدة البيانات لا يكشف إلا عن نص مشفّر وبيانات وصفية.

مشكلة تبادل المفاتيح وحلّها

الجزء الأصعب في E2EE هو إيصال المفتاح إلى المستلم دون أن يراه الخادم. تحلّ الخدمات الحديثة المعتمدة على المتصفح هذه المعضلة بحيلة جزء URL. يبدو رابط المشاركة هكذا:

https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-key

يعامل المتصفح كل شيء بعد # على أنه جزء من جانب العميل. حين تنقر الرابط، يتلقى الخادم فقط /download/abc123 في طلب HTTP — ولا يغادر الجزء متصفحك. تقرأ JavaScript حينئذٍ المفتاح من الجزء وتمرّره إلى crypto.subtle.decrypt() في Web Crypto API.

هذا أبسط من تبادل مفاتيح RSA أو Diffie-Hellman ويعمل مع أي شخص لديه متصفح. الثمن: أي شخص يحصل على الرابط يحصل على الملف، لذا لا تزال بحاجة إلى مشاركة الروابط عبر قناة آمنة (Signal، شخصياً، أو بريد إلكتروني مشفّر).

ما يراه الخادم وما لا يراه

مع تطبيق E2EE السليم، تحتوي سجلّات الخادم عادةً على: معرّف ملف عشوائي، وحجم النص المشفّر، وعنوان IP الرفع، وختم وقته، وبصمة SHA-256 للنص المشفّر لأغراض إزالة التكرار. لا يرى الخادم: اسم الملف، ومحتواه، وهوية المستلم، ومفتاح فكّ التشفير. كثيراً ما تُشفَّر أسماء الملفات مع المحتوى وتُخزَّن كجزء من رأس النص المشفّر.

اختبار مفيد: اسأل المزوّد عمّا سيسلّمه في حال وُجّه إليه أمر قضائي. ستقول خدمة E2EE الصادقة: "كتل مشفّرة وسجلّات IP." إن كانت تستطيع تقديم ملفات بنص صريح، فالتشفير ليس من طرف إلى طرف.

الخوارزميات تحت الغطاء

تتقارب بُنى E2EE الحقيقية على قائمة قصيرة من العناصر الأساسية الموثوقة:

• AES-256-GCM لتشفير الملفات بالجملة. يوفّر GCM السرية والمصادقة معاً، فالنص المشفّر المعبث به يفشل في فكّ التشفير بدلاً من إنتاج بيانات غير منطقية.
• PBKDF2 بما لا يقلّ عن 100,000 تكرار، أو Argon2id، لاشتقاق المفاتيح من كلمات مرور المستخدمين حين تُضاف حماية بكلمة مرور.
• SHA-256 لبصمات النزاهة.
• TLS 1.3 كطبقة نقل خارجية، لأن الحزامين أفضل من حزام واحد.

تجنّب الخدمات التي لا تزال تستخدم AES-CBC بدون HMAC (قابل للتلاعب)، أو MD5 أو SHA-1 (مكسوران)، أو PBKDF2 بأقل من 10,000 تكرار (قابل للاختراق بالقوة على GPUs الحديثة).

E2EE لنقل الملفات مقابل المراسلة

شهّر Signal تشفير E2EE للمحادثات باستخدام بروتوكول Double Ratchet الذي يغيّر المفاتيح بعد كل رسالة لضمان السرية اللاحقة. لا يحتاج نقل الملفات هذا التعقيد لأنه عملية آنية — لا تحتاج إلى الحفاظ على محادثة مستمرة. مفتاح متماثل واحد لكل ملف، يُنشأ حديثاً لكل رفع، هو أبسط وأسهل في التدقيق.

ما يحتاجه نقل الملفات ولا تحتاجه المراسلة: رفع مقسّم قابل للاستئناف (قد تبلغ الملفات 10 جيجابايت)، والتحقّق من النزاهة عبر الأجزاء، وروابط تعمل دون أن يملك المستلم حساباً. تتبع Tresorit وProton Drive وSwissTransfer وHexaTransfer هذا النهج مع اختلافات بسيطة.

كيف تتحقّق أن الخدمة تطبّق E2EE فعلاً

أربعة اختبارات عملية قبل أن تثق بأي مزوّد:

1. افتح DevTools ثم Network أثناء رفع ملف صغير. إذا رأيت النص الصريح في جسم الطلب، فالتشفير ليس من جانب العميل.
2. ابحث عن المفتاح في جزء URL (بعد #). عدم وجود مفتاح في الجزء يعني عادةً أن الخادم يحتفظ بالمفتاح.
3. اقرأ سياسة الخصوصية بحثاً عن عبارة "لا نستطيع الوصول إلى ملفاتك" مقرونة بوصف تقني للسبب.
4. تحقّق مما إذا كان رمز العميل قابلاً للتدقيق — مفتوح المصدر أو موثّق على الأقل. الملفات التنفيذية المغلقة مع ادّعاءات E2EE تستحق التريّث.

الخدمات التي تجتاز الاختبارات الأربعة: SwissTransfer (مستوى التشفير من جانب العميل)، وTresorit Send، وProton Drive روابط المشاركة، وHexaTransfer.

ما لا يحميك منه E2EE

E2EE ليس سحراً. لا يحميك من:

• نقطة نهاية مخترقة. إن كان حاسوبك مصاباً ببرمجيات خبيثة، يقرأ المهاجم الملفات قبل التشفير.
• روابط مشاركة مسرّبة. أي شخص حصل على الرابط يستطيع التنزيل وفكّ التشفير.
• كلمات مرور ضعيفة على النقل المحمي. يُبطئ PBKDF2 هجمات القوة، لكن "summer2024" تسقط في ثوانٍ.
• ارتباط البيانات الوصفية. لا تزال التوقيتات وأحجام الملفات وعناوين IP قادرة على رواية قصة.

قرن E2EE بروابط منتهية الصلاحية (24 ساعة خيار معقول)، وحدود التنزيل (غالباً من 1 إلى 10 تنزيلات)، وكلمات مرور قوية للنقل الحساس.

تطبيق ذلك عملياً

لإجراء اختبار سريع: ارفع ملف اختبار بحجم 5 ميجابايت، افتح رابط المشاركة في نافذة خاصة دون الجزء (احذف كل شيء بعد #)، وحاول التنزيل. ستفشل خدمة E2EE الحقيقية في فكّ التشفير. إن فُتح الملف على أي حال، فالخادم كان يحتفظ بالمفتاح طوال الوقت.

جرّبها على hexatransfer.com — مجاني، بدون حساب، حتى 10 جيجابايت.