Источник и важность nonce / IV для протокола, использующего AES-GCM

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

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

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