كيفية اختيار وضع تشفير AES (CBC ECB CTR OCB CFB)؟

Question

أي منهم يفضل وفي أي الظروف؟

أود أن أرى قائمة معايير التقييم لمختلف الأوضاع، وربما مناقشة إمكانية تطبيق كل معيار.

على سبيل المثال ، أعتقد أن أحد المعايير هو "حجم الكود" للتشفير وفك التشفير ، وهو أمر مهم للأنظمة المضمنة الرمز الصغير ، مثل محولات شبكة 802.11.إذا كان الكود المطلوب لتنفيذ CBC أصغر بكثير من ذلك المطلوب لنسبة النقر إلى الظهور (لا أعلم أن هذا صحيح، إنه مجرد مثال)، فيمكنني أن أفهم سبب تفضيل الوضع ذو الكود الأصغر.ولكن إذا كنت أكتب تطبيقًا يعمل على خادم، ومكتبة AES التي أستخدمها تنفذ كلاً من CBC وCTR على أي حال، فإن هذا المعيار ليس له أي صلة.

انظر ماذا أقصد بـ "قائمة معايير التقييم وقابلية تطبيق كل معيار"؟؟

هذا ليس متعلقًا بالبرمجة حقًا ولكنه متعلق بالخوارزمية.

Answer 1

• لا ينبغي استخدام البنك المركزي الأوروبي في حالة تشفير أكثر من كتلة واحدة من البيانات بنفس المفتاح.

• تتشابه CBC وOFB وCFB، إلا أن OFB/CFB أفضل لأنك تحتاج فقط إلى التشفير وليس فك التشفير، مما يمكن أن يوفر مساحة التعليمات البرمجية.

• يتم استخدام نسبة النقر إلى الظهور (CTR) إذا كنت تريد موازاة جيدة (على سبيل المثال.السرعة)، بدلاً من CBC/OFB/CFB.

• يعد وضع XTS هو الوضع الأكثر شيوعًا إذا كنت تقوم بتشفير بيانات عشوائية يمكن الوصول إليها (مثل القرص الصلب أو ذاكرة الوصول العشوائي).

• يعد OCB هو الوضع الأفضل على الإطلاق، لأنه يسمح بالتشفير والمصادقة في مسار واحد.ولكن هناك براءات اختراع عليه في الولايات المتحدة الأمريكية.

الشيء الوحيد الذي يجب أن تعرفه حقًا هو أنه لا ينبغي استخدام البنك المركزي الأوروبي إلا إذا كنت تقوم بتشفير كتلة واحدة فقط.يجب استخدام XTS إذا كنت تقوم بتشفير البيانات التي تم الوصول إليها عشوائيًا وليس الدفق.

• يجب عليك دائما استخدام فريدة من نوعها رابعافي كل مرة تقوم فيها بالتشفير، ويجب أن تكون كذلك عشوائي.إذا كنت لا تستطيع ضمان أنهم كذلك عشوائي, ، استخدم OCB لأنه يتطلب فقط ملف nonce, ، ليس رابعا, ، وهناك فرق واضح.أ nonce لا يسقط الأمن إذا تمكن الناس من تخمين التالي، أ رابعا يمكن أن يسبب هذه المشكلة.

Answer 2

يرجى التفكير طويلاً وشاقًا إذا لم تتمكن من تنفيذ التشفير الخاص بك

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

