المجموعة 7

هذه أولى مجموعتين ولّدناهما بعد المجموعات الست الأصلية.

وخلافًا للمجموعات القليلة الماضية، هذه المجموعة خليط متنوع. وتتضمن أيضًا بعض التحديات القليلة التي لا فائدة لها على الأرجح ضد أهداف واقعية (كانت ممتعة بما يكفي لتُضمَّن على أي حال). وفي المقابل، نضمّن أيضًا تحدٍّا يحاكي هجوم CRIME على TLS.

هذه المجموعة صعبة. فيها قدر كبير من البرمجة، وهجوم Wang تحديدًا صعب بمستوى كل ما فعلناه.

49. تزوير رسائل CBC-MAC

لنتحدث عن CBC-MAC.

CBC-MAC هكذا:

1. خذ النص الصريح P.
2. شفّر P بـ CBC تحت المفتاح K، فينتج النص المشفَّر C.
3. اطرح كل C ما عدا الكتلة الأخيرة C[n].
4. C[n] هو رمز المصادقة (MAC).

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

message || IV || MAC

والرسالة تبدو هكذا:

from=#{from_id}&to=#{to_id}&amount=#{amount}

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

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

وينبغي أن تتيح الواجهة الشبكية للمهاجم توليد رسائل صالحة لحسابات يتحكم بها. (تحرّر في تنقية المعاملات إن كنت شديد التدقيق.) افترض أن المهاجم في وضع يتيح له التقاط الرسائل من العميل إلى خادم API وفحصها.

أمر واحد لم نناقشه هو متجه التهيئة. افترض أن العميل يولّد متجه تهيئة لكل رسالة ويرسله مع رمز المصادقة. هكذا يعمل CBC، صحيح؟

خطأ.

بالنسبة إلى الرسائل الموقّعة بـ CBC-MAC، يكون متجه التهيئة الخاضع لسيطرة المهاجم خطرًا. لماذا؟ لأنه يمنح سيطرة كاملة على الكتلة الأولى من الرسالة.

استخدم هذه الحقيقة لتوليد رسالة تحوّل مليون من عملة «سبيس باكس» من حساب ضحية مستهدف إلى حسابك.

سأنتظر. أخبرني فقط عندما تنتهي.

... في الانتظار

... في الانتظار

... في الانتظار

انتهيت؟ رائع --- كنت أعلم أنك قادر!

الآن لنضبط ذلك البروتوكول قليلًا.

كما نعلم الآن، من المفترض أن تستخدم متجه تهيئة ثابتًا مع CBC-MAC، فلنفعل ذلك. سنضبط متجهنا على 0 للتبسيط. هذا يعني أن متجه التهيئة يخرج من البروتوكول:

message || MAC

بسيط جدًا، لكن سنعدّل الرسالة أيضًا. لأغراض الكفاءة، يريد البنك أن يعالج معاملات متعددة في طلب واحد. لذا تبدو الرسالة الآن هكذا:

from=#{from_id}&tx_list=#{transactions}

مع تنسيق قائمة المعاملات هكذا:

to:amount(;to:amount)*

لا يزال هناك ضعف هنا: رمز المصادقة عرضة لهجمات تمديد الطول. كيف؟

حسنًا، مخرج CBC-MAC هو متجه تهيئة صالح لرسالة جديدة.

«لكننا لا نتحكم في متجه التهيئة بعد الآن!»

بإتقان كافٍ لـ CBC، يمكننا تزييف ذلك.

مهمتك: التقط رسالة صالحة من المستخدم المستهدف. استخدم تمديد الطول لإضافة معاملة تدفع لحساب المهاجم مليون من عملة «سبيس باكس».

تلميح!

سيكون هذا أسهل بكثير لو كانت لديك سيطرة كاملة على الكتلة الأولى من رسالتك، أليس كذلك؟ ربما يمكنك محاكاة ذلك.

