Relayium

كيف يُشفِّر Relayium ملفاتك من الطرف إلى الطرف

آخر تحديث: 2026-08-06

«هل Relayium آمن؟» سؤال وجيه — فكل أداة لنقل الملفات تدّعي أنها تحمي الخصوصية. تشرح هذه الصفحة بلغة بسيطة كيف يحافظ Relayium على خصوصية ملفاتك بالضبط، حتى تحكم على هذا الادّعاء بنفسك بدلًا من تصديقه على عِلّاته.

هناك نظامان مختلفان للتشفير يعملان هنا، لأن هناك موقفين مختلفين: إرسال ملف بشكل فوري إلى شخص متصل بالإنترنت الآن، وترك رابط تنزيل ليأخذه شخص ما لاحقًا. كلاهما يُبقي الخادم بعيدًا عن ملفك، لكنهما يصلان إلى ذلك بطرق مختلفة — ومن المفيد أن تعرف أيّهما ينطبق ومتى.

النقل الفوري: جهازان يتفقان على سِرٍّ لا يراه الخادم أبدًا

عندما ترسل ملفًا بشكل فوري — وكلا الطرفين متصل، من متصفح إلى متصفح — يبدأ Relayium بجعل كل جهاز يولّد زوج مفاتيح جديدًا باستخدام X25519، وهو نفس تبادل المفاتيح القائم على المنحنيات الإهليلجية المُستخدَم في المراسلة الآمنة الحديثة (تقنيًا، crypto_kx من libsodium). يحتفظ كل جهاز بمفتاحه الخاص لنفسه ويرسل مفتاحه العام فقط إلى الطرف الآخر.

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

رمز الخانات الست الذي يكشف الخادم غير النزيه

ما تحتاجه لإجراء هذه المقارنة

  • أن يكون الجهازان أمامك، أو أن يكون هناك شخص آخر جالسًا أمام جهازه الآن.
  • قناة ليست هي هذا النقل — مكالمة هاتفية، أو الغرفة التي تجلسان فيها معًا. أما لصق الرمز في المحادثة نفسها التي تقلق بشأنها فلا يثبت شيئًا.
  • عشر ثوانٍ. هذه هي كامل كلفة الفحص الوحيد الذي يكشف خادمًا غير أمين.

هناك دقيقة تستحق الصراحة بشأنها. يتبادل التشفير المدمج في WebRTC (DTLS) بصمات المفاتيح عبر خادم الإشارة الذي يُعرّف الجهازين أحدهما بالآخر. لو كان ذلك الخادم غير نزيه، لأمكنه نظريًا أن يتوسّط ويستبدل مفاتيحه الخاصة — هجوم وسيط كلاسيكي — دون أن يلاحظ أيٌّ من المتصفحَين ذلك فورًا.

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

  1. ابدأ نقلًا بين الجهازين وانتظر حتى يظهر رمز التحقّق على كل شاشة.

    https://relayium.com/

  2. اقرأ أحدهما بصوت مسموع رقمًا رقمًا عبر القناة الخارجة عن المسار — لا تنسخه داخل التطبيق ولا في خيط المحادثة نفسه.

  3. قارن الأرقام الستة كلها. فالتطابق الجزئي هو عدم تطابق.

  4. لا تقبل إلا إذا تطابقا. وإن اختلفا فارفض، واعرف على أي جهاز يجلس الطرف الآخر فعلًا قبل أن تعيد المحاولة.

  5. في سطر الأوامر اجعل المقارنة حاجزة لا اختيارية: يوقف ‎--verify‎ النقل عند تلك النقطة وينتظر تأكيدك، فلا يتحرك بايت واحد قبل أن ينظر أحدهم فعلًا.

    relayium send --verify ./report.pdf

ماذا تثبت المقارنة المتطابقة وماذا لا تثبت

ظهور الأرقام الستة نفسها على الشاشتين يعني أن بصمات الشهادات التي ثبّتها الطرفان متطابقة، أي أن خادم اللقاء لم يستبدل طرفًا ولم ينتحل شخصية أيٍّ منهما. وهذا بالضبط هو الهجوم الذي يتناوله هذا القسم.