اسمحوا لي أن أوضح وجهة نظري:تخيل أنك تقوم بإنشاء تطبيق ويب وتحتاج إلى تخزين بعض بيانات الجلسة.يمكنك تعيين معرف جلسة لكل مستخدم وتخزين بيانات الجلسة على الخادم في خريطة تجزئة لتعيين معرف الجلسة لبيانات الجلسة.ولكن بعد ذلك يتعين عليك التعامل مع هذه الحالة المزعجة على الخادم، وإذا كنت في مرحلة ما تحتاج إلى أكثر من خادم واحد، فستصبح الأمور فوضوية.لذا بدلاً من ذلك، لديك فكرة تخزين بيانات الجلسة في ملف تعريف الارتباط من جانب العميل.ستقوم بتشفيرها بالطبع حتى لا يتمكن المستخدم من قراءة البيانات ومعالجتها.إذن ما هو الوضع الذي يجب أن تستخدمه؟أتيت إلى هنا لتقرأ الإجابة العليا (آسف لتمييزك عن myforwik).الأول المغطى - ECB - ليس مناسبًا لك، فأنت تريد تشفير أكثر من كتلة واحدة، والتالي - CBC - يبدو جيدًا ولا تحتاج إلى توازي نسبة النقر إلى الظهور، ولا تحتاج إلى وصول عشوائي، لذلك لا XTS وبراءات الاختراع هي عبارة عن PITA، لذا لا يوجد OCB.باستخدام مكتبة التشفير الخاصة بك، ستدرك أنك بحاجة إلى بعض الحشو لأنه يمكنك فقط تشفير مضاعفات حجم الكتلة.اختار أنت PKCS7 لأنه تم تعريفه في بعض معايير التشفير الجادة.بعد القراءة في مكان ما أن CBC موجود آمنة بشكل مؤكد إذا تم استخدامه مع IV عشوائي وتشفير كتلة آمن، فستكون مرتاحًا على الرغم من قيامك بتخزين بياناتك الحساسة على جانب العميل.

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

وهذا ليس سيناريو افتراضيا: كان لدى Microsoft هذا الخلل الدقيق في ASP.NET حتى سنوات قليلة مضت.

تكمن المشكلة في وجود الكثير من المزالق المتعلقة بالتشفير، ومن السهل جدًا إنشاء نظام يبدو آمنًا للشخص العادي، ولكن من السهل جدًا كسره بالنسبة لمهاجم واسع المعرفة.

ماذا تفعل إذا كنت بحاجة إلى تشفير البيانات

بالنسبة للاتصالات المباشرة، استخدم TLS (تأكد من التحقق من اسم مضيف الشهادة وسلسلة المُصدر).إذا لم تتمكن من استخدام TLS، فابحث عن واجهة برمجة التطبيقات (API) ذات المستوى الأعلى التي يجب أن يقدمها نظامك لمهمتك وتأكد من فهمك للضمانات التي يقدمها، والأهم من ذلك ما لا يضمنه.على سبيل المثال أعلاه إطار مثل يلعب عروض مرافق التخزين من جانب العميل, ومع ذلك، فإنه لا يبطل البيانات المخزنة بعد مرور بعض الوقت، وإذا قمت بتغيير الحالة من جانب العميل، فيمكن للمهاجم استعادة الحالة السابقة دون أن تلاحظ.

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

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

مقارنة الأوضاع

التشفير فقط:

• الأوضاع التي تتطلب الحشو:كما هو الحال في المثال، يمكن أن يكون الحشو خطيرًا بشكل عام لأنه يفتح إمكانية حدوث هجمات أوراكل.أسهل دفاع هو مصادقة كل رسالة قبل فك التشفير.انظر أدناه.
  • البنك المركزي الأوروبي يقوم بتشفير كل كتلة من البيانات بشكل مستقل وستؤدي نفس كتلة النص العادي إلى نفس كتلة النص المشفر.ألق نظرة على صورة Tux المشفرة للبنك المركزي الأوروبي على صفحة البنك المركزي الأوروبي على ويكيبيديا لنرى لماذا هذه مشكلة خطيرة.لا أعرف أي حالة استخدام يكون فيها البنك المركزي الأوروبي مقبولاً.
  • سي بي سي يحتوي على IV وبالتالي يحتاج إلى العشوائية في كل مرة يتم فيها تشفير الرسالة، يتطلب تغيير جزء من الرسالة إعادة تشفير كل شيء بعد التغيير، أخطاء الإرسال في كتلة نص مشفر واحدة تدمر النص العادي تمامًا وتغير فك تشفير الكتلة التالية، يمكن فك التشفير يكون متوازيًا / لا يمكن التشفير، النص العادي مرن إلى درجة معينة - هذا يمكن أن يكون مشكلة.