طعام للفكر: كيف تعدّل البروتوكول لمنع هذا؟

50. التجزئة باستخدام CBC-MAC

يحاول الناس أحيانًا استخدام CBC-MAC كدالة تجزئة.

هذه فكرة سيئة. يشرح Matt Green:

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

لنجرّب تمرينًا بسيطًا.

تُستخدم دوال التجزئة غالبًا للتحقق من الشيفرة. هذه القطعة من JavaScript (مع سطر جديد):

alert('MZA who was that?');

تجزئتها هي 296b8d7cb78a243dda4d0a61d33bbdd1 تحت CBC-MAC بمفتاح "YELLOW SUBMARINE" ومتجه تهيئة 0.

زوّر قطعة JavaScript صالحة تُنبّه "Ayo, the Wu is back!" ولها التجزئة نفسها. تأكد من أنها تعمل في متصفح.

نقاط إضافية

اكتب شيفرة JavaScript تنزّل ملفك، وتتحقق من CBC-MAC الخاص به، وتُدخله في DOM فقط إذا طابق التجزئة المتوقعة.

51. هجمات القناة الجانبية على نسبة الضغط

غالبًا ما يُضغط مرور الإنترنت لتوفير النطاق الترددي. حتى وقت قريب، تضمن ذلك ترويسات HTTPS، وما زال يشمل محتويات الاستجابات.

لماذا يهم ذلك؟

حسنًا، إن كنت مهاجمًا تملك:

1. معرفة جزئية بالنص الصريح و
2. سيطرة جزئية على النص الصريح و
3. وصولًا إلى أوراكل ضغط (compression oracle)

فلديك فرصة جيدة لاستعادة أي نص صريح إضافي مجهول.

ما أوراكل الضغط؟ تعطيه إدخالًا ما فيخبرك بمدى جودة ضغط الرسالة كاملة، أي طول المخرج الناتج.

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

السيناريو: أنت تنفّذ هجوم وسيط بهدف سرقة كوكيز جلسة آمنة. حقنت محتوى خبيثًا يتيح لك توليد طلبات اعتباطية ومراقبتها أثناء مرورها. (التفاصيل ليست مهمة كثيرًا، امضِ معها فقط.)

إذن! اكتب هذا الأوراكل:

oracle(P) -> length(encrypt(compress(format_request(P))))

نسّق الطلب هكذا:

POST / HTTP/1.1
Host: hapless.com
Cookie: sessionid=TmV2ZXIgcmV2ZWFsIHRoZSBXdS1UYW5nIFNlY3JldCE=
Content-Length: ((len(P)))
((P))

(تظاهر بأنك لا تستطيع رؤية معرّف الجلسة ذلك. أنت المهاجم.)

اضغط باستخدام zlib أو أي شيء آخر.

التشفير... غير مهم فعليًا لأغراضنا، لكن كن رياضيًا حسنًا. استخدم أي شيفرة تيار. الخيار لك. مفتاح/متجه تهيئة عشوائي في كل نداء إلى الأوراكل.

ثم أعِد الطول بالبايتات فقط.

الآن، الفكرة هنا هي تسريب معلومات باستخدام مكتبة الضغط. حمولة "sessionid=T" ينبغي أن تُضغط أفضل قليلًا من، لنقل، "sessionid=S".

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

وقد تحصل أيضًا على بعض الإيجابيات الكاذبة العارضة.

لكن لا تقلق! لدي ثقة كاملة فيك.

استخدم أوراكل الضغط لاستعادة معرّف الجلسة.

سأنتظر.

فهمته؟ رائع.

الآن استبدل شيفرة التيار لديك بـ CBC وأعد العملية.

52. تصادمات متعددة في دوال التجزئة المتكررة

وبينما نحن في موضوع دوال التجزئة...

