Источник и значение 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 для каждого сеанса (помните, что одноразовый номер означает использование ONLY ONCE ) .

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

Answer 2

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

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