• أوضاع تشفير الدفق:تولد هذه الأوضاع دفقًا عشوائيًا زائفًا من البيانات التي قد تعتمد أو لا تعتمد على النص العادي.على نحو مشابه لشفرات الدفق عمومًا، يتم XORed للتيار العشوائي الزائف الذي تم إنشاؤه مع النص العادي لإنشاء النص المشفر.نظرًا لأنه يمكنك استخدام أي عدد تريده من أجزاء الدفق العشوائي، فلن تحتاج إلى الحشو على الإطلاق.عيب هذه البساطة هو أن التشفير كامل طيع, ، مما يعني أنه يمكن للمهاجم تغيير فك التشفير بأي طريقة يريدها بالنسبة للنص العادي p1 والنص المشفر c1 والدفق العشوائي الزائف r ويمكن للمهاجم اختيار اختلاف d بحيث يكون فك تشفير النص المشفر c2=c1⊕d هو p2 = p1⊕d، كما p2 = c2⊕r = (c1 ⊕ د) ⊕ r = d ⊕ (c1 ⊕ r).كما يجب أيضًا عدم استخدام نفس الدفق العشوائي الزائف مرتين أبدًا كما هو الحال بالنسبة للنصين المشفرين c1=p1⊕r وc2=p2⊕r، حيث يمكن للمهاجم حساب xor للنصين العاديين على النحو التالي c1⊕c2=p1⊕r⊕p2⊕r= ص1⊕ص2.وهذا يعني أيضًا أن تغيير الرسالة يتطلب إعادة تشفير كاملة، إذا كان من الممكن أن يحصل المهاجم على الرسالة الأصلية.تحتاج جميع أوضاع التشفير البخاري التالية فقط إلى عملية التشفير الخاصة بالتشفير الكتلي، لذا اعتمادًا على التشفير، قد يوفر هذا بعض المساحة (السيليكون أو كود الآلة) في بيئات مقيدة للغاية.
  • نسبة النقر إلى الظهور الأمر بسيط، فهو ينشئ دفقًا عشوائيًا زائفًا مستقلاً عن النص العادي، ويتم الحصول على تدفقات عشوائية زائفة مختلفة عن طريق العد التصاعدي من مختلف الحروف noces/IVs والتي يتم ضربها بالحد الأقصى لطول الرسالة بحيث يتم منع التداخل، ومن الممكن استخدام تشفير الرسائل noces بدون عشوائية لكل رسالة، يتم إكمال فك التشفير والتشفير بشكل متوازي، وتؤثر أخطاء الإرسال فقط على البتات الخاطئة ولا شيء أكثر من ذلك
  • OFB ينشئ أيضًا دفقًا عشوائيًا زائفًا مستقلاً عن النص العادي، ويتم الحصول على تدفقات عشوائية زائفة مختلفة من خلال البدء بـ nonce أو IV عشوائي مختلف لكل رسالة، ولا يمكن موازاة التشفير أو فك التشفير، كما هو الحال مع نسبة النقر إلى الظهور (CTR)، فإن استخدام تشفير الرسائل غير ممكن بدون عشوائية لكل رسالة ، كما هو الحال مع أخطاء إرسال نسبة النقر إلى الظهور (CTR) تؤثر فقط على البتات الخاطئة وليس أكثر
  • CFBيعتمد الدفق العشوائي الزائف لـ على النص العادي، وهناك حاجة إلى رقم مختلف أو IV عشوائي لكل رسالة، كما هو الحال مع نسبة النقر إلى الظهور وOFB، حيث يمكن استخدام تشفير الرسائل بدون عشوائية لكل رسالة، وفك التشفير قابل للتوازي / التشفير غير ممكن، وأخطاء الإرسال تدمر تمامًا الكتلة التالية، ولكنها تؤثر فقط على البتات الخاطئة في الكتلة الحالية
