إنشاء المفاتيح وNonces وIVs بأمان

تحتاج ثلاث قيم تشفيرية متميزة إلى توليد آمن: (1) المفاتيح — طويلة الأمد، ويجب أن تكون غير قابلة للتنبؤ وسرية. (2) IV — لكل رسالة، وقد تكون علنية، لكن يجب أن تكون غير قابلة للتنبؤ في CBC أو فريدة في GCM. (3) قيم nonce — يجب أن تكون فريدة في كل استخدام، وقد تكون عشوائية أو غير عشوائية.

AES-128: secrets.token_bytes(16). AES-256: secrets.token_bytes(32). ChaCha20: secrets.token_bytes(32). لا تشتقوا المفاتيح من كلمات المرور دون استخدام KDF ‏(PBKDF2/Argon2). ولا تعيدوا استخدام المفاتيح بين خوارزميات أو أغراض مختلفة.

from cryptography.hazmat.primitives.asymmetric import ec, rsa rsa_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) ec_key = ec.generate_private_key(ec.SECP256R1()) # تتولى المكتبة داخليًا توفير مصدر الإنتروبيا

يتطلب AES-CBC قيمة IV عشوائية موزعة توزيعًا منتظمًا بطول 16 بايت لكل رسالة. لا تعيدوا استخدام IV مع المفتاح نفسه مطلقًا. ولا تستخدموا عدادًا بوصفه IV في نمط CBC. وللتوليد: iv = os.urandom(16). أضيفوا IV إلى بداية النص المشفر؛ فلا يلزم أن يكون سريًا، بل يجب فقط ألا يكون قابلًا للتنبؤ.

يتطلب AES-GCM قيمة nonce فريدة بطول 96 بت لكل زوج (key, message). تؤدي إعادة استخدام nonce إلى كسر GCM بشكل كارثي؛ إذ يسترد المهاجم مفتاح المصادقة ويمكنه تزوير الرسائل. استخدموا إما nonce عشوائيًا بطول 12 بايت (يبلغ حد عيد الميلاد عند 2^32 رسالة) أو عدادًا.

للتشفير عالي الحجم باستخدام مفتاح واحد: حافظوا على عداد مستمر لكل مفتاح. nonce = counter.to_bytes(12, "big"). زيدوا العداد بعد كل عملية تشفير. خزّنوا العداد في تخزين مستمر، إذ تؤدي إعادة ضبطه عند إعادة التشغيل إلى إعادة الاستخدام.

تتميز AES-GCM-SIV وDeoxys-II بمقاومة سوء استخدام nonce: إذ تؤدي إعادة استخدام nonce إلى خفض الأمان إلى مستوى التشفير الحتمي، من دون تسريب مفتاح المصادقة. ويُنصح بهما عندما يصعب ضمان تفرد nonce، كما في الأنظمة الموزعة وسيناريوهات التعطل وإعادة التشغيل.

لا تستخدموا مادة المفتاح الخام مباشرة لأغراض متعددة. اشتقوا مفاتيح مخصصة لكل غرض: from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). استخدموا قيمة info مختلفة لكل غرض.

اشتقوا مفاتيح خاصة بكل جلسة من سر مشترك (مثل مخرجات ECDH) باستخدام HKDF. يشتق TLS 1.3 مفاتيح منفصلة للعميل والخادم من أجل المصافحة وبيانات التطبيق. وتعزل مفاتيح الجلسات أثر الاختراق؛ فمعرفة مفتاح جلسة واحدة لا تكشف شيئًا عن الجلسات الأخرى.

لتخزين مفتاح بأمان، غلّفوه باستخدام مفتاح تشفير المفاتيح (KEK) مع AES-KW ‏(RFC 3394) أو AES-GCM. ويمكن تخزين المفتاح المغلف في قاعدة بيانات أو نقله. ويُخزن KEK في HSM أو مخزن مفاتيح مدعوم عتاديًا، مثل Android Keystore وApple Secure Enclave.

قبل النشر، تحققوا مما يلي: (1) جميع المفاتيح مولدة باستخدام os.urandom/secrets. (2) لا توجد مفاتيح أو IVs مضمنة في الشيفرة. (3) لا يعاد استخدام IVs مع المفتاح نفسه. (4) قيم nonce في GCM فريدة لكل رسالة. (5) تحديد جدول زمني لتدوير المفاتيح. (6) يستخدم اشتقاق المفاتيح HKDF مع سلاسل info متميزة.

تحتاج المفاتيح إلى توليد عشوائي حقيقي؛ وتحتاج IVs في CBC إلى العشوائية؛ وتحتاج قيم nonce في GCM إلى التفرد. استخدموا os.urandom/secrets، واشتقوا المفاتيح باستخدام HKDF، وغلّفوها باستخدام KEKs. تحمي AEADs المقاومة لسوء استخدام nonce من إعادة الاستخدام غير المقصودة. التالي: براهين المعرفة الصفرية.