الميزة الكبرى التي تريدها في دالة التجزئة هي مقاومة التصادم. أي ينبغي أن يكون صعبًا توليد تصادمات، وينبغي أن يكون صعبًا حقًا توليد تصادم لتجزئة معينة (أي الصورة الأولية).

لدى دوال التجزئة المتكررة مشكلة: الجهد اللازم لتوليد الكثير من التصادمات يتناقص دون الخطية.

ما دالة التجزئة المتكررة؟ في كل الأغراض العملية، نتحدث عن تركيب Merkle-Damgard. يبدو هكذا:

function MD(M, H, C):
  for M[i] in pad(M):
    H := C(M[i], H)
  return H

من أجل الرسالة M، والحالة الابتدائية H، ودالة الضغط C.

ينبغي أن يبدو هذا مألوفًا جدًا، لأن SHA-1 وMD4 كلتاهما من هذه الفئة. والممتع أنه يمكنك استخدام هذه الصيغة لبناء دالة تجزئة مؤقتة من بعض أوليات التشفير المتوفرة لديك (مثلًا C = AES-128).

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

كيف؟ من أجل حالة H معينة، اعثر على كتلتين تتصادمان. الآن خذ التجزئة الناتجة من هذا التصادم كقيمة H جديدة وكرّر. لاحظ أنه مع كل تكرار يمكنك فعليًا مضاعفة تصادماتك باستبدال أي من الكتلتين في ذلك الموضع.

هذا يعني أنه إن كان العثور على رسالتين متصادمتين يستغرق جهدًا قدره 2^(b/2) (حيث b حجم دالة التجزئة بالبتّات)، فإن العثور على 2^n رسالة متصادمة يستغرق جهدًا قدره n*2^(b/2) فقط.

لنختبر ذلك. أولًا، ابنِ دالة تجزئة MD خاصة بك. سنولّد قدرًا هائلًا من التصادمات، فلا تُجهِد نفسك. بل اجهد عمدًا في جعلها سيئة. إليك طريقة:

1. خذ شيفرة كتل سريعة واستخدمها كـ C.
2. اجعل H صغيرة جدًا. لن أنظر إليك بدونية إن كانت 16 بتًا فقط. اختر قيمة H ابتدائية ما.
3. ستكون H مفتاح الإدخال وكتلة الخرج من C. هذا يعني أنك ستحتاج إلى حشوها عند الدخول وإسقاط بتّات عند الخروج.

الآن اكتب الدالة f(n) التي تولّد 2^n تصادمًا في دالة التجزئة هذه.

لماذا يهم هذا؟ حسنًا، أحد الأسباب أن الناس حاولوا تقوية دوال التجزئة بتسلسلها معًا. إليك ما أعني:

1. خذ دالتي التجزئة f وg.
2. ابنِ h بحيث h(x) = f(x) || g(x).

الفكرة أنه إن كانت التصادمات في f تكلف 2^(b1/2) والتصادمات في g تكلف 2^(b2/2)، فينبغي أن تبلغ التصادمات في h المبلغ الزهيد 2^((b1+b2)/2).

لكننا نعلم الآن أن هذا غير صحيح!

وإليك الفكرة:

1. اختر دالة التجزئة «الأرخص». لنفترض أنها f.
2. ولّد 2^(b2/2) رسالة متصادمة في f.
3. هناك فرصة جيدة أن مجموعة رسائلك فيها تصادم في g.
4. اعثر عليه.

وإن لم يوجد، فواصل توليد التصادمات الرخيصة حتى تجده.

أثبت هذا ببناء دالة تجزئة أكثر تكلفة (لكن ليست مكلفة جدًا) لتقرنها بالتي استخدمتها للتو. اعثر على زوج من الرسائل يتصادم تحت الدالتين. قِس العدد الإجمالي للنداءات إلى دالة التصادم.

53. الرسائل القابلة للتوسع لدى Kelsey وSchneier