• أوضاع تشفير القرص:هذه الأوضاع مخصصة لتشفير البيانات الموجودة أسفل تجريد نظام الملفات.لأسباب تتعلق بالكفاءة، يجب أن يتطلب تغيير بعض البيانات الموجودة على القرص إعادة كتابة كتلة قرص واحدة على الأكثر (512 بايت أو 4 كيلو بايت).إنهم خارج نطاق هذه الإجابة لأن لديهم سيناريوهات استخدام مختلفة تمامًا عن الأخرى. لا تستخدمها لأي شيء باستثناء تشفير القرص على مستوى الكتلة.بعض الأعضاء:إكس إي إكس، إكس تي إس، إل آر دبليو.

التشفير المعتمد:

لمنع حشو هجمات أوراكل والتغييرات في النص المشفر، يمكن للمرء حساب رمز مصادقة الرسالة (MAC) على النص المشفر وفك تشفيره فقط إذا لم يتم العبث به.وهذا ما يسمى تشفير ثم ماك و ينبغي أن يفضل على أي أمر آخر.وباستثناء حالات استخدام قليلة جدًا، فإن الأصالة لا تقل أهمية عن السرية (والأخيرة هي هدف التشفير).تجمع أنظمة التشفير المصادق عليها (مع البيانات المرتبطة (AEAD)) بين عملية التشفير والمصادقة المكونة من جزأين في وضع تشفير كتلة واحد ينتج أيضًا علامة مصادقة في العملية.في معظم الحالات، يؤدي هذا إلى تحسين السرعة.

• CCM عبارة عن مزيج بسيط من وضع نسبة النقر إلى الظهور (CTR) وCBC-MAC.يعد استخدام تشفيرين لتشفير الكتل لكل كتلة أمرًا بطيئًا للغاية.
• او سي بي أسرع ولكنه مثقل ببراءات الاختراع.مجانًا (كما هو الحال في الحرية) أو البرامج غير العسكرية صاحب براءة الاختراع منحت ترخيصًا مجانيًا, ، رغم ذلك.
• جي سي إم عبارة عن مزيج سريع للغاية ولكنه معقد للغاية بين وضع نسبة النقر إلى الظهور (CTR) وGHASH، وهو MAC فوق حقل Galois مع 2^128 عنصر.ينعكس استخدامه على نطاق واسع في معايير الشبكة المهمة مثل TLS 1.2 في أ تعليمات خاصة قدمت شركة Intel لتسريع حساب GHASH.

توصية:

بالنظر إلى أهمية المصادقة، فإنني أوصي بوضعي تشفير الكتل التاليين لمعظم حالات الاستخدام (باستثناء أغراض تشفير القرص):إذا تمت مصادقة البيانات بواسطة توقيع غير متماثل، فاستخدم CBC، وإلا فاستخدم GCM.

Answer 3

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

لاحظ أن معظم هذه العناصر تتطلب أن يكون IV عشوائيًا، مما يعني أنه لا يمكن التنبؤ به وبالتالي يجب أن يتم إنشاؤه باستخدام أمان التشفير.ومع ذلك، فإن البعض لا يتطلب سوى "nonce"، وهو ما لا يتطلب تلك الخاصية ولكن بدلاً من ذلك يتطلب فقط عدم إعادة استخدامها.لذلك فإن التصميمات التي تعتمد على nonce تكون أقل عرضة للخطأ من التصميمات التي لا تفعل ذلك (وصدقني، لقد رأيت العديد من الحالات التي لا يتم فيها تنفيذ CBC مع التحديد الوريدي المناسب).لذلك سترى أنني أضفت خطًا غامقًا عندما يقول Rogaway شيئًا مثل "لا تتحقق السرية عندما يكون IV هو nonce"، فهذا يعني أنه إذا اخترت IV الخاص بك آمنًا تشفيريًا (لا يمكن التنبؤ به)، فلا توجد مشكلة.ولكن إذا لم تقم بذلك، فإنك تفقد خصائص الأمان الجيدة. لا تعيد استخدام الوريد أبدًا لأي من هذه الأوضاع.

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

يجب أن أقول أنه على الرغم من أن GCM يتمتع بالتشفير وسلامة الرسائل، إلا أنه تصميم هش للغاية:إذا قمت بإعادة استخدام الوريد، فستكون مخطئًا - يمكن للمهاجم استعادة مفتاحك.التصميمات الأخرى أقل هشاشة، لذا أخشى شخصيًا أن أوصي بـ GCM بناءً على كمية كود التشفير الضعيف الذي رأيته عمليًا.

