كيف يعمل التشفير من طرف إلى طرف في نقل الملفات

التشفير من طرف إلى طرف في نقل الملفات يعني أن البايتات الخارجة من جهازك مُشفَّرة بمفتاح لا يلمس الخادم قط، ولا يستطيع فك تشفيرها إلا المستقبِل المقصود. يُخزِّن الخادم نصًّا مُشفَّرًا ولا يرى شيئًا ذا معنى، ويمكن اختراقه دون كشف محتويات ملفك. الوصفة التشفيرية تستخدم دائمًا خوارزمية تماثلية كـAES-256-GCM أو XChaCha20-Poly1305 للملف ذاته، مُغلَّفة بتبادل مفاتيح كـX25519 ECDH أو RSA-OAEP 2048/4096 لمادة المفتاح. إليك تفصيل ذلك عمليًا.

نموذج التهديد الذي يدافع عنه E2EE فعلًا

E2EE يدافع تحديدًا ضد: اختراق مزود النقل أو استدعائه قضائيًا أو كونه خبيثًا؛ ومهاجمي الشبكة الذين يعترضون حركة TLS المفككة عند الوسطاء؛ ولقطات النسخ الاحتياطي لحاوية التخزين التي تقع في أيدٍ خاطئة؛ والوصول الداخلي من موظفي الخدمة. لا يدافع ضد: البرمجيات الخبيثة على جهاز المُرسِل أو المستقبِل، أو التصيد الذي يلتقط رابط فك التشفير، أو حسابات المستقبِل المُخترَقة. فهم النموذج مهم، لأن كلمة "مُشفَّر" كثيرًا ما تُساء استخدامها بمعنى "TLS أثناء النقل زائد AES في حالة السكون على الخادم"، مما يُبقي المزود حاملًا للمفاتيح.

التشفير المتماثل لحمولة الملف

الملفات تُشفَّر بخوارزمية متماثلة لأن التشفير بالمفتاح العام بطيء جدًا للبيانات الضخمة. الخيار الحديث هو AES-256-GCM المعرَّف في NIST SP 800-38D، يوفر السرية والتكامل المُصادَق في تمريرة واحدة. مفتاح عشوائي 256-بت ونونس فريد 96-بت (لا يُعاد استخدامه مع المفتاح ذاته) يحميان كل ملف. XChaCha20-Poly1305 المعرَّف في RFC 8439 وRFC 8103 بديل سريع على الأجهزة التي تفتقر إلى تسريع AES-NI، كمعالجات ARM الأقدم. كلاهما يُنتج نصًّا مُشفَّرًا زائد وسم مصادقة 128-بت يكتشف أي تلاعب.

اشتقاق المفتاح من كلمات المرور

حين يستخدم E2EE كلمة مرور، لا تكون كلمة المرور ذاتها هي مفتاح التشفير — هذا ضعيف جدًا أمام هجمات القوة الغاشمة. بدلًا من ذلك، دالة اشتقاق مفتاح كـPBKDF2-HMAC-SHA256 بـ600,000 تكرار أو أكثر (إرشادات OWASP 2025)، أو Argon2id بـm=19 MiB وt=2 (RFC 9106)، أو scrypt (RFC 7914) تمد كلمة المرور في مفتاح قوي. ملح عشوائي 128-بت أو 256-بت يمنع هجمات جداول قوس قزح. المفتاح الناتج يُشفِّر الملف. يُخزَّن الملح وعدد التكرارات مع النص المُشفَّر حتى يستطيع المستقبِل إعادة بناء المفتاح عند إدخال كلمة المرور.

تغليف بالمفتاح العام للنقل القائم على الحسابات

حين يمتلك المستقبِلون حسابات بمفاتيح عامة منشورة، لا حاجة لإدخال كلمة مرور. يُولِّد المُرسِل مفتاح تشفير ملف عشوائيًا (FEK)، يُشفِّر الملف بـAES-256-GCM باستخدام FEK، ثم يُشفِّر FEK إلى كل مفتاح عام لمستقبِل عبر اتفاق مفتاح X25519 ECDH بموجب RFC 7748 مقترنًا بـHKDF-SHA256 بموجب RFC 5869 لاشتقاق مفتاح التغليف، أو RSA-OAEP بموجب PKCS#1 v2.2 مع SHA-256. يجلس FEK المُغلَّف جانب النص المُشفَّر. فقط حامل المفتاح الخاص للمستقبِل يستطيع فك تغليف FEK وفك تشفير الملف. هذا نموذج Signal وWhatsApp للرسائل، مُكيَّف لحمولات الملفات.

E2EE القائم على الروابط باستخدام أجزاء URL