من المقاييس الأساسية التي نحكم بها على دالة تجزئة تشفيرية مقاومتها لهجمات الصورة الأولية الثانية. وهذا يعني أنه إن أعطيتك x وy بحيث H(x) = y، فينبغي أن تجد صعوبة في إيجاد x' بحيث H(x') = H(x) = y.

ما مقدار الصعوبة؟ صعوبة القوة الغاشمة. بالنسبة إلى دالة تجزئة بـ 2^b، نريد أن تكلّف هجمات الصورة الأولية الثانية 2^b عملية.

وتبيّن أن هذا ليس الحال مع الرسائل الطويلة جدًا.

لنتأمل المسألة التي نحاول حلها: نريد إيجاد رسالة تتصادم مع H(x) في الكتلة الأخيرة تحديدًا. لكن هناك وفرة من الكتل الوسيطة، ولكل منها حالة تجزئة وسيطة خاصة بها.

ماذا لو استطعنا التصادم مع إحداها؟ يمكننا حينها إلحاق كل الكتل التالية من الرسالة الأصلية لإنتاج H(x) الأصلي. تقريبًا.

لا يمكننا فعل هذا بدقة لأن الحشو سيعبث بالأمر.

ما نحتاجه هو رسائل قابلة للتوسع.

في المسألة السابقة استخدمنا التصادمات المتعددة لإنتاج 2^n رسالة متصادمة بجهد n*2^(b/2). يمكننا استخدام المبادئ نفسها لإنتاج مجموعة رسائل بطول (k, k + 2^k - 1) من أجل k معين.

إليك الطريقة:

• بدءًا من الحالة الابتدائية لدالة التجزئة، اعثر على تصادم بين رسالة من كتلة واحدة ورسالة من 2^(k-1)+1 كتلة. لا تجزّئ الرسالة الطويلة كاملة في كل مرة. اختر 2^(k-1) كتلة وهمية، وجزّئها، ثم ركّز على الكتلة الأخيرة.
• خذ حالة الخرج من الخطوة الأولى. استخدمها كحالتك الابتدائية الجديدة واعثر على تصادم آخر بين رسالة من كتلة واحدة ورسالة من 2^(k-2)+1 كتلة.
• أعد هذه العملية k مرة إجمالًا. ينبغي أن يكون تصادمك الأخير بين رسالة من كتلة واحدة ورسالة من 2^0+1 = 2 كتلة.

الآن يمكنك إنشاء رسالة بأي طول في (k, k + 2^k - 1) كتلة باختيار الرسالة المناسبة (القصيرة أو الطويلة) من كل زوج.

الآن نحن مستعدون لمهاجمة رسالة طويلة M من 2^k كتلة.

1. ولّد رسالة قابلة للتوسع بطول (k, k + 2^k - 1) باستخدام الاستراتيجية الموضحة أعلاه.
2. جزّئ M وولّد خريطة من حالات التجزئة الوسيطة إلى مؤشرات الكتل التي تقابلها.
3. من الحالة النهائية لرسالتك القابلة للتوسع، اعثر على «جسر» من كتلة واحدة إلى حالة وسيطة في خريطتك. لاحظ المؤشر i الذي يقابلها.
4. استخدم رسالتك القابلة للتوسع لتوليد بادئة بالطول الصحيح بحيث len(prefix || bridge || M[i..]) = len(M).

ينبغي أن يكون الحشو في الكتلة الأخيرة صحيحًا الآن، وينبغي أن تتصادم رسالتك المزوّرة مع القيمة نفسها لـ M.

54. هجوم نوستراداموس لدى Kelsey وKohno

تُستخدم دوال التجزئة أحيانًا كإثبات على تنبؤ سري.

على سبيل المثال، افترض أنك أردت التنبؤ بنتيجة كل مباراة في دوري كرة القاعدة الرئيسي خلال موسم. (2,430 مباراة في المجموع.) قد تقلق من أن نشر تنبؤاتك سيؤثر على النتائج.