إذا كنت بحاجة إلى كليهما، سلامة الرسالة والتشفير، فيمكنك الجمع بين خوارزميتين:عادةً ما نرى CBC مع HMAC، ولكن لا يوجد سبب لربط نفسك بـ CBC.الشيء المهم الذي يجب معرفته هو تشفير أولاً، ثم MAC المحتوى المشفر, ، ليس العكس.أيضًا، يجب أن يكون IV جزءًا من حساب MAC.

لست على علم بقضايا الملكية الفكرية.

الآن إلى الأشياء الجيدة من البروفيسور روجواي:

أوضاع تشفير الحظر والتشفير ولكن ليس سلامة الرسالة

البنك المركزي الأوروبي:تشفير الكتل، يقوم الوضع بتشفير الرسائل التي تكون مضاعفًا لـ n بت عن طريق تشفير كل قطعة n-bit بشكل منفصل. الخصائص الأمنية ضعيفة, ، طريقة تسريب مساواة الكتل عبر مواضع الكتلة والوقت.ذات قيمة تراثية كبيرة، وقيمة باعتبارها لبنة بناء لمخططات أخرى، ولكن هذا الوضع لا يحقق أي هدف أمني مرغوب فيه بشكل عام في حد ذاته ويجب استخدامه بحذر كبير؛ ولا ينبغي لنا أن ننظر إلى البنك المركزي الأوروبي باعتباره أسلوباً للسرية "لأغراض عامة"..

سي بي سي:نظام تشفير قائم على IV، يعتبر الوضع آمنًا كنظام تشفير احتمالي، مما يحقق عدم القدرة على التمييز من البتات العشوائية، بافتراض وجود IV عشوائي. لا تتحقق السرية إذا كان IV مجرد رقم, ، ولا إذا كان رقمًا غير مشفر تحت نفس المفتاح الذي يستخدمه المخطط، كما يقترح المعيار بشكل غير صحيح.النصوص المشفرة مرنة للغاية.لم يتم اختيار أمان هجوم النص المشفر (CCA).يتم فقدان السرية في حالة وجود أوراكل الحشو الصحيح للعديد من طرق الحشو.التشفير غير فعال لأنه تسلسلي بطبيعته.تُستخدم خصائص الأمان الخاصة بالخصوصية فقط على نطاق واسع، مما يؤدي إلى سوء الاستخدام المتكرر.يمكن استخدامه ككتلة بناء لخوارزميات CBC-MAC. لا يمكنني تحديد أي مزايا مهمة مقارنة بوضع نسبة النقر إلى الظهور (CTR).

CFB:نظام تشفير قائم على IV، يعتبر الوضع آمنًا كنظام تشفير احتمالي، مما يحقق عدم القدرة على التمييز من البتات العشوائية، بافتراض وجود IV عشوائي. لا تتحقق السرية إذا كان IV يمكن التنبؤ به, ، ولا إذا تم إجراؤه بواسطة رقم غير مشفر تحت نفس المفتاح الذي يستخدمه المخطط، كما يقترح المعيار بشكل غير صحيح.النصوص المشفرة قابلة للطرق.لا يوجد أمن التقييم القطري المشترك.التشفير غير فعال لأنه تسلسلي بطبيعته.يعتمد المخطط على المعلمة s، 1 ≥ s ≥ n، عادةً s = 1 أو s = 8.غير فعال في الحاجة إلى استدعاء تشفير كتلة واحد لمعالجة البتات فقط.يحقق الوضع خاصية "المزامنة الذاتية" المثيرة للاهتمام؛يؤدي إدخال أو حذف أي عدد من أحرف s-bit في النص المشفر إلى تعطيل عملية فك التشفير الصحيحة بشكل مؤقت فقط.