حيلة ذكية في النقل عبر المتصفح: تخزين مفتاح فك التشفير في جزء URL (الجزء بعد #). الأجزاء لا تُرسَل إلى الخادم أبدًا في طلب HTTP. رابط كـhttps://example.com/d/abc123#k=B9kZtR... يحمل معرّف الملف من جانب الخادم والمفتاح من جانب العميل. يُنزِّل المتصفح النص المُشفَّر ويقرأ الجزء في JavaScript ويُفكِّك التشفير محليًا. لا ترى الخدمة المفتاح. أدوات كـFirefox Send (متوقف الآن) وSend عبر ownCloud تستخدم هذا النمط. التحفظ: إذا تسرَّب الرابط — في السجلات أو لقطات الشاشة أو معاينات تطبيقات المراسلة — يتسرَّب المفتاح معه.

التكامل مع AEAD والهاشات

أوضاع التشفير المُصادَق بالبيانات المرتبطة (AEAD) كـGCM وChaCha20-Poly1305 تمنع التلاعب. قلب بت واحد في النص المُشفَّر يُفشل التحقق من وسم المصادقة، وتُعيد دالة فك التشفير خطأً بدلًا من نص خام فاسد. فوق AEAD، تحسب تطبيقات كثيرة هاش SHA-256 أو BLAKE3 للنص الأصلي كإدخال في البيان حتى يستطيع المستقبِل التحقق بعد فك التشفير من مطابقة الملف لما أرسله المُرسِل. هذا مهم للملفات الكبيرة المُنقَلة في أجزاء، حيث قد ينجح تسليم جزئي في أجزاء ويفشل صامتًا عند ذيل مفقود.

التشفير المجزَّأ للملفات الكبيرة

تشفير ملف 10 جيجابايت في عملية AES-GCM واحدة يتطلب الاحتفاظ بـ10 جيجابايت من الحالة، وهذا غير عملي في المتصفحات. التطبيقات الحقيقية تقسم الملف إلى أجزاء، عادةً 1 إلى 16 ميجابايت كلٌّ منها، وتُشفِّر كل جزء باستقلالية بمفتاح فرعي مشتق ونونس قائم على عداد. أداة التشفير age المعرَّفة على age-encryption.org تستخدم أجزاء 64 كيلوبايت مع ChaCha20-Poly1305. بروتوكول Magic Wormhole يستخدم إنشاء تدفق. حدود الأجزاء أيضًا تُتيح للمتصفحات دفق فك التشفير عبر Streams API — بدء التنزيل إلى القرص قبل وصول الملف كاملًا — ودعم الرفعات القابلة للاستئناف عند انقطاع الشبكة.

أمان النقل فوق E2EE

TLS 1.3 المعرَّف في RFC 8446 لا يزال مهمًا فوق E2EE، ليس لسرية الحمولة (الحمولة مُشفَّرة أصلًا)، بل لخصوصية البيانات الوصفية: أسماء الملفات والأحجام والتوقيت. TLS 1.3 مع تبادل مفاتيح أمامي السرية كـX25519 يعني أنه حتى لو اختُرق المفتاح طويل العمر للخادم لاحقًا، لا يمكن فك تشفير الجلسات المُسجَّلة. تثبيت الشهادة أو HSTS preload يمنع هجمات التراجع. مجتمعَين، E2EE زائد TLS 1.3 يحمي محتويات الملف ونمط العمليات — من يرسل ماذا إلى من.

أخطاء شائعة في التطبيق

ثلاثة أخطاء تتكرر. أولًا، إعادة استخدام النونسات مع المفتاح ذاته في AES-GCM يُدمِّر السرية بشكل كارثي؛ استخدم دائمًا نونسًا عشوائيًا جديدًا أو عدادًا لا يُكرَّر. ثانيًا، تطبيق التشفير بروتينات منزلية بدلًا من مكتبات مُدقَّقة كـlibsodium أو Web Crypto API (SubtleCrypto) أو BoringSSL؛ العمليات في وقت ثابت ضرورية لمنع هجمات التوقيت. ثالثًا، عدم مصادقة البيانات الوصفية للملف مع المحتويات؛ إذا لم تكن هوية المُرسِل واسم الملف وقائمة المستقبِلين في AAD (البيانات المرتبطة المُصادَقة)، يستطيع مهاجم تبديل البيانات الوصفية دون كشف. HexaTransfer يعالج هذا باستخدام واجهات Web Crypto الأصيلة من جانب العميل بأنماط مُراجَعة.

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

اقرأ ادعاءات التسويق بتشكيك. E2EE الحقيقي يعني أن المزود لا يستطيع فك تشفير الملفات حتى بأمر قضائي. ابحث عن: وثائق تقنية منشورة تصف الخوارزميات الدقيقة (AES-256-GCM، X25519، HKDF، عدد تكرارات PBKDF2)، وكود عميل مفتوح المصدر قابل للتدقيق، ونموذج تهديد يعترف بما يدافع E2EE عنه وما لا يدافع. الخدمات التي تُتيح استرداد كلمة المرور من جانب الخادم للملفات المُشفَّرة لا تُطبِّق E2EE حقيقيًا — هي تحتفظ بالمفاتيح. الخدمات التي تدَّعي "عدم المعرفة" يجب أن تدعم ذلك بوصف بروتوكول تشفيري، لا بشعار وحسب.

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