لذا بدلًا من ذلك تكتب كل النتائج، وتجزّئ المستند، وتنشر التجزئة. وبعد انتهاء الموسم، تنشر المستند. ويستطيع الجميع حينها تجزئة المستند للتحقق من مهارتك في التنبؤ.

لكن ماذا لو لم تستطع التنبؤ بدقة بنتائج 2.4 ألف مباراة كرة قاعدة؟ لا تخف --- تزوير تنبؤ في هذا المخطط يختزل إلى هجوم صورة أولية ثانية آخر.

يمكننا تطبيق هجوم الرسالة الطويلة من المسألة السابقة، لكنه سيبدو مريبًا جدًا. هل تثق بشخص خرجت رسالته المتنبأة بطول 2^50 بايت؟

وتبيّن أننا نستطيع تنفيذ هجوم ناجح بلاحقة أقصر بكثير. تأمل الطريقة:

1. ولّد عددًا كبيرًا من حالات التجزئة الابتدائية. لنقل 2^k.
2. ازوجها وولّد تصادمات من كتلة واحدة. الآن لديك 2^k حالة تجزئة تتصادم في 2^(k-1) حالة.
3. أعد العملية. ازوج الحالات 2^(k-1) وولّد تصادمات. الآن لديك 2^(k-2) حالة.
4. واصل هذا حتى تحصل على حالة واحدة. هذا هو تنبؤك.
5. حسنًا، نوعًا ما. تحتاج إلى الالتزام بطول ما لتشفّره في الحشو. تأكد من أنه طويل بما يكفي لاستيعاب رسالتك الفعلية، وهذه اللاحقة، وقليل من الغراء لضمّها. جزّئ كتلة الحشو هذه باستخدام الحالة من الخطوة 4 --- هذا هو تنبؤك.

ما الذي بنيته للتو؟ إنه أساسًا قمع يربط حالات ابتدائية كثيرة بحالة نهائية مشتركة. المهم أن لدينا الآن حقلًا واسعًا من 2^k حالة يمكننا محاولة التصادم معها، لكن اللاحقة الفعلية لن تتجاوز k+1 كتلة.

الباقي بديهي:

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

ستكون الصعوبة هنا نحو 2^(b-k). وبرفع أو خفض k في مرحلة توليد الشجرة، يمكنك ضبط صعوبة هذه الخطوة. من المنطقي على الأرجح بذل جهد أكبر مقدمًا، لأن الناس سينتظرونك لتزويدهم برسالتك بعد انتهاء الحدث. تنبؤ سعيد!

55. تصادمات MD4

MD4 دالة تجزئة تشفيرية بـ 128 بتًا، ما يعني أنه ينبغي أن يستغرق العثور على تصادمات جهدًا يقارب 2^64.

وتبيّن أننا نستطيع فعل ما هو أفضل بكثير.

تفصّل ورقة «Cryptanalysis of the Hash Functions MD4 and RIPEMD» لـ Wang وآخرين هجومًا تحليليًا تشفيريًا يتيح لنا إيجاد تصادمات في 2^8 أو أقل.

بالنظر إلى كتلة رسالة M، يوضّح Wang استراتيجية لإيجاد كتلة رسالة شقيقة M'، تختلف في بضع بتّات فقط، وتتصادم معها. بشرط أن تتحقق مجموعة قصيرة من الشروط في M.

أي شروط؟ مساوات بتّية بسيطة داخل حالة دالة التجزئة الوسيطة، مثل a[1][6] = b[0][6]. ينبغي قراءة هذا هكذا: «يجب أن تتساوى البتّة السادسة (بترقيم يبدأ من الصفر) من a[1] (أي أول تحديث لـ 'a') مع البتّة السادسة من b[0] (أي القيمة الابتدائية لـ 'b')».

