Безопасная генерация ключей, одноразовых чисел и векторов инициализации

Безопасной генерации требуют три разных криптографических значения: (1) Ключи — используются длительное время, поэтому должны быть непредсказуемыми и секретными. (2) IV — используются для каждого сообщения, могут быть общедоступными, но должны быть непредсказуемыми (CBC) или уникальными (GCM). (3) Одноразовые числа — должны быть уникальными при каждом использовании, но могут быть случайными, а могут и не быть.

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()) # The library handles entropy sourcing internally

AES-CBC требует равномерно случайного 16-байтового IV для каждого сообщения. Никогда не используйте IV повторно с тем же ключом. Никогда не используйте счётчик в качестве IV в режиме CBC. Сгенерируйте: iv = os.urandom(16). Добавьте IV перед шифротекстом — он не обязан быть секретным, только непредсказуемым.

AES-GCM требует уникального 96-битного одноразового числа для каждой пары (ключ, сообщение). Повторное использование одноразового числа катастрофически нарушает безопасность GCM: злоумышленник получает ключ аутентификации и может подделывать сообщения. Используйте либо случайное 12-байтовое одноразовое число (граница парадокса дней рождения — 2^32 сообщения), либо счётчик.

Для шифрования больших объёмов данных одним ключом поддерживайте постоянный счётчик для каждого ключа. nonce = counter.to_bytes(12, "big"). Увеличивайте счётчик после каждого шифрования. Храните счётчик в постоянном хранилище — сброс при перезапуске приводит к повторному использованию.

AES-GCM-SIV и Deoxys-II устойчивы к неправильному использованию одноразовых чисел: повторное использование одноразового числа снижает безопасность до уровня детерминированного шифрования (ключ аутентификации не раскрывается). Эти алгоритмы рекомендуются, когда уникальность одноразовых чисел трудно гарантировать (в распределённых системах и при сценариях сбоев и перезапусков).

Не используйте необработанный материал ключа непосредственно для нескольких целей. Выводите ключи для конкретных целей: 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) отсутствуют жёстко заданные ключи и IV; (3) IV никогда не используется повторно с тем же ключом; (4) одноразовые числа GCM уникальны для каждого сообщения; (5) определён график смены ключей; (6) для выведения ключей используется HKDF с различными строками info.

Для ключей нужна генерация с использованием истинной случайности; IV в CBC должны быть случайными; одноразовые числа GCM должны быть уникальными. Используйте os.urandom/secrets, выводите ключи с помощью HKDF и оборачивайте их с помощью KEK. AEAD, устойчивые к неправильному использованию одноразовых чисел, защищают от случайного повторного использования. Далее: доказательства с нулевым разглашением.