OFB:نظام تشفير قائم على IV، يعتبر الوضع آمنًا كنظام تشفير احتمالي، مما يحقق عدم القدرة على التمييز من البتات العشوائية، بافتراض وجود IV عشوائي.لا تتحقق السرية إذا كان IV هو nonce، على الرغم من أن التسلسل الثابت من IVs (على سبيل المثال، العداد) يعمل بشكل جيد.النصوص المشفرة مرنة للغاية.لا يوجد أمان CCA.التشفير وفك التشفير غير فعالين لكونهما مسلسلين بطبيعتهما.يقوم أصلاً بتشفير السلاسل من أي طول بت (لا حاجة إلى الحشو).لا يمكنني تحديد أي مزايا مهمة مقارنة بوضع نسبة النقر إلى الظهور (CTR).

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

اكس تي اس:يعمل الوضع، وهو نظام تشفير قائم على IV، من خلال تطبيق تشفير كتلة قابل للتعديل (آمن كـ PRP قوي) على كل قطعة n-bit.بالنسبة للرسائل ذات الأطوال غير القابلة للقسمة على n، يتم التعامل مع الكتلتين الأخيرتين بشكل خاص.الاستخدام الوحيد المسموح به لهذا الوضع هو تشفير البيانات الموجودة على جهاز تخزين مبني على كتلة.يعد العرض الضيق لـ PRP الأساسي والمعاملة السيئة للكتل النهائية الكسرية من المشاكل.أكثر كفاءة ولكن أقل استحسانًا من تشفير الكتل الآمن PRP (الكتلة العريضة).

أجهزة MAC (تكامل الرسالة ولكن ليس التشفير)

ALG1–6:مجموعة من أجهزة MAC، جميعها تعتمد على CBC-MAC.مخططات كثيرة جدًا.بعضها آمن بشكل مثبت مثل VIL PRFs، والبعض الآخر مثل FIL PRFs، وبعضها لا يتمتع بأمان يمكن إثباته.تعترف بعض المخططات بهجمات ضارة.بعض الأوضاع مؤرخة.لا يتم الاهتمام بفصل المفاتيح بشكل كافٍ بالنسبة للأنماط التي تحتوي عليه.لا ينبغي اعتمادها بشكل جماعي، ولكن من الممكن اختيار المخططات "الأفضل" بشكل انتقائي.وسيكون من الجيد أيضًا عدم اعتماد أي من هذه الأوضاع لصالح CMAC.بعض أجهزة MAC المعتمدة على ISO 9797-1 موحدة ومستخدمة على نطاق واسع، خاصة في مجال الخدمات المصرفية.سيتم قريبًا إصدار نسخة منقحة من المعيار (ISO/IEC FDIS 9797-1:2010) [93].

سي ماك:MAC يعتمد على CBC-MAC، يكون الوضع آمنًا (حتى تاريخ الميلاد المحدد) باعتباره (VIL) PRF (بافتراض أن التشفير الأساسي هو PRP جيد).الحد الأدنى من النفقات العامة بشكل أساسي للمخطط القائم على CBCMAC.تمثل الطبيعة التسلسلية بطبيعتها مشكلة في بعض مجالات التطبيق، وقد يتطلب استخدامها مع تشفير كتلي 64 بت إعادة المفاتيح من حين لآخر.أنظف من مجموعة ISO 9797-1 لأجهزة MAC.

HMAC:MAC يعتمد على وظيفة تجزئة التشفير بدلاً من تشفير الكتل (على الرغم من أن معظم وظائف التجزئة المشفرة تعتمد في حد ذاتها على تشفير الكتل).تتمتع الآلية بحدود أمنية قوية يمكن إثباتها، وإن لم تكن من الافتراضات المفضلة.إن المتغيرات المتعددة والمترابطة بشكل وثيق في الأدبيات تجعل من الصعب فهم ما هو معروف.لم يتم اقتراح أي هجمات ضارة على الإطلاق.موحدة ومستخدمة على نطاق واسع.

جي إم إيه سي:MAC غير قائم على أساس وهو حالة خاصة لـ GCM.يرث العديد من الخصائص الجيدة والسيئة لـ GCM.ولكن عدم وجود متطلبات غير ضروري بالنسبة إلى MAC، وهنا لا يجلب سوى القليل من الفوائد.الهجمات العملية إذا تم اقتطاع العلامات إلى ≥ 64 بت ولم تتم مراقبة مدى فك التشفير وتقليصه.فشل كامل في عدم إعادة الاستخدام.الاستخدام ضمني على أي حال إذا تم اعتماد GCM.لا يوصى بالتوحيد المنفصل.

