(لقد وجدت خيطًا على Twitter يحتوي على شرح رائع للغاية عن الأصفار المتماثلة. كتبه كولم ماك كارثاي ، أحد المساهمين الرئيسيين في أباتشي. طلبت من كولم إذنًا بالترجمة ، وافق برفق).
سأشرح لك بلغة واضحة ما يحدث عندما يتم تشفير البيانات. آمل أنه بدون التصوف والأشياء المعقدة التي اخترعها التشفير.
لذا ، فإن التشفير المتماثل هو بالضبط ما نستخدمه في معظم الحالات عندما نريد تشفير مجموعة من البيانات. متصفحك يرسل ويستقبل البيانات باستخدام تشفير متماثل. إذا قمت بتشفير الملفات أو القرص ، فإن التشفير المتماثل يعمل أيضًا في هذه الحالة. iMessage ، Signal ، WhatsApp - كلهم يستخدمون تشفيرًا متماثلًا لحماية أمان مراسلاتك.
إذا كنت تعتقد أنه عند تشفير البيانات يتم خلطها بحيث لا يمكن لأحد قراءتها بدون مفتاح ، فإن ذلك يحدث بالفعل.
هنا مثال بسيط. افترض أن لدي سلسلة Ovaltine وأريد تشفيرها. يمكنني استخدام rot13 - شفرة قيصر للمدرسة القديمة البسيطة للغاية ، والتي تجعل رقصة مستديرة من الحروف حيث a و z يدا ، ويستبدل كل حرف بحرف آخر من الحروف الأبجدية ، وهو 13 حرفا من الرسالة التي تم استبدالها. وبالتالي ، يتحول "O" إلى "B" ، ويصبح "v" "i" ، ونتيجة لذلك ، يتحول "Ovaltine" إلى "Binygvar". بالطبع ، هذه ليست آمنة جدا. هذا مثال ساذج ، من السهل جدًا كسره ، حيث يمكن للمهاجم معرفة الرسالة التي يتم العثور عليها غالبًا (عادةً في النص الأصلي "e") والعثور على الحروف المتبقية بهذه الطريقة.
الآن يمكنك أن تتخيل أنه يجب أن تكون هناك طرق أكثر صعوبة "لخلط" الحروف. على سبيل المثال ، هناك مخطط معقد حيث "a" ينتقل إلى "p" ، ولكن عندما يعاد تشفيره ، إلى "f". ربما حتى في بعض الأحيان يبدأ هذا المخطط في تشفير "a" بحرفين ، على سبيل المثال ، "jd" أو أي شيء آخر. وبالتالي ، يمكن لهذا المخطط المعقد تشفير "Ovaltine" في السلسلة "FGyswDmweeRq" (لاحظ أنه أصبح أطول). ظهرت خوارزميات التشفير في الماضي والتي كانت تعمل بطريقة مماثلة ، ولكن ليس هذا على الإطلاق كيف يعمل التشفير الحديث.
بدلاً من "خلط الرسائل" ، يأخذ التشفير الحديث سلتك السرية ويجمعها ببراعة مع البيانات العشوائية. هذا يشبه rot13 فقط في جانبين: التشفير وفك التشفير هما نفس العملية ، وكل شيء يحدث "في مكانه". في الواقع ، هل لاحظت أن rot13 هو كل من خوارزمية التشفير وفك التشفير؟ rot13 (Ovaltine) -> Binygvar ، rot13 (Binygvar) -> Ovaltine. أعتقد أن هذا تناظر جميل للغاية في تشفير متماثل. لكن العودة إلى موضوعنا. الحيلة هي أننا نستخدم عملية XOR bitwise. في التشفير ، والمنطق الرسمي ، والرمز ، يمكن الإشارة إلى برامج XOR بشكل مختلف ، لكنني سأستخدم رمزًا من المرجح أن تكون على دراية به. يبدو مثل هذا: ^.
XOR تعني "OR الحصري". هذا هو عامل (أو وظيفة ، إذا كنت تفضل ذلك) ، والذي يأخذ وسيطين ويعيد النتيجة. ^ B = C. يسمى هذا العامل "bitwise" لأنه ينطبق على البتات المقابلة لبعضها البعض. إذا كانت A و B بايتان ، فيمكننا افتراض أن A ^ B = C هي في الأساس 8 عمليات مختلفة تحدث في وقت واحد. ^ يقارن البتة الأولى A والبت الأول B ، ثم يضع النتيجة في البتة الأولى C. وهو يكرر نفس الشيء 7 مرات أكثر من البتات المتبقية. القواعد بسيطة: إذا كانت البتة من A هي "1" أو كانت البتة من B هي "1" ، فسنقوم بضبط البتة المقابلة C على "1" ، لكن فقط إذا كان "A" و "B" ليسا "1" في نفس الوقت. هذا هو الجزء الحصري. فيما يلي جدول حقيقة للمدرسة القديمة:
A|B|C 0|0|0 1|0|1 0|1|1 1|1|0
أروع شيء في XOR هو أنه يشبه rot13. يمكننا استخدامه للتشفير وفك التشفير. سأظهر هذا بمثال بسيط. دعونا نتخيل أننا نريد تشفير الرقم المعتاد "3" وأن مفتاح التشفير لدينا هو رقم آخر "7". وبالتالي 3 ^ 7 = 4. وهذا هو ، نتيجة التشفير هي "4". دعونا الآن فك الرقم. سأفعل نفس الشيء مرة أخرى: 4 ^ 7 = 3. خذ أي رقم تريده أو أي بيانات ، وسيعمل دائمًا - سيكون بإمكان XOR دائمًا فك تشفير نفسه.
شيئًا فشيئًا - هذه هي الطريقة التي نشفر بها تشفير البيانات وفك تشفيرها بالفعل ، ولا يوجد أي خلط ، فقط XOR-ing الجزء الصعب هو العثور على البيانات التي يمكننا تطبيقها على XOR. تتمثل إحدى الطرق في أخذ جزء كبير من البيانات السرية في متناول اليد واستخدامها كوسيطة ثانية لـ XOR. في هذه الحالة ، يجب على جميع المشاركين في عملية نقل البيانات المشفرة استخدام نفس مجموعة البيانات السرية للتشفير وفك التشفير. وسوف تعمل. صحيح ، هناك العديد من المشاكل.
المشكلة الأولى. يجب أن تبدو البيانات السرية عشوائية. لا يمكنك أخذ نص من كتاب أو أي شيء من هذا القبيل. سوف تظهر أي أنماط في البيانات المشفرة. هذا هو بالضبط ما جعل القوات المتحالفة متفوقة في الحرب العالمية الثانية.
المشكلة الثانية. لا يمكنك إعادة استخدام البيانات الحساسة ، حيث ستظهر الأنماط مرة أخرى. وبالتالي ، يتعين عليك بطريقة أو بأخرى توفير مجموعات كبيرة من البيانات السرية لكل من يحتاج إليها ، مثل اللوحة ذات المرة الواحدة. هذا صعب للغاية.
في التشفير الحديث ، "نولد" البيانات السرية التي نحتاجها من المفاتيح الصغيرة. هذه المفاتيح أسهل بكثير في حملها وحمايتها. هذا هو ما خوارزميات التشفير المتماثل حقًا - مخططات لتوليد البيانات الحتمية العشوائية من المفتاح. الجزء المتعلق بـ "الحتمية" مهم للغاية: يجب أن يقوم شخصان يحملان نفس المفتاح بإنشاء نفس مجموعة البيانات تمامًا ، وإلا فلن يتمكنوا من فهم بعضهم البعض. ربما سمعت عن هذه الخوارزميات: AES ، 3DES ، DES ، RC4 ، ChaCha20. انهم جميعا يفعلون ذلك.
اتضح أن المشكلة الرياضية المتمثلة في إنشاء دفق بيانات عشوائي (حيث لا توجد أنماط بأي شكل يمكن التنبؤ به) باستخدام المفتاح أمر صعب للغاية. من هذه القائمة ، تعتبر فقط AES و ChaCha20 آمنة اليوم. تم اختراق خوارزميات أخرى: كان الناس قادرين على التنبؤ بها. علاوة على ذلك ، تتمتع AES بسمعة مشوهة قليلاً ، لأن مصففي التشفير يقولون ما يلي:
AES هي خوارزمية التشفير الرئيسية والأكثر تحليلًا. تماما الذهب القياسية! : dark_sunglasses:
لكن في نفس الوقت يضيفون:
تطبيقات AES في البرامج (ليست في الأجهزة) إما غير آمنة أو بطيئة ، وأحيانًا ليست آمنة ، وبطيئة. لم يتم تصميمه مع مراعاة حقيقة أنه يمكن اختراقه باستخدام تحليل ذاكرة التخزين المؤقت. : facepalm:
لا تكن خائفًا جدًا إذا كان هذا غير واضح بالنسبة لك. الفكرة الرئيسية هي: AES رائع من وجهة نظر الرياضيات ، لكنه معقد للغاية في تنفيذ البرامج. ولكن لا تقلق - فنحن دائمًا ما يكون لدينا دعم AES على مستوى الأجهزة (يمكن العثور على قائمة بجميع المعالجات التي تدعم دعم الأجهزة AES هنا https://en.wikipedia.org/wiki/AES_instruction_set ، - ملاحظة المترجم).
مهما كان الأمر ، فإننا نواصل ... كيف تعمل هذه الخوارزميات في الواقع؟ كيف يمكننا أن نأخذ المفتاح وأن نولد بأمان دفق بيانات عشوائي؟ سوف أبسط الأشياء قليلاً هنا وأبدأ بالكتل.
تتلقى هذه الخوارزميات ثلاثة معلمات عند الإدخال وتعطي النص المشفر عند الإخراج. معلمات الإدخال - مفتاح ، نص مشفر و ... مفاجأة - شيء غريب يسمى "ناقلات التهيئة" (متجه التهيئة ، IV).
AES(key, IV, plaintext) -> encrypted_data.
يتم دمج المفتاح والرابع مع بعضهما البعض لإنشاء مجموعة من "شروط البدء" للخوارزمية ؛ هذا مشابه للمبادلة المبدئية أو خلط القطع في لعبة Scrabble. نفس المجموعة من المفتاح والرابع ستخلق دائمًا نفس مجموعة شروط البدء. أنت تسأل ، لماذا نحن بحاجة إلى IV إذن؟ نحتاج إلى IV حتى نتمكن من تشفير رسائل متعددة باستخدام نفس المفتاح. بدون IV ، سيكون كل دفق البيانات التي تم إنشاؤها نفس الشيء ، وهذا سيء. هذا ينتهك أحد القواعد التي تحدثنا عنها سابقًا: لا يمكننا إعادة استخدام نفس البيانات للتشفير. لذلك نحن بحاجة إلى الرابع لخلط النتيجة. ولكن على عكس المفتاح الرابع ، يمكن أن يكون عامًا.
لذلك ، عندما تقوم بتشفير رسالة وإرسالها إلى شخص ما ، يمكنك أيضًا إضافة: "مرحبًا ، إليك الرابع الذي استخدمته". لا يزال من الأهمية بمكان ألا نعيد استخدام مزيج المفتاح والرابع ، لأنها ستوفر لنا بيانات عشوائية متكررة. هناك طريقتان لتحقيق هذا الشرط: 1) الرابع هو نوع من العداد الذي نزيده مع كل رسالة جديدة. 2) يتم إنشاء IV بشكل عشوائي ، في حين أن له قيمة كبيرة إلى حد ما ، لذلك نحن لسنا بحاجة للقلق كثيرا حول الاصطدامات. وأيا كان الأمر ، فقد ذكرت أنني سأتحدث عن الكتل.
يتم خلط "المفاتيح" و "الرابع" أو دمجها بطريقة تنشئ مجموعة من شروط البدء ... هذه الشروط هي في الواقع "الكتلة" الأولية للبيانات العشوائية. يبلغ طول هذه الكتلة 128 بت لـ AES128 و 256 بت لـ AES256 و 512 بت لـ ChaCha20. وهنا يتجلى السحر الحقيقي والفردية لخوارزمية تشفير معينة. في الواقع ، يكمن جوهرها في كيفية إنشاء تسلسل الكتل وكيفية ارتباط كل كتلة بجيرانها. تبقى العلاقة بين هذه الكتل متوقعة حتى بالنسبة لأولئك الذين ليس لديهم مفتاح.
لن أتعمق في كيفية عمل هذه الخوارزميات ، ولكن إذا كنت تريد معرفة المزيد ، فإنني أنصحك بالبدء في استكشاف هذا الموضوع باستخدام المولدات التطورية الخطية (LCG). LCG هي وظيفة تقوم بإنشاء كتل بيانات "دائرية" بطريقة عشوائية وغير متكررة. ثم نلقي نظرة على شبكات Feistel ، المستوى التالي من تطوير LCG. ثم تعامل مع S-Boxes ، ثم انظر إلى كيفية إنشاء Salsa20 للتشابك في خوارزمية ChaCha20. كل هذا هو أكثر بأسعار معقولة مما كنت تعتقد!
لذلك ، نحن نعرف الآن كيف يمكن دمج دفق بيانات عشوائي مع نص لتشفيره وفك تشفيره ، ونحن بالفعل قليلاً في موضوع كيفية إنشاء دفق البيانات العشوائي هذا. أليس هذا كل ما نحتاجه؟ بالنسبة لتشفير القرص ، هذا كل شيء تقريبًا. يمكننا تشفير كل كتلة أو قطاع من التخزين باستخدام مفتاح واحد و IV ، والتي يمكن الحصول عليها من "الموضع" على القرص. وبالتالي ، يمكننا دائمًا فك تشفير أي كتلة بيانات في أي مكان على القرص ، طالما أن لدينا المفتاح. ولكن هناك مشكلة واحدة ... يمكن لأي شخص أن يدمر بياناتنا المشفرة. إذا قمت بتغيير قيمة أي بايت ، حتى لو لم يكن لدي مفتاح ، فلن نتمكن في النهاية من فك تشفير الكتلة. وليس هناك حماية ضد هذا النوع من التدخل. في حالة إرسال الرسائل والبيانات عبر الشبكة ، يصبح هذا أكثر أهمية. لا نريد أن يفسد أي شخص بياناتنا المرسلة. لذلك نحن بحاجة إلى إضافة تحقق النزاهة! هناك عدة مخططات للقيام بذلك.
تعد HMAC و GCM و Poly1305 أكثر أنظمة التحقق من النزاهة الحديثة شيوعًا. تعمل هذه الخوارزميات بشكل أساسي مثل هذا: يتم توفيرها مع البيانات ومفتاح آخر (ما يسمى مفتاح التكامل). بعد العمليات الحسابية ، يقدمون MAC (رمز مصادقة الرسائل) أو العلامة ، والتي بدورها هي مجرد جزء آخر من البيانات التي تعمل كتوقيع.
وبالتالي ، بالنسبة للتشفير والحماية ، قد يبدو مخططنا كما يلي:
AES(key, IV, "Ovaltine") -> encrypted_output HMAC(key, encrypted_output) -> MAC
ثم بواسطة الأسلاك نرسل:
IV | encrypted_output | MAC
لفك التشفير ، نتحقق من MAC وننشئه مرة أخرى ونقارن النتيجة مع MAC المستلم ، ثم نفك تشفير البيانات. هناك اختلافات داخلية في كيفية قيام HMAC و GCM و Poly1305 بإنشاء هذه التوقيعات ، ولكن لا داعي للقلق بشأن ذلك. حتى الآن ، عادةً ما يتم لف هذا المزيج من العمليات في وظيفة تسمى "AEAD" (تشفير مصادق عليه مع بيانات إضافية). تحت الغطاء ، تفعل كل ما تحدثت عنه سابقًا:
AEAD(key, IV, plaintext, additional_data) -> IV_encrypted_data_MAC
قطعة تسمى "extra_data" هي مجرد بيانات يمكنك من خلالها التأكد من أن الطرف المرسل لديه هذه البيانات ، على الرغم من أنه لم يتم إرسالها إليهم. إنه مثل البيانات الوصفية التي تحدد حقوق الوصول. غالبًا ما يتم ترك هذا الحقل فارغًا.
ومع ذلك ، يمكنك أن تواجه مشاكل مع AEAD إذا كنت تستخدم نفس الرابع. هذا سيء! هناك محاولات لتحسين هذا الموقف: يعمل زميلي ، واسمه Shay ، على نظام SIV بارد يضيف طبقة من الحماية ضد هذه المشكلة. ولكن إذا كنت تستخدم جهاز IV فريدًا ، فإن التشفير الحديث آمن جدًا. وهذا يعني أنه يمكنك نشر النص المشفر في صحيفة نيويورك تايمز ، ولا يمكن لأحد كسره. سيبقى الوصول إلى الشفرات حتى إذا كان جزء "النص" معروفًا. على سبيل المثال ، في بروتوكولات الإنترنت ، يُعرف مقدار كبير من النص. تستجيب خوادم HTTP دائمًا كما هو معروف دائمًا البايتات الأولى. لكن هذه الحقيقة لا تهم على الإطلاق - لن تساعد المهاجم في العثور على قطعة واحدة من البيانات المتبقية ... لقد قطعنا شوطًا طويلاً منذ الحرب العالمية الثانية.
ولكن هناك هجمات هذا العمل! إذا قمت بإرسال البيانات عبر شبكة وتعقب شخص ما وقت الرسائل وحجمها ، فيمكن حينئذٍ كسر البيانات المشفرة باستخدام تحليل حركة المرور.

