⇌Relayium

الأمان ونموذج التهديد

آخر تحديث: 2026-07-01

صُمِّمت Relayium بحيث يكون مَن ينقلون الملفات — لا الخادم — هم مَن يملكون المفاتيح. تصف هذه الصفحة بدقة ما هو محميّ، وكيف يعمل، وحدود تلك الحماية.

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

التشفير من الطرف إلى الطرف (X25519 + AES-256-GCM)

تُولِّد كل عملية نقل زوج مفاتيح X25519 جديدًا ومؤقتًا على كل جهاز. ويُجري الجهازان تبادلًا للمفاتيح لاشتقاق مفتاح AES-256-GCM مشترك لا يوجد إلا داخل المتصفحين. وتُشفَّر كل كتلة بذلك المفتاح مع قيمة عشوائية فريدة (nonce)، بحيث لا يرى خادم الإشارة — وأي مُرحِّل — سوى النص المُشفَّر على الدوام.

• المفاتيح مؤقتة وخاصة بكل عملية نقل — ولا يُعاد استخدام أي شيء عبر الجلسات.
• يُشتَقّ المفتاح المشترك على الجهازين؛ ولا يُرسَل أبدًا إلى أي خادم ولا يُخزَّن عليه.
• يُطبَّق التشفير في طبقة التطبيق، فوق أمان النقل الخاص بـ WebRTC، فيظل صامدًا حتى لو تعرّضت طبقة النقل للاختراق.

رمز التحقق (SAS) — اكتشاف خادم خبيث

يتبادل التشفير المدمج في WebRTC (DTLS) بصمات المفاتيح عبر خادم الإشارة، لذا يمكن لخادم غير أمين أن يتوسّط في المنتصف ويبدّل المفاتيح. ولرصد ذلك، تشتقّ Relayium سلسلة مصادقة قصيرة (SAS) من 6 أرقام من المفاتيح العامة للطرفين وتعرضها على كلتا الشاشتين. فإذا تطابق الرمزان، فهذا يعني أن تبادل المفاتيح لم يُعبَث به ولم يبدّل أحد مفتاحًا في أثنائه.

يمكن من حيث المبدأ كسر رمز بسيط من 6 أرقام (نحو 20 بت) بالقوة الغاشمة من قِبل مُرحِّل يسابق الزمن لفرض رمز مُطابِق. تسدّ Relayium هذه الثغرة بمصافحة «الالتزام ثم الكشف»: يلتزم كل طرف أولًا بمفتاحه بإرسال تجزئة له، ولا يكشف المفتاح إلا بعد تلقّي التزام الطرف الآخر. ومن ثمّ لا يستطيع الخادم انتقاء مفتاح مُتصادِم بعد الأمر، فيبقى الرمز القصير جديرًا بالثقة.

• للحصول على أقوى ضمان، قارِن الرمز عبر قناة خارجية — وجهًا لوجه أو عبر مكالمة صوتية.
• إذا اختلف الرمزان، فأوقِف النقل: قد يكون أحدهم يعترض الاتصال.

ما لا يراه الخادم أبدًا

صُمِّمت الخدمة بحيث لا يصل ما يلي مطلقًا إلى خوادمنا، في أي وضع:

في الوضع الفوري لا تمسّ بايتات الملف الخادم إطلاقًا على نفس الشبكة — بل تتدفق مباشرةً بين الجهازين؛ أما عبر الشبكات فتمرّ عبر مُرحِّل TURN الموصوف أدناه، وهو ينقل نصًا مُشفَّرًا ولا يملك أي مفتاح. ولا يقوم خادم الإشارة إلا بتمرير رسائل إعداد الاتصال، ويرى عضوية الغرفة (عنوان IP العام الخاص بك)، واسمًا مستعارًا للجهاز تختاره أنت، والحضور.

• محتويات ملفاتك.
• أسماء ملفاتك.
• مفاتيح التشفير الخاصة بك.

عندما تُرحَّل ملفاتك (TURN)

تمرّ عمليات النقل عبر الشبكات في المتصفح — أي جلسات رمز الاقتران، بما في ذلك روابط الانضمام الخاصة بها — عبر خادم TURN بحكم التصميم، لا كخيار احتياطي. فأنظمة NAT المُقيِّدة وجدران الحماية تجعل المسار المباشر الحقيقي مستبعدًا هناك، لذا يفرض التطبيق مسار الترحيل من البداية بدل إنفاق نحو عشرين ثانية على فحص مرشّحين مباشرين ينتهي وقتهم غالبًا لينتهي الأمر عند المُرحِّل نفسه على أي حال. أما جلسات نفس الشبكة فلا تُصدَر لها بيانات اعتماد ترحيل إطلاقًا وتتصل مباشرةً؛ كما أن واجهة سطر الأوامر لا تُرحِّل بايتات الملفات أبدًا — فنقلها عبر الشبكات مباشر فقط ويفشل إن لم يُعثر على مسار مباشر.

