مولّدات PRNG الآمنة تشفيريًا

يجب أن يحقق CSPRNG ما يلي: (1) عدم إمكانية التنبؤ بالبت التالي؛ فعند معرفة جميع البتات السابقة، لا يمكن التنبؤ بالبت التالي باحتمال أكبر من 1/2 + مقدار ضئيل. (2) مقاومة تمديد اختراق الحالة؛ إذ لا يكشف الاطلاع على الحالة الحالية شيئاً عن المخرجات السابقة.

يستخدم Linux ‏/dev/urandom مولد أرقام شبه عشوائية آمنًا تشفيريًا (CSPRNG) مهيأً من مجمّع الإنتروبيا. بعد التهيئة الأولية ببذرة تحتوي على 128 بت من الإنتروبيا، يصبح استخدامه آمنًا حتى عندما يكون المجمّع "فارغًا"، إذ يحافظ مولد CSPRNG على حالته الداخلية الخاصة. ويُعد getrandom() النظير الحديث لاستدعاء النظام.

استبدل Linux kernel 5.17+ مولد CSPRNG بتصميم قائم على ChaCha20. يتميز ChaCha20 بالسرعة (ولا يحتاج إلى تسريع عتادي)، ويوفر أمانًا بمستوى 256 بت، وله برهان أمان مفهوم جيدًا. تكون قيمة nonce هي العداد، ويأتي المفتاح من مجمّع الإنتروبيا.

Fortuna (Ferguson & Schneier، 2003) هو تصميم لمولد CSPRNG يحافظ على 32 مجمّعًا للإنتروبيا ويجمع الإنتروبيا باستمرار. يعيد المولد تهيئة نفسه باستخدام المجمّعات عند امتلائها. وهو مقاوم لهجمات إعادة ضبط RNG وهجمات اختراق الحالة جزئيًا.

تضمّن NIST SP 800-90A في الأصل DUAL_EC_DRBG، المعتمد على المنحنيات الإهليلجية. وكشفت وثائق Snowden أن NSA أدخلت بابًا خلفيًا: فقد اختيرت نقاط EC بحيث تتمكن NSA من التنبؤ بالمخرجات انطلاقًا من أي seed. لا تستخدموا DUAL_EC_DRBG مطلقًا. أزالته NIST في عام 2014.

يستخدم CTR_DRBG ‏(NIST SP 800-90A) خوارزمية AES في نمط العداد بوصفها مولد CSPRNG. تتكون البذرة من مفتاح بطول 256 بت وnonce بطول 128 بت. يؤدي كل استدعاء إلى تقديم العداد. وهو مطبق على نطاق واسع في OpenSSL وBoringSSL وWindows BCrypt. ويستفيد من التسريع العتادي على معالجات AES-NI.

يستخدم HASH_DRBG دالة تجزئة (SHA-256) تكراريًا مع قيمة seed. أما HMAC_DRBG فيستخدم HMAC للمزج. ويُعد HMAC_DRBG أبسط من حيث التنفيذ الصحيح، ويُستخدم في العديد من الأنظمة المضمنة، مثل mbedTLS وWolfSSL.

حتى مولدات CSPRNG يجب أن تعيد التهيئة بالبذرة دوريًا. تبلغ فترة إعادة التهيئة في CTR_DRBG مقدار 2^48 طلبًا. ويعيد Fortuna التهيئة باستخدام مجمّعات الإنتروبيا الخاصة به. لإعادة التهيئة يدويًا، أضيفوا إنتروبيا جديدة (بايتات getrandom) إلى حالة مولد CSPRNG عند بدء التشغيل وبعد fork().

عند إجراء fork لعملية، ترث العملية الأب والعملية الابنة حالة CSPRNG نفسها، ولذلك ستنتجان مخرجات متطابقة. الحل هو استدعاء getrandom() لإعادة التهيئة بالبذرة مباشرة بعد fork(). ويتولى OpenSSL ذلك تلقائيًا عبر pthread_atfork() في الإصدارات الحديثة.

import secrets key = secrets.token_bytes(32) # مفتاح بطول 256 بت nonce = secrets.token_bytes(12) # nonce بطول 96 بت لـ AES-GCM pin = secrets.randbelow(10**6) # رمز PIN من 6 أرقام # لا تستخدموا الوحدة random مطلقًا في التشفير

‏window.crypto.getRandomValues(typedArray) هو مولد CSPRNG في المتصفح. ويستدعي مصدر الإنتروبيا في نظام التشغيل. ويستخدمه WebCrypto API لتوليد المفاتيح. لا تستخدموا Math.random() لأغراض الأمان مطلقًا، فهو مولد PRNG غير تشفيري مهيأ من وقت النظام.

ما وحدة Python التي ينبغي استخدامها لتوليد بايتات عشوائية تشفيرية؟

تولد مولدات CSPRNG، مثل ChaCha20 وCTR_DRBG وFortuna، مخرجات غير قابلة للتنبؤ انطلاقًا من بذور الإنتروبيا. تجنبوا DUAL_EC_DRBG وrandom.random() وMath.random(). استخدموا secrets في Python أو window.crypto في المتصفح. التالي: حالات فشل الإنتروبيا في العالم الحقيقي.