إنها تُوثّق الطرفين. ولا تثبت شيئًا عن كل قفزة شبكية بينهما، ولا تثبت شيئًا على الإطلاق إن لم يقارنها أحد — ولهذا وُجد ‎--verify‎.

التأكد من أن ما يصل هو تمامًا ما أُرسِل

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

الروابط المُخزَّنة: مفتاح مختلف، يُولَّد مرة واحدة، ولا يوجد إلا في الرابط

يحتاج النقل الفوري إلى وجود الطرفين متصلَين في الوقت نفسه. حين يتعذّر ذلك، يقدّم Relayium بدلًا منه رابط تنزيل مُخزَّن — وهذا يستخدم آلية مختلفة فعلًا، يُستحسَن عدم الخلط بينها وبين آلية النقل الفوري أعلاه.

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

ما يمكن للخادم رؤيته — وما لا يمكنه

من المفيد أن نوضّح بالضبط أين يقف الخادم من كل هذا، لأن «التشفير من الطرف إلى الطرف» ادّعاء يسهل قوله ويصعب قوله بدقة. في الوضع الفوري على نفس الشبكة، لا يلمس الملف نفسه خوادم Relayium إطلاقًا — بل يُبَثّ مباشرة بين المتصفحَين. تقتصر مهمة خادم الإشارة على تمرير رسائل إعداد الاتصال (معلومات SDP/ICE التقنية التي يحتاجها WebRTC لإنشاء رابط مباشر) حتى يتمكن الجهازان من إيجاد أحدهما الآخر؛ فهو لا يرى أبدًا محتوى الملفات أو أسماءها أو المفاتيح.

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

حين تسوء المقارنة

ثلاث نتائج، والأولى وحدها حالة طارئة. ومعرفة أيَّها أمامك هي معظم الفائدة.

ما تراه، وما تفحصه، وماذا يعني

تعرض الشاشتان رمزين مختلفين.
https://relayium.com/   # the two screens show different verification codes

توقّف ولا ترسل الملف. فاختلاف الرمزين يعني أن الطرفين ثبّتا بصمتي شهادة مختلفتين، أي أن الطرف البعيد ليس الجهاز الذي تظنه. تأكّد خارج المسار من الجهاز الذي يجلس عليه الطرف الآخر ثم ابدأ من جديد. وإعادة التشغيل مع ‎--verify‎ تجعل النقل ينتظر عند تلك المقارنة بدل تركها لانتباهك.

لم يظهر أي رمز تحقّق بعد.
https://relayium.com/   # no verification code on screen yet

الرمز مشتقّ من اتصال، فهو يوجد متى اتصل الطرفان. وقبل ذلك لا شيء يُقارَن، و«نقل لا يتصل أبدًا» مشكلة مختلفة عن «نقل اختلف رمزاه».

قارنت الرمزين بلصق أحدهما في المحادثة التي تستخدمها أصلًا.
relayium send --verify ./report.pdf   # holds the transfer at the comparison

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

الأسئلة الشائعة

هل يستطيع Relayium قراءة ملفاتي؟

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

ماذا يرى الخادم فعلًا؟

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

هل مُرحِّل TURN نقطة ضعف؟

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

هل Relayium مفتوح المصدر؟

نعم. تصميم البروتوكول وكامل شيفرة العميل والخادم متاحة علنًا على GitHub بموجب رخصة AGPL-3.0، لذا يمكن تدقيق التعمية الموصوفة هنا بشكل مستقل بدلًا من تصديقها على عِلّاتها.

ماذا لو لم يتطابق رمزا التحقق على الشاشة؟

أوقِف النقل. اختلاف الرمزين يعني أن الجهازين لا يريان الاتصال نفسه — وهذا بالضبط ما يحدث عند استبدال المفاتيح أو وجود وسيط، لا خللًا بسيطًا غير مؤذٍ. (أما فشل مصافحة «الالتزام ثم الكشف» فهو عطل مختلف وأسبق: يُنهي الاتصال نفسه قبل عرض أي رمز.) لا تُكمِل حتى تفهم السبب.

أتتساءل كيف يبدو الأمر عمليًا؟ فعِّل التحقّق المتقدّم قبل بدء اتصال جديد، لتسري مقارنة الرمز وخطوات التأكيد منذ البداية.

جرّب Relayium الآن

تابع القراءة