• لا ينقل المُرحِّل سوى النص المُشفَّر — ولا يمكنه قراءة ملفاتك، التي تظل مُشفَّرة من الطرف إلى الطرف.
• نسجّل عدد البايتات المُرحَّلة لكل حساب لفرض حصة ترحيل شهرية ومنع إساءة الاستخدام — ولا نفحص أبدًا ما يُرحَّل، بل نسجّل عدد البايتات فقط.
• لا نفحص أبدًا المحتوى المُرحَّل.

روابط التنزيل المُخزَّنة — المفتاح لا يغادر متصفحك أبدًا

وضع رابط التنزيل الاختياري مُخصَّص لما يكون فيه المُستقبِل غير متصل. يُشفِّر متصفحك الملفات باستخدام AES-256-GCM قبل رفع أي شيء، ويوضَع مفتاح فك التشفير في جزء URL فقط — الجزء الذي يلي # — وهو ما لا ترسله المتصفحات أبدًا إلى الخادم.

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

سلامة الملفات (SHA-256)

إلى جانب السرية، يُتحقَّق من سلامة كل ملف. تحمل كل كتلة وسم مصادقة AES-GCM، ويُتحقَّق من تجزئة SHA-256 لكل ملف من الطرف إلى الطرف على جانب المُستقبِل، بحيث يُكتشَف الملف التالف أو المُتلاعَب به بدلًا من قبوله بصمت.

ما لا تحمي منه Relayium

يحمي التشفير من الطرف إلى الطرف البيانات أثناء انتقالها بين طرفين أمينين. ولا يمكنه، بحكم التصميم، أن يحمي من:

• جهاز أو متصفح مُخترَق على أي من الطرفين — برمجية خبيثة، أو امتداد متصفح عدائي، أو شخص يقرأ الشاشة.
• البيانات الوصفية التي يتعامل معها الخادم بالضرورة: أن عملية نقل قد حدثت، وحجمها وتوقيتها، و — في حالة رابط تنزيل مُخزَّن أو نقل عبر الشبكات برمز اقتران — الحساب الذي أنشأها أو أرسلها.
• اختيار المُستقبِل الاحتفاظ بالملفات أو إعادة توجيهها بعد أن يتلقّاها.
• مشاركة رابط تنزيل عبر قناة غير موثوقة، إذ إن مفتاح فك التشفير ينتقل داخل الرابط.

دعم المتصفحات وحدوده

تعمل Relayium في أي متصفح حديث يدعم WebRTC عبر HTTPS. وتختلف بعض القدرات باختلاف المتصفح:

• يتوفّر في Chrome وEdge على سطح المكتب واجهة File System Access، فيبثّان الملفات الكبيرة مباشرةً إلى القرص، دون سقف عملي للذاكرة.
• أما Firefox وSafari وجميع متصفحات الهاتف (فكل متصفح على iOS يعمل بـ WebKit) فتفتقر إلى تلك الواجهة وتجمّع الملف في الذاكرة على المسار الفوري، ولذلك يحذّر التطبيق مسبقًا عند تجاوز نحو 256 MB — وهو تقدير متحفّظ عن قصد، لا حدّ مقيس. لملفات بهذا الحجم فضّل Chrome/Edge على سطح المكتب، أو استخدم وضع رابط التنزيل، الذي يمكن لصفحة التنزيل فيه أيضًا الكتابة إلى القرص عبر service worker.
• يتطلب WebRTC سياقًا آمنًا (HTTPS)؛ ولن يتصل التطبيق عبر HTTP العادي.

المصدر المفتوح والإبلاغ عن المشكلات

تصميم البروتوكول وكامل شِفرة العميل والخادم متاحة للعموم على GitHub، بحيث يستطيع أي شخص تدقيق التشفير، أو تشغيل خادمه الخاص، أو المساهمة. وإذا اكتشفت مشكلة أمنية، فيُرجى الإبلاغ عنها بصورة خاصة عبر آلية الإبلاغ عن الثغرات في GitHub على المستودع، بدلًا من فتح مشكلة عامة.