date: 2022-01-16T03:00:00Z
كيف تعمل الرسائل المشفرة من طرف إلى طرف على LocalCryptos
14 دقيقة
LocalCryptos هو سوق نظير لنظير للعملات المشفرة و هو السوق الأشهر الذي يستخدم التشفير من طرف إلى طرف لحماية الرسائل بين المستخدمين.
يتم تشفير الرسائل بين المستخدمين على منصة التداول LocalCryptos من طرف إلى طرف. هذا يعني أن الرسائل يتم تشفيرها أثناء النقل من كمبيوتر المرسل إلى جهاز المستلم، دون السماح لأي شخص بينهما باعتراض وقراءة المحادثة أثناء النقل ، بما في ذلك LocalCryptos.
منصتنا تقوم بتحقيق ذلك باستخدام واجهة برمجة تطبيقات الويب المشفرة ، وهي واجهة برمجة تطبيقات JavaScript API حديثة توفر عمليات تشفير متقدمة مثل التشفير وفك التشفير و التحقق من التوقيع وإنشاء مفتاح آمن لمتصفحات الويب.
على الرغم من أن إرسال الرسائل واستلامها على LocalCryptos قد يكون مشابهًا لأي موقع ويب آخر ، فإن ما يحدث "داخل" وحدة المعالجة المركزية بجهازك يختلف اختلافًا كبيرًا مع كل موقع ويب آخر تقريبًا.
LocalCryptos هو من بين عدد قليل من تطبيقات الويب المعروفة التي تنفذ تقنية تشفير آمنة من طرف إلى طرف داخل موقع ويب ، مثل تطبيقات
WhatsApp Web </ a> و Skiff .
قبل البدء في التشفير من طرف الى طرف
أدى الكشف عن مراقبة الاتصالات الجماعية والانتهاكات الكبرى لقواعد البيانات إلى جعل المستهلكين أكثر حذراً بشأن خصوصيتهم على الإنترنت.
تعرضت الخدمات البارزة عبر الإنترنت للتطفل من قبل قراصنة مجهولين. تمت سرقة مجموعة من المعلومات الحساسة من شركات مثل Apple و TikTok و Target و Equifax و Yahoo و eBay و Ancestry.com و AOL و Adobe و LinkedIn و Microsoft و YouTube و Instagram و Quora و Airtel و Ashley Madison و Nintendo و Dropbox و T-Mobile و Uber و United States Postal Service والمزيد في بعض أكبر عمليات إختراق البيانات في التاريخ الحديث.
بالإضافة إلى ذلك ، تم الكشف في عام 2013 أن حكومة الولايات المتحدة تجمع البيانات سرًا من شركات الإنترنت. قام برنامج PRISM التابع لوكالة الأمن القومي بسحب البيانات من مجموعة واسعة من الشركات بما في ذلك Google و Microsoft و Yahoo و Facebook و YouTube و Skype والعديد من مزودي خدمات الإنترنت للمستهلكين.
لم توفر تطبيقات المراسلة الفورية المبكرة أي حماية من هذه الأنواع من الانتهاكات. على الرغم من أن إرسال الرسائل عبر القنوات المشفرة، كانت القناة عادة بين العميل ومزود الخدمة. تمكن مزود الخدمة ، مثل Facebook أو Skype أو Google ، من قراءة محتويات جميع الرسائل التي تم تسليمها من خلال الخدمة. إذا تم اختراق مزود الخدمة، فيمكن استخراج الرسائل النصية العادية بشكل كبير.
ابتكار التشفير من طرف إلى طرف
استجابة لهذه التهديدات ، قام المطورون وخبراء التشفير بتسريع البحث في التقنيات الجديدة لتوفير الأمن في عالم رقمي حديث حيث لا يمكن الوثوق بمزودي خدمات الإنترنت أو مقدمي الخدمات. تستخدم العديد من تطبيقات المراسلة الفورية واسعة الانتشار الآن تقنيات تشفير متقدمة لتحقيق السرية الشاملة ، بما في ذلك OTR و iMessage من Apple و WhatsApp و Signal و Telegram وحتى Facebook Messenger.
تطبق منصة LocalCryptos تقنيات التشفير من طرف إلى طرف بحيث تظل التفاصيل المالية والمعلومات الشخصية لمستخدميه سرية بين الأطراف المعنية. الرسائل بين المستخدمين يتم تشفيرها ، مما يعني أنه حتى في حالة اختراق قاعدة البيانات ، لا يمكن استخراج أي معلومات حساسة مثل معلومات الحساب المصرفي من الرسائل التاريخية.
استوحى المطورون والباحثون وراء بروتوكول المراسلة الفورية Off-the Record Messaging (OTR) التكنولوجيا الكامنة وراء الرسائل المشفرة من طرف إلى طرف على LocalCryptos.
ما لم يتم تشفيره على LocalCryptos
قبل الخوض في التفاصيل الفنية لتنفيذ التشفير من طرف إلى طرف في LocalCryptos، دعنا نناقش ما هو الذي لم يتم جعله سريًا.
لا يمكن لـ LocalCryptos قراءة محتويات كل رسالة دون إذن من أحد المشاركين ، ومع ذلك يمكنه رؤية بعض البيانات الوصفية المتعلقة بهذه الرسائل. على سبيل المثال ، نعرف متى تم إرسال رسالة ومن تم إرسالها إليه ونعرف أيضًا ما إذا تمت قراءة رسالة معينة ومتى.
إذا كنت تفكر في الرسائل المشفرة من طرف إلى طرف على أنها رسائل ، فإن LocalCryptos هي خدمة البريد التي توفر المغلفات التي تحتوي على كل حرف. على الرغم من أننا لا نستطيع قراءة الحروف ، إلا أننا نحتاج إلى معرفة مكان تسليم المغلف.
من خلال التعامل مع المغلفات، يمكننا أيضًا إجراء بعض التخمينات حول رسالة دون قراءتها:
- إذا شعرنا أن المغلف أثقل من المعتاد ، فيمكننا أن نخمن حجمه عن طريق وزنه مثلا. ومع ذلك ، يتم إخفاء هذا الأمر بواسطة المتراسلين عن طريق ملء الرسالة بصفحات فارغة ، لذلك لن نتمكن من تحديد عدد الكلمات الدقيق.
- إذا كان المغلف مصحوبًا بطرد ، فمن الواضح أنك أرسلت مرفقًا (مثل صورة أو مستند) بدلاً من رسالة عادية. عادة ما تكون الرسائل العادية أقل من كيلو بايت بينما يمكن أن تكون المرفقات أكبر بعدة آلاف من المرات.
الآن ، دعنا نناقش ما الذي يتم تشفيره وكيف يعمل بروتوكول المراسلة المشفر من طرف إلى طرف على LocalCryptos.
الموافقة سرا على مفتاح التشفير
لكي يتمكن مستخدمان من إرسال رسائل مشفرة ذهابًا وإيابًا ، يجب أن يتفق كلاهما على سر مشترك لتشفير هذه الرسائل وفك تشفيرها. ومع ذلك، لا يمكنهم السماح لأي شخص آخر برؤية هذا المفتاح السري المشترك ، لذا فإن تمرير هذا المفتاح عبر خادم LocalCryptos كوسيط أمر غير وارد.
تستخدم LocalCryptos مخطط اتفاقية المفتاح المجهول و التي تعرف بإسم Elliptic Curve Diffie – Hellman Key Exchange (ECDH). يسمح مخطط التشفير هذا لشخصين لهما أزواج من المفاتيح العامة باشتقاق نفس كلمة السر المشتركة باستخدام المفتاح الخاص لشخص واحد والمفتاح العام للآخر.
لكي يعمل هذا ، يعمل LocalCryptos على الخادم الرئيسي لتوزيع مفاتيح التشفير العامة للمستخدمين. تحتفظ متصفحات الويب الخاصة بالمستخدمين أيضًا بالمفاتيح العامة للمستخدمين الآخرين على مساحة تخزين أجهزتهم للحماية من اختراق الخادم الرئيسي ، ومع ذلك سنترك هذه التفاصيل لمقال آخر.
أولاً ، يجب على المستخدمين معرفة مفاتيح الهوية العامة للطرف الآخر أو جلبها من خادم مفاتيح LocalCryptos. لا يتم استخدام أزواج مفاتيح الهوية هذه ، والتي لا تتغير أبدًا ، في عملية ECDH ؛ ومع ذلك ، يتم استخدامها للمصادقة على مجموعة أخرى من أزواج المفاتيح المستخدمة في طريقة Diffie-Hellman.
بالإضافة إلى مفاتيح الهوية العامة ، يقوم المستخدمون بإنشاء عدد كبير من "المفاتيح المسبقة" الآمنة تشفيريًا (أيضًا "مفاتيح الشركة المصنعة") عند التسجيل لأول مرة على المنصة. هذه هي أزواج المفاتيح العامة والخاصة المؤقتة التي يتم توقيعها رقميًا باستخدام مفاتيح هوية المستخدم ، ثم يتم تحميلها إلى خادم مفاتيح LocalCryptos. الغرض من هذه "المفاتيح المسبقة" هو تمكين تبادل المفاتيح غير المتزامن تمامًا (أي السماح للمستخدمين بتلقي الرسائل أثناء عدم الاتصال بالإنترنت).
عندما يبدأ المستخدم محادثة ، فسيقوم بإنشاء زوج مفاتيح ثالث سريع الزوال. نسمي هذا "مفتاح المتلقي". زوج المفاتيح هذا هو الجزء الأخير من اللغز لتمكين مخطط اتفاقية المفتاح الآمن وغير المتزامن للعمل بشكل لا تشوبه شائبة.
العملية التدريجية لبدء بروتوكول تشفير آمن من طرف إلى طرف هي:
- يحصل المستخدم الذي يبدأ المحادثة (أليس) على معلومات مفتاح المستلم (بوب) من خادم مفتاح LocalCryptos. وهذا يشمل:
- مفتاح هوية بوب (المفتاح العام)
- أحد "المفاتيح المسبقة" لبوب الموقّع مسبقًا (المفتاح العام والتوقيع الرقمي)
- ستتحقق أليس من أن التوقيع الرقمي المرتبط بـ "المفتاح المسبق" الخاص ببوب قد تم توقيعه بواسطة مفتاح هوية بوب.
- ستقوم أليس بأداء Diffie – Hellman باستخدام المفتاح الخاص لمفتاح "مفتاح المتلقي" الخاص بها والمفتاح العام لـ "المفتاح المسبق" الخاص بـ Bob. سيصبح ناتج هذه الخوارزمية هو السر المشترك (
SharedSecretRoot). - يتم استخدام
SharedSecretRoot كبداية لحساب مفاتيح أكثر أمانًا باستخدام SHA ‐ 256 كدالة اشتقاق مفتاح. نظرًا لأنه يعتبر ممارسة سيئة لاستخدام مفتاح واحد لأغراض متعددة بسبب التفاعلات غير المرغوب فيها المحتملة في الأنظمة المختلفة ، يتم اشتقاق مفاتيح مختلفة من الجذر لأغراض مختلفة: SharedSecretEnc - لتشفير الرسائل باستخدام AES ‐ 256 ، نتيجة SHA256 (SharedSecretRoot || "enc").SharedSecretMac - لمصادقة الرسائل باستخدام HMAC ‐ SHA256 ، نتيجة SHA256 (SharedSecretRoot || "mac").
- ستزود أليس بوب عبر LocalCryptos بمفتاحها العام والتوقيع الرقمي المرفق (موقّع بمفتاح هويتها) لـ "مفتاح المتلقي" الذي أنشأته أثناء هذا الإجراء.
عندما يحصل بوب على مفتاحها العام ، سيكون لديه معلومات كافية ليتمكن من اكتشاف نفس السر المشترك الذي قامت أليس بحسابه.
تنتج طريقة Diffie-Hellman نفس السر المشترك عند إعطاء مدخلات مفتاح عام وخاص معكوسة. لأي مفتاحين خاصين pk و p’k والمفاتيح العامة من ECDSA المقابلة لها pu و p’u:
السر المشترك (SharedSecretRoot) هو وظيفة ECDH باستخدام معلمات المفتاح الخاص لطرف والمفتاح العام للطرف الآخر. لزوج مفاتيح المصنع وأخذ زوج المفاتيح و ، الجذر السري المشترك هو:
هذا يعني أنه عندما يسجل بوب الدخول للتحقق من رسائله:
- سيتلقى بوب "مفتاح المتلقي" والتوقيع الرقمي الخاص بأليس ، والنص المشفر للرسالة ا��مشفرة التي أرسلتها ، ومفتاح هويتها.
- سيتحقق بوب من أن التوقيع الرقمي المرفق بـ "مفتاح المتلقي" أليس قد تم توقيعه باستخدام زوج مفاتيح هويتها للتحقق من أنه يخصها حقًا.
- سيقوم بوب بأداء Diffie – Hellman باستخدام المفتاح الخاص لـ "مفتاحه المسبق" والمفتاح العام لـ "مفتاح taker" الخاص بـ Alice. سيوفر هذا لـ Bob نفس
SharedSecretRoot الذي أنشأته أليس. - باستخدام نفس وظائف اشتقاق المفاتيح ، سيجد بوب
SharedSecretEnc و SharedSecretMac ويستخدمهما لفك تشفير الرسالة المشفرة التي أرسلتها أليس.
الهيكل الداخلي للرسائل
عندما يكتب المستخدم رسالة ، يتم تجميعها في حمولة ��شفرة بتنسيق JSON قبل أن تبدأ عملية التشفير. في وقت كتابة هذا التقرير ، يوجد نوعان من حمولات الرسائل: الرسائل النصية العادية والمرفقات. الرسائل عبارة عن رسائل نصية عادية بسيطة ومرفقات مخصصة لتحميلات أكبر للملفات ، مثل الصور أو المستندات.
حمولة الرسالة هي بنية JSON بسيطة. هناك ثلاث خصائص يجب تضمينها في كل حمولة بغض النظر عن النوع:
الرسائل القياسية
النوع - يمكن أن يكون هذا "رسالة" أو "مرفق". قد يتم إضافة دعم لأنواع أخرى في المستقبل.trade_id - المعرف الفريد لهذه الصفقة. هذا لمنع هجمات إعادة التشغيل المعقدة (أي نسخ الرسائل من صفقات أخرى والتظاهر بأنها كانت مخصصة لهذا.)client_timestamp - الطابع الزمني الحالي على كمبيوتر المرسل (ISO 8601). هذا أيضًا لاكتشاف هجمات إعادة التشغيل المعقدة ويسمح للمحكم باستدعاء فاعل سيئ إذا ادعى أنه أرسل رسالة في وقت متأخر أو قبل الواقع.
هذا مثال على ذلك:
{
"type": "message",
"client_timestamp": "2022-01-13T00:00:00Z",
"trade_id": "xxxx-xxxx-xxxx-xxx",
"message": "مرحبا! هذه رسالتي المشفرة "
}
المرفقات المشفرة
في بعض الأحيان ، يرغب المستخدمون في إرسال مرفقات بعضهم البعض ، على سبيل المثال الصور والمستندات.
ومع ذلك ، فإن تضمين محتويات المرفقات داخل الرسالة المشفرة قد يؤدي إلى تجربة مستخدم مؤلمة ، خاصة للمستخدمين الذين يعانون من ضعف اتصالات الإنترنت. قد يعني ذلك أن المستلم سيحتاج إلى تنزيل المرفق بالكامل (والذي قد يكون عدة ميغا بايتس) قبل أن يعرف أنه مرفق.
بدلاً من ذلك ، نفصل بين الاثنين: يتم تشفير الملف وتحميله بشكل منفصل ، وتشير الرسالة المشفرة ببساطة إلى موقع المرفق المشفر وإرشادات حول كيفية فك تشفيره. يمنح هذا المستلم خيار عدم تنزيل المرفق.
عملية إرسال المرفقات هي:
- ينشئ المرسل مفتاحًا سريًا جديدًا 256 بت وناقل تهيئة لتشفير المرفق (
AttachmentKey و AttachmentIv). - يقوم المرسل بتشفير محتويات المرفق باستخدام AES256 ‐ CBC ، مع
AttachmentKey و AttachmentIv. - يتم إنشاء هاش SHA ‐ 256 لـ
AttachmentCiphertext لحماية سلامة المرفق (AttachmentHash). - يقوم المرسل بتحميل
AttachmentCiphertext إلى التخزين السحابي ويتم منحه معرفًا فريدًا (AttachmentBlobKey). - ينشئ المرسل حمولة رسالة تحتوي على ارتباط بالمرفق والمعلومات اللازمة للمصادقة عليه وفك تشفيره (
AttachmentBlobKey ، AttachmentKey ، AttachmentIv ، و تجزئة المرفقات). كما تتضمن أيضًا البيانات الوصفية ، بما في ذلك اسم الملف الأصلي والملحق وحجم المرفق.
هذا مثال على ذلك:
{
"type": "attachment",
"client_timestamp": "2022-01-13T00:00:00Z",
"trade_id": "xxxx-xxxx-xxxx-xxx",
"attachment_blob_key": "AttachmentBlobKey",
"attachment_sha256": "AttachmentHash",
"attachment_iv": "AttachmentIv",
"attachment_key": "AttachmentKey",
"filename": "UploadedFile.jpg",
"filesize": 1000000
}
تشفير حمولات الرسائل
يتم تشفير حمولات الرسائل المشفرة بتنسيق JSON باستخدام السر المشترك shared secret للمحادثة ، وتوقيعها باستخدام مفتاح هوية حساب المرسل ، ومجزأة باستخدام مفتاح MAC المشترك. يتيح ذلك للمستخدم الآخر التحقق من أن الرسالة قد تم إرسالها من قبل المرسل ولم يتم العبث بها على طول الطريق.
كيف يعمل ذلك:
- ينشئ المرسل توقيع ECDSA (
MessageSignature) لتجزئة keccak ‐ 256 لـ MessagePayload. - يقوم المرسل بإنشاء متجه تهيئة للتشفير (
MessageIv). - يتم إنشاء حزمة JSON ‐ المشفرة (
MessagePackage) تحتوي على MessagePayload و MessageSignature. MessagePackage مشفرة باستخدام AES256 ‐ CBC إلى SharedSecretEnc مع IV MessageIv و الملء هو (Message Ciphertext).- لحماية سلامة الرسالة ، يُنتج المرسل رمز مصادقة الرسالة (
MessageMac) كـ HMAC ‐ SHA256 (SharedSecretMac، MessageCiphertext). - يرسل المرسل
Message Ciphertext و Message و MessageMac إلى واجهة برمجة التطبيقات ، التي تسلمها إلى المستلم.
أسئلة
ألن يلغي التحكيم الغرض من التشفير من طرف إلى طرف؟
لا يوجد شيء مثل بروتوكول مراسلة مشفر يمكن أن يجعل من المستحيل على مستلم الرسالة مشاركتها مع شخص آخر.
لا يمكنك منع الشخص الذي ترسل إليه رسالة من مشاركة رسالتك ، تمامًا كما لا يمكنك منع شخص ما من التقاط لقطة شاشة. إذا قرر شخص ما مشاركة محادثته ، بما في ذلك معنا ، فيمكنه فعل ذلك.
عندما نحتاج إلى التحقيق في مزاعم الاحتيال أو إساءة الاستخدام ، أو التعامل مع نزاعات الدفع ، فإننا نشجع المستخدمين على مشاركة محتويات المحادثات معنا.
تسمح لنا مشاركة السر المشترك للمحادثة معنا بالعودة وفك تشفير النص لتلك المحادثة المعينة ، إلا أن ذلك لا يؤثر على خصوصية محادثاتك الأخرى. هذا لأن كل صفقة تستخدم مجموعة فريدة من أزواج المفاتيح لاشتقاق هذا السر المشترك ، مما يجعل الأسرار المشتركة فريدة أيضًا.
ما هي حدود هذا النظام؟
لقد أخبرناك للتو كيف أن الرسائل آمنة على LocalCryptos. بروح الشفافية ، دعونا نناقش أيضًا كيف يمكن أن تكون الرسائل غير مؤمنة.
هناك بعض الخبراء الذين يدافعون عن إنشاء تطبيقات تشفير قائمة على الويب مصممة لاحترام اهتمامات المستخدم بدلاً من موفر الويب ، وهو ما فعلناه بالضبط. بينما لا نتفق في النهاية مع هذه التوصية الشاملة لأننا نعتقد أن الفوائد تفوق المخاطر وأن الأمان المستند إلى الويب سيتحسن بمرور الوقت ، فإن الحجج ضد استخدام Web Cryptography API في مواقع الويب لا تخلو من المزايا.
الحجة الأساسية ضد استخدام التشفير داخل متصفحات الويب هي أن تطبيقات الويب أقل أمانًا في النهاية من البرامج وملحقات المتصفح او ما يعرف بـ browser extensions عندما يتعلق الأمر بتسليم رمز التطبيق. هذا بسبب الطريقة التي يعمل بها تصفح الويب: عندما تزور هذا الموقع أو أي موقع آخر ، سيقوم متصفح الويب الخاص بك بجلب أحدث كود تطبيق لـ LocalCryptos مباشرة من خادم الويب الخاص بـ LocalCryptos وتشغيله — دون بذل الكثير للمصادقة على أن الرمز هو حقًا رمز LocalCryptos الرسمي ولم يتم تعديله.
قد تعتقد أن استخدام HTTPS يحل مشكلة المصادقة هذه ، مما يجعل يمكن لـ LocalCryptos التوقيع رقميًا على الكود الذي يقدمه ، وأنت على صواب جزئيًا ، ولكن إلى حد معين فقط. بينما يقضي HTTPS عمليًا على الغالبية العظمى من هجمات الرجل في الوسط النظرية ضد مستخدمي الويب ، فإنه لا يحل مشكلة التهديد الذي يمكن أن يتعرض له خادم الويب LocalCryptos نفسه. يمكن للمتسلل الذكي اختراق خوادم الويب الخاصة بـ LocalCryptos وتعديل أحد ملفات JavaScript التي يتم تسليمها إلى المستخدمين النهائيين بعناية ، ربما لإدخال بضعة أسطر من التعليمات البرمجية لسحب المفاتيح الخاصة.
يقوم LocalCryptos بجهود كثيرة لتقليل هذه المخاطر ، وذلك باستخدام جميع آليات أمان HTTP و DNS و BGP المتاحة ، مع أخذ الأمان على محمل الجد. ومع ذلك ، لا يمكن القضاء على هذا التهديد تمامًا. يمكن قول الشيء نفسه عن كل موقع ويب وتطبيق ويب آخر ؛ هناك دائمًا احتمال أن يكون أي موقع ويب أو تطبيق عرضة لهجوم شديد التعقيد. في نهاية اليوم، يكون الأمن السيبراني دائمًا مقياسًا متحركًا يتطلب مناقشة دقيقة وصادقة ، وأي شخص يخبرك أن جزءًا معينًا من البرنامج لا يمكن اختراقه فهو على خطأ.
إذن ما الذي سيحدث لخصوصية رسائلك الخاصة المرسلة والمستلمة إذا تعرض موقع LocalCryptos الإلكتروني لاختراق كبير؟ ذلك يعتمد على عدة أشياء. إذا كان متصفح الويب الخاص بك ينفذ تعليمات برمجية ضارة تم حقنها بواسطة متسلل متطور، فهناك احتمال أن يتمكنوا من الوصول إلى مفتاحك الخاص وفك تشفير كل محادثتك. ومع ذلك ، إذا لم ينفذ متصفح الويب الخاص بك هذا الرمز المخرب افتراضيًا لإختراق محادثتك، فستظل محادثاتك السرية سرية بغض النظر عن إختراق موقع الويب. بمعنى آخر، إذا قمت بزيارة الموقع وقمت بتسجيل الدخول أثناء هجوم نشط، فقد تكون في خطر؛ ومع ذلك ، إذا كنت لا تزور موقع الويب بنشاط في وقت الهجوم ، فلن تكون في أي خطر. هذا لأن متصفح الويب الخاص بك لا ينفذ رمز موقع الويب إلا عندما تنتقل إليه عمدًا.
بالمقارنة ، إذا تم اختراق خدمة مراسلة مركزية ، فسيكون الجميع في خطر على الفور. سيكون المهاجم قادرًا على تنزيل النص العادي لكل رسالة مرسلة ومستلمة ، لأن كل رسالة سيتم تخزينها ببساطة في قاعدة بيانات بنص عادي. إن تداعيات هجوم على خدمة مراسلة غير مشفرة ستكون أكثر تدميراً بكثير من هجوم على تطبيق ويب مشفر من طرف إلى طرف.
في النهاية ، نعتقد أن الفوائد الأمنية لاستخدام تقنية التشفير من طرف إلى طرف من جانب العميل تفوق إلى حد كبير مخاطر الهجوم المستهدف والمعقد ، وأن أمان تسليم التطبيقات في تطبيقات الويب سيتحسن بمرور الوقت. تصبح تقنيات الأمان الجديدة متاحة للمتصفحات الحديثة.
لماذا لا يتم اسختدام خوارزمية Double Ratchet؟
في حين أن بعض تطبيقات الرسائل المشفرة من طرف إلى طرف مثل Signal تأخذ التجديدات الرئيسية خطوة إلى الأمام مع اتفاقية Diffie-Hellman بعد كل رسالة ذهابًا وإيابًا ، فإن هذه الممارسة لا تفيد LocalCryptos وهي في الواقع تأتي بنتائج عكسية لأنها تعقد عملية تسوية المنازعات.
تجديدات المفاتيح على مستوى الرسالة هي مبالغة في التعامل مع التداولات لأن جلسات المحادثات لا تدوم طويلاً. من المنطقي الاستمرار في تبادل المفاتيح الجديدة للمحادثات طويلة الأمد (مثل محادثات WhatsApp أو Facebook التي يمكن أن تستمر لسنوات) ، ولكن معظم التداولات تنتهي بسرعة كبيرة.
كيف يمكنني التحقق من تشفير رسائلي؟
إذا قمت بتمكين "وضع الخبير" أثناء المحادثة ، يمكنك النقر فوق كل رسالة لكشف التفاصيل منخفضة المستوى حول كل رسالة.
تشمل هذه التفاصيل كل ما ناقشناه في المقالة. ومع ذلك ، سوف تحتاج إلى فهم جيد للتشفير التطبيقي حتى تتمكن من فهم معنى وأهمية هذه القيم.
يمكنك النقر فوق كل قيمة لنسخها إلى الحافظة الخاصة بك والتحقق يدويًا من أن العمليات الحسابية تسحب - باستخدام أي رمز أو أداة خارجية تختارها ، أو يمكنك كتابة ما تريد.
يمكنك أيضًا التحقق من أن هذه هي المعلومات الوحيدة التي يتم إرسالها إلى LocalCryptos باستخدام أدوات المطور الخاصة بالمتصفح الخاص بك.