دعونا معرفة طول أولا. من الواضح أن الطول ليس خاصية خفية. وهذا أمر طبيعي إذا كنت تحاول حماية كلمة المرور أو رقم بطاقة الائتمان الخاصة بك في مكان ما في منتصف الرسالة. ليست مشكلة كبيرة ولكن هذا يعني أنه يمكن لأي شخص تحديد نوع المحتوى الذي ترسله. مثال بسيط: إذا قمت بإرسال gif باستخدام برنامج messenger وإذا كان حجم هذه الصورة فريدًا ، فقد يشير المهاجم الذي اعترض بياناتك إلى GIF الذي تم إرساله للتو. هناك إصدارات أكثر صعوبة من هذا الهجوم في خرائط Google و Netflix و Wikipedia ، إلخ. للحماية من هذا الهجوم ، يمكنك "إنهاء" الرسائل المرسلة مع وحدات بايت إضافية ، بحيث تكون جميع الرسائل المرسلة بنفس الطول بغض النظر عن ما. يعمل التشفير المستخدم في الشبكات العسكرية دائمًا على "إنهاء" حركة المرور ببيانات إضافية ، أي بالنسبة للمعترض يبدو دائمًا كما هو! هناك مشكلة أخرى في الطول وهي أنه إذا كنت تستخدم الضغط وتمنح المهاجم القدرة على تغيير أي جزء من المحتوى على الصفحة التي يراها المستخدم ، فإن ذلك يسمح للمهاجم باكتشاف حتى أصغر الأسرار. البحث عن هجوم يسمى CRIME. إنها رائعة ومخيفة.
قلت أيضا أن المشكلة الأخرى هي التوقيت. من الواضح أن وقت إرسال كل رسالة هو معلومات مفتوحة. يمكن أن يكون هذا مشكلة؟ ربما! على سبيل المثال ، إذا قمت بإرسال رسالة في كل مرة تضغط فيها على مفتاح ، فمن السهولة بمكان معرفة ما تتم طباعته بالضبط باستخدام تحليل الوقت. رائع! مثال آخر هو VOIP. إذا كان تطبيق الاتصال الخاص بك يرسل البيانات فقط عندما يتحدث الناس ، ولكن ليس أثناء الصمت ، فهذا يكفي لاستعادة 70 ٪ من الكلام باللغة الإنجليزية. فقط من الصمت. بارد مخيف.
هذه الأمثلة هي مجرد غيض من فيض. حتى عند استخدام خوارزميات ومخططات التشفير التي تتحسن منذ 80 عامًا ، لا تزال هناك ثغرات يمكن استخدامها للقضاء على الأمان. هذا هو السبب في أنه من المفيد معرفة ذلك!
هذا ما قد يكون ، وهذا هو مستوى التفسير الذي أريد أن أتطرق إليه الآن ، لكننا نظرنا في الأشياء الأكثر أهمية التي يجب معرفتها. إذا قرأت ما يصل إلى هذه النقطة - شكرا! يجب أن يكون لديك الآن فهم أكبر لما يحدث أثناء التشفير وما يجب الانتباه إليه.
لا تتردد في طرح الأسئلة.
تم نشر الترجمة بموجب رخصة CC BY-NC-SA 4.0