التشفير المعتمد (كل من التشفير وسلامة الرسالة)

CCM:مخطط AEAD غير القائم على NONCE يجمع بين تشفير وضع CTR و CBC-MAC الخام.تسلسلي بطبيعته، مما يحد من السرعة في بعض السياقات.آمن بشكل مؤكد، مع حدود جيدة، بافتراض أن التشفير الأساسي هو PRP جيد.البناء غير المربح الذي يؤدي المهمة بشكل واضح.أسهل في التنفيذ من GCM.يمكن استخدامه كجهاز MAC غير قائم.موحدة ومستخدمة على نطاق واسع.

جي سي إم:نظام AEAD غير قائم على أساس يجمع بين تشفير وضع CTR ووظيفة التجزئة العالمية المستندة إلى GF(2128).خصائص كفاءة جيدة لبعض بيئات التنفيذ.نتائج جيدة وآمنة مع افتراض الحد الأدنى من اقتطاع العلامات.الهجمات وحدود الأمان الضعيفة التي يمكن إثباتها في ظل وجود اقتطاع كبير للعلامات.يمكن استخدامه كجهاز MAC غير معتمد، والذي يُسمى بعد ذلك GMAC.خيار مشكوك فيه للسماح بالأرقام غير 96 بت.نوصي بتقييد الأحرف غير المسموح بها على 96 بت والعلامات على 96 بت على الأقل.موحدة ومستخدمة على نطاق واسع.

Answer 4

1. أي شيء سوى البنك المركزي الأوروبي.
2. إذا كنت تستخدم نسبة النقر إلى الظهور (CTR)، فمن الضروري أن تستخدم IV مختلفًا لكل رسالة، وإلا فسينتهي بك الأمر مع قدرة المهاجم على أخذ نصين مشفرين واستخلاص نص عادي غير مشفر مدمج.والسبب هو أن وضع نسبة النقر إلى الظهور (CTR) يحول بشكل أساسي تشفير الكتلة إلى تشفير دفق، والقاعدة الأولى لتشفير الدفق هي عدم استخدام نفس المفتاح + IV مرتين أبدًا.
3. لا يوجد فرق كبير حقًا في مدى صعوبة تنفيذ الأوضاع.تتطلب بعض الأوضاع فقط أن يعمل تشفير الكتلة في اتجاه التشفير.ومع ذلك، فإن معظم تشفير الكتل، بما في ذلك AES، لا يتطلب الكثير من التعليمات البرمجية لتنفيذ فك التشفير.
4. بالنسبة لجميع أوضاع التشفير، من المهم استخدام IVs مختلفة لكل رسالة إذا كانت رسائلك متطابقة في البايتات العديدة الأولى، ولا تريد أن يعرف المهاجم ذلك.

Answer 5

هل تبدأ من خلال قراءة المعلومات على هذا في ويكيبيديا - وسائط الشفرات كتلة عملية ؟ ثم اتبع الرابط إشارة على ويكيبيديا ل NIST: التوصية لكتلة طرق التشفير لل عملية .

Answer 6

وقد ترغب في اختيار وبناء على ما هو متاح على نطاق واسع. كان لي نفس السؤال وهنا هي نتائج بحثي محدود.

والقيود الأجهزة

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

والقيود مفتوحة المصدر

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] HTTP: //www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/ OpenAES-0.8.0.zip

Answer 7

وأنا أعلم جانب واحد: على الرغم من CBC يعطي أمنية أفضل من خلال تغيير IV لكل كتلة، انها لا ينطبق على الوصول بشكل عشوائي محتوى المشفرة (مثل قرص ثابت مشفرة)

.

وهكذا، استخدم CBC (وغيرها من وسائط متتابعة) للتيارات متتابعة والبنك المركزي الأوروبي عن وصول عشوائي.