آخر تحديث: 2026-07-09
«هل Relayium آمن؟» سؤال وجيه — فكل أداة لنقل الملفات تدّعي أنها تحمي الخصوصية. تشرح هذه الصفحة بلغة بسيطة كيف يحافظ Relayium على خصوصية ملفاتك بالضبط، حتى تحكم على هذا الادّعاء بنفسك بدلًا من تصديقه على عِلّاته.
هناك نظامان مختلفان للتشفير يعملان هنا، لأن هناك موقفين مختلفين: إرسال ملف بشكل فوري إلى شخص متصل بالإنترنت الآن، وترك رابط تنزيل ليأخذه شخص ما لاحقًا. كلاهما يُبقي الخادم بعيدًا عن ملفك، لكنهما يصلان إلى ذلك بطرق مختلفة — ومن المفيد أن تعرف أيّهما ينطبق ومتى.
عندما ترسل ملفًا بشكل فوري — وكلا الطرفين متصل، من متصفح إلى متصفح — يبدأ Relayium بجعل كل جهاز يولّد زوج مفاتيح جديدًا باستخدام X25519، وهو نفس تبادل المفاتيح القائم على المنحنيات الإهليلجية المُستخدَم في المراسلة الآمنة الحديثة (تقنيًا، crypto_kx من libsodium). يحتفظ كل جهاز بمفتاحه الخاص لنفسه ويرسل مفتاحه العام فقط إلى الطرف الآخر.
من هذين المفتاحين العامّين، يحسب كل جهاز بشكل مستقل السرَّ المشترك نفسه — وهي عملية تنجح تحديدًا بسبب طريقة بناء تبادل المفاتيح القائم على المنحنيات الإهليلجية، لا لأن السرّ أُرسِل إلى أي مكان. يصبح ذلك السرُّ المشترك مفتاح AES-256-GCM موجودًا فقط داخل المتصفحَين. تُختَم كل كتلة من الملف بهذا المفتاح وبرقم عشوائي فريد (nonce) قبل أن يغادر جهاز المُرسِل أصلًا، بحيث لا يرى أيُّ شيء يعبر الشبكة — بما في ذلك خادم الإشارة الذي ساعد المتصفحَين على إيجاد أحدهما الآخر — سوى النص المُشفَّر.
هناك دقيقة تستحق الصراحة بشأنها. يتبادل التشفير المدمج في WebRTC (DTLS) بصمات المفاتيح عبر خادم الإشارة الذي يُعرّف الجهازين أحدهما بالآخر. لو كان ذلك الخادم غير نزيه، لأمكنه نظريًا أن يتوسّط ويستبدل مفاتيحه الخاصة — هجوم وسيط كلاسيكي — دون أن يلاحظ أيٌّ من المتصفحَين ذلك فورًا.
يسدّ Relayium هذه الثغرة برمز تحقق قصير. يشتقّ كلا الجهازين نفس سلسلة المصادقة القصيرة (SAS) المكوَّنة من ست خانات من مفتاحيهما العامّين ويعرضانها على الشاشة. إذا تطابق الرمزان، فالمفاتيح لم تُستبدَل، ولا أحد في المنتصف. لكن الرمز البسيط المكوَّن من ست خانات لا يتجاوز نحو 20 بت، وهو ما قد يحاول مهاجم في موقع مناسب مبدئيًا أن يخمّنه بالقوة الغاشمة ليطابقه بعد رؤية المفتاحين الحقيقيين. لمنع ذلك، يستخدم Relayium مصافحة «الالتزام ثم الكشف»: يرسل كل طرف أولًا تجزئة (hash) تلتزم بمفتاحه، ولا يكشف عن المفتاح الحقيقي إلا بعد تلقّي التزام الطرف الآخر. يعني هذا الترتيب أن الخادم الخبيث عليه أن يلتزم بمفتاح مزيّف على العمياء، قبل أن يكون قد رأى المفتاح الحقيقي — فلا يستطيع اختيار مفتاح متصادم بعد وقوع الأمر، وهكذا يبقى الرمز القصير جديرًا بالثقة.
يحمي التشفير السرية، لكنه لا يُثبِت تلقائيًا أن شيئًا لم يتلف أو يُعبَث به في الطريق. يتحقق Relayium من ذلك على حدة: تحمل كل كتلة وسم مصادقة AES-GCM الخاص بها، فيفشل فك تشفير أي كتلة مُعدَّلة من الأساس. علاوة على ذلك، مع إرسال كل ملف، يحسب الطرفان تجزئة SHA-256 جارية على محتواه الصريح؛ وعند انتهاء الملف، تُقارَن تجزئة المُرسِل بتجزئة المُستقبِل. إذا تطابقتا، فما استقرّ على القرص مطابق بايتًا ببايت لما أُرسِل — وإن لم تتطابقا، يُوسَم الملف بدلًا من قبوله بصمت.
يحتاج النقل الفوري إلى وجود الطرفين متصلَين في الوقت نفسه. حين يتعذّر ذلك، يقدّم Relayium بدلًا منه رابط تنزيل مُخزَّن — وهذا يستخدم آلية مختلفة فعلًا، يُستحسَن عدم الخلط بينها وبين آلية النقل الفوري أعلاه.
لا يوجد هنا تبادل مفاتيح، لأنه لا يوجد بعدُ جهاز ثانٍ للتبادل معه. بدلًا من ذلك، يولّد متصفحك مفتاح AES-256-GCM عشوائيًا واحدًا ويستخدمه لتشفير الملفات قبل رفع أي شيء. لا يُرسَل هذا المفتاح إلى الخادم إطلاقًا — بل يُلحَق برابط التنزيل بعد الرمز #، فيما يُسمّى جزء العنوان (URL fragment)، وهو جزء من العنوان تتعمّد المتصفحات ألّا ترسله إلى أي خادم أبدًا. ينتهي الأمر بالخادم مُخزِّنًا نصًا مُشفَّرًا فقط لا سبيل له إلى فك تشفيره، إضافة إلى بيانات إدارية مثل حجم النص المُشفَّر وطابع زمني لانتهاء الصلاحية. أي شخص يفتح الرابط الكامل — بما فيه الجزء — يستطيع فك تشفير الملف محليًا في متصفحه؛ ومن لا يملكه لا يرى سوى كتلة مبهمة على الخادم. هذا هو جزء المعرفة الصفرية: يحتفظ الخادم بالملف المُشفَّر دون أن يملك يومًا وسيلة قراءته.
من المفيد أن نوضّح بالضبط أين يقف الخادم من كل هذا، لأن «التشفير من الطرف إلى الطرف» ادّعاء يسهل قوله ويصعب قوله بدقة. في الوضع الفوري على نفس الشبكة، لا يلمس الملف نفسه خوادم Relayium إطلاقًا — بل يُبَثّ مباشرة بين المتصفحَين. تقتصر مهمة خادم الإشارة على تمرير رسائل إعداد الاتصال (معلومات SDP/ICE التقنية التي يحتاجها WebRTC لإنشاء رابط مباشر) حتى يتمكن الجهازان من إيجاد أحدهما الآخر؛ فهو لا يرى أبدًا محتوى الملفات أو أسماءها أو المفاتيح.
عبر الشبكات — حيث تستبعد أنظمة NAT وجدران الحماية المقيِّدة المسار المباشر في الغالب — يمرّ التدفق المُشفَّر على خادم مُرحِّل TURN. لا يمرّر المُرحِّل سوى النص المُشفَّر؛ فليس لديه مفتاح ولا يمكنه فك تشفير ما يمرّ عبره. أما ما يفعله فهو عدّ البايتات التي يُرحّلها ضمن حصة الترحيل الشهرية لحساب المُرسِل، لغرض القياس ومنع إساءة الاستخدام فقط — دون أن يفحص ما بداخلها أبدًا.
لا. في الوضع الفوري، يُشتَقّ مفتاح التشفير بشكل مستقل على كلا الجهازين ولا يغادرهما أبدًا — ولا ترى خوادم Relayium المفتاح ولا محتوى الملفات. أما بالنسبة للروابط المُخزَّنة، فيوجد المفتاح فقط في جزء العنوان (URL fragment)، الذي لا ترسله المتصفحات إلى أي خادم أبدًا، لذا لا يحتفظ الخادم إلا بنص مُشفَّر لا يستطيع فك تشفيره.
في الوضع الفوري على نفس الشبكة، لا يرى سوى معلومات إعداد الاتصال اللازمة لتعريف الجهازين أحدهما بالآخر — ولا يرى بايتات الملف أبدًا. أما عبر الشبكات فيَنقل مُرحِّل TURN بايتات الملف فعلًا، لكن كنص مُشفَّر لا يملك مفتاحه. أما بالنسبة للروابط المُخزَّنة، فيرى النص المُشفَّر إضافة إلى بيانات إدارية مثل الحجم ووقت انتهاء الصلاحية — دون أن يرى النص الصريح أو أسماء الملفات أو مفتاح فك التشفير أبدًا.
في المتصفح يحمل بحكم التصميم كل عمليات النقل عبر الشبكات، لا تلك التي فشل فيها المسار المباشر فحسب — لكنه لا يتعامل إلا مع النص المُشفَّر، وليس لديه مفتاح، ولذلك لا يستطيع قراءة ما يُرحّله. يَعُدّ Relayium البايتات التي يُرحّلها ضمن الحصة الشهرية لحسابك، لكنه لا يفحص محتواها أبدًا.
نعم. تصميم البروتوكول وكامل شيفرة العميل والخادم متاحة علنًا على GitHub بموجب رخصة AGPL-3.0، لذا يمكن تدقيق التعمية الموصوفة هنا بشكل مستقل بدلًا من تصديقها على عِلّاتها.
أوقِف النقل. عدم التطابق يعني أن فحص «الالتزام ثم الكشف» قد فشل، وهو ما يشير إلى احتمال وجود وسيط لا إلى خلل بسيط غير مؤذٍ — لا تُكمِل حتى تفهم السبب.
أتتساءل كيف يبدو الأمر عمليًا؟ ابدأ عملية نقل وشاهد رمز التحقق يظهر بنفسك.
جرّب Relayium الآن