Источник и значение nonce / IV для протокола с использованием AES-GCM

Question

Я делаю протокол, который использует пакеты (то есть, не поток), зашифрованные с помощью AES. Я решил использовать GCM (на основе CTR), потому что он обеспечивает интегрированную аутентификацию и является частью пакета NSA B. Ключи AES согласовываются с помощью ECDH, где открытые ключи подписываются доверенными контактами как часть веб-интерфейса. доверия, используя что-то вроде ECDSA. Я считаю, что мне нужен 128-битный одноразовый вектор / вектор инициализации для GCM, потому что, хотя я использую 256-битный ключ для AES, это всегда 128-битный блочный шифр (верно?) Я буду использовать 96-битный IV после чтение кода BC

Я определенно не реализую свои собственные алгоритмы (только протокол - мой поставщик криптографии - BouncyCastle), но мне все еще нужно знать, как использовать этот одноразовый номер, не стреляя себе в ногу. Ключ AES, используемый между двумя людьми с одинаковыми ключами DH, останется неизменным, поэтому я знаю, что один и тот же одноразовый номер не должен использоваться для более чем одного пакета.

Могу ли я просто добавить 96-битное псевдослучайное число к пакету и сделать так, чтобы получатель использовал его как одноразовый номер? Это одноранговое программное обеспечение, и пакеты могут быть отправлены в любое время (например, с помощью мгновенного сообщения, запроса на передачу файла и т. Д.), А скорость является большой проблемой, поэтому было бы неплохо не использовать безопасный источник случайных чисел. Одноразовый номер вовсе не должен быть секретным, верно? Или обязательно такой случайный, как "криптографически безопасный" PNRG? Википедия говорит, что она должна быть случайной, иначе она будет восприимчива к выбранной атаке открытым текстом - но рядом с обоими утверждениями есть "нужная цитата", и я не уверен, верно ли это для блочных шифров. Могу ли я на самом деле использовать счетчик, который подсчитывает количество отправленных пакетов (отдельно от счетчика количества 128-битных блоков) с данным ключом AES, начиная с 1? Очевидно, это сделало бы одноразовый номер предсказуемым. Учитывая, что GCM аутентифицирует, а также шифрует, это поставит под угрозу его функциональность аутентификации?

Answer 1

GCM - это режим счетчика блочного шифра с аутентификацией. Режим счетчика эффективно превращает блочный шифр в потоковый шифр, и поэтому многие правила для потоковых шифров все еще применяются. Важно отметить, что один и тот же ключ +IV всегда будет генерировать один и тот же поток PRNG, и повторное использование этого потока PRNG может привести к тому, что злоумышленник получит открытый текст с простым XOR. В протоколе один и тот же ключ +IV может использоваться для жизни сеанса, пока счетчик режима не переносится (переполнение int). Например, протокол может иметь две стороны, и у них есть предварительный общий секретный ключ, тогда они могут согласовать новый криптографический одноразовый номер, который используется в качестве IV для каждого сеанса (помните, что одноразовый номер означает использовать ТОЛЬКО ОДИН РАЗ).

Если вы хотите использовать AES в качестве блочного шифра, вам следует обратиться к режиму CMAC или, возможно, к варианту OMAC1. В режиме CMAC применяются все правила для неподвижного CBC. В этом случае вы должны убедиться, что каждый пакет использует уникальный IV, который также является случайным. Однако важно отметить, что повторное использование IV не имеет столь же тяжелых последствий, как повторное использование потока PRNG.

Answer 2

Я бы посоветовал не делать свой собственный протокол безопасности. Есть несколько вещей, которые вы должны учитывать, что даже квалифицированный криптограф может ошибиться. Я бы направил вас к протоколу TLS (RFC5246) и к протоколу дейтаграмм TLS (RFC 4347). Выберите библиотеку и используйте их.

По поводу вашего вопроса с IV в режиме GCM. Я расскажу вам, как это делают DTLS и TLS. Они используют явный одноразовый номер, то есть порядковый номер сообщения (64 бита), который включен в каждый пакет, с секретной частью, которая не передается (верхние 32 бита) и получена из начального обмена ключами (проверьте RFC 5288 для Дополнительная информация).