Я делаю протокол, который использует пакеты (т.е. не потоки), зашифрованные с помощью AES. Я решил использовать GCM (основанный на CTR), потому что он обеспечивает интегрированную проверку подлинности и является частью NSA Suite B. Ключи AES обсуждаются с использованием ECDH, где открытые ключи подписываются доверенными контактами как часть веб- что-то вроде ECDSA. Я считаю, что мне нужен 128-битный вектор nonce/initialization для GCM, потому что, хотя я использую 256-битный ключ для AES, он всегда имеет 128-битный блочный шифр (правда?) используя 96-битный IV после считывания кода BC.
Я определенно не реализую свои собственные алгоритмы (только протокол - мой крипто провайдер - BouncyCastle), но мне все еще нужно знать, как использовать этот nonce, не снимая себя в ногу. Ключ AES, используемый между двумя людьми с теми же ключами DH, останется постоянным, поэтому я знаю, что тот же самый nonce не должен использоваться для более чем одного пакета.
Могу ли я просто добавить 96-битное псевдослучайное число в пакет и использовать получателя как nonce? Это одноранговое программное обеспечение, и пакеты могут быть отправлены либо в любое время (например, мгновенное сообщение, запрос на передачу файлов и т.д.), А скорость - большая проблема, поэтому было бы неплохо не использовать безопасный случайный номер источника. Ночь не обязательно должна быть секретной, верно? Или обязательно такой случайный, как "криптографически безопасный" PNRG? Википедия говорит, что она должна быть случайной, или же она восприимчива к выбранной атаке открытого текста - но там есть "цитата" рядом с обеим утверждениями, и я не уверен, что это верно для блочных шифров. Могу ли я использовать счетчик, который подсчитывает количество отправленных пакетов (отдельно от счетчика числа 128-битных блоков) с заданным ключом AES, начиная с 1? Очевидно, это сделало бы nonce предсказуемым. Учитывая, что GCM аутентифицируется, а также шифрует, может ли это нарушить его функции аутентификации?