وتبيّن أن كثيرًا من هذه الشروط بديهي فرضه. لترى لماذا، ألقِ نظرة على الأولى (من ثلاث) من الجولات في دالة ضغط MD4. في هذه الجولة، نكرّر على كل كلمة في كتلة الرسالة بالتتابع ونمزجها في الحالة. لذا يمكننا التأكد من تحقق كل شروط الجولة الأولى بفعل هذا:

# calculate the new value for a[1] in the normal fashion
a[1] = (a[0] + f(b[0], c[0], d[0]) + m[0]).lrot(3)

# correct the erroneous bit
a[1] ^= ((a[1][6] ^ b[0][6]) << 6)

# use algebra to correct the first message block
m[0] = a[1].rrot(3) - a[0] - f(b[0], c[0], d[0])

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

بعد أن تدلّك M بالقدر الكافي، يمكنك ببساطة توليد M' بقلب بضع بتّات واختبار التصادم. التصادم غير مضمون لأننا لم نضمن كل شرط. لكن نأمل أننا حققنا ما يكفي لإيجاد زوج (M, M') مناسب دون جهد كبير.

نفّذ هجوم Wang.

56. انحيازات البايت الواحد في RC4

RC4 شيفرة تيار شائعة، تشتهر باستخدامها في بروتوكولات مثل TLS وWPA وRDP وما إلى ذلك.

وهي أيضًا عرضة لانحيازات كبيرة في البايت الواحد، خصوصًا في بداية تيار المفاتيح. ماذا يعني ذلك؟

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

الآن، ابحث على الإنترنت عن «On the Security of RC4 in TLS and WPA». هذا الموقع هو متجرك الشامل لمعلومات RC4.

انقر وصولًا إلى «RC4 biases» (انحيازات RC4) على اليمين.

هذه رسوم بيانية لكل انحياز بايت واحد (رسم لكل صفحة). لاحظ خصوصًا الطفرات الهائلة عند z16 وz32 وz48 وما إلى ذلك. (ملاحظة: الترقيم يبدأ من الواحد، لذا z16 = keystream[15].)

ما مدى فائدة هذه الانحيازات؟

انقر وصولًا إلى ورقة البحث ومرّر لأسفل إلى نتائج المحاكاة. (بالمناسبة، الورقة كاملة قراءة جيدة إن كان لديك وقت فراغ.) نبدأ بطفرات واضحة عند 2^26 تكرار، لكن فرصنا في استعادة كل واحد من أول 256 بايت تقترب من 1 كلما اتجهنا نحو 2^32.

هناك طريقتان للاستفادة من هذه الانحيازات. الطريقة الأولى بسيطة جدًا:

1. اكتسب معرفة شاملة بانحيازات تيار المفاتيح.
2. شفّر النص الصريح المجهول 2^30+ مرة تحت مفاتيح مختلفة.
3. قارن انحيازات النص المشفَّر بانحيازات تيار المفاتيح.

يتطلب فعل ذلك معرفة عميقة بالانحيازات لكل بايت من تيار المفاتيح. لكن تبيّن أننا نستطيع أداءً جيدًا جدًا بانحيازات قليلة مفيدة --- إن كانت لدينا بعض السيطرة على النص الصريح.

كيف؟ باستخدام معرفة انحياز واحد ككوة نطل منها على النص الصريح.

فك ترميز هذا السر:

QkUgU1VSRSBUTyBEUklOSyBZT1VSIE9WQUxUSU5F

وسمِّه كوكيز. ممنوع التلصص!

الآن استخدمه لبناء أوراكل التشفير هذا:

RC4(your-request || cookie, random-key)

استخدم مفتاحًا جديدًا بطول 128 بتًا في كل نداء.

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

يمكنك التحكم في موضع الكوكيز بطلب "/" و"/A" و"/AA" وهكذا.

ابنِ خرائط انحياز لبضعة مؤشرات مختارة (z16 وz32 جيدان) وفك تشفير الكوكيز.