- Может ли пассивный слушатель взломать это шифрование и/или создать законные сообщения?
Пассивный слушатель не должен иметь возможности отменить AES, поэтому получение открытого текста должно быть невозможным, если только каждый сеанс не перезапускается.Однако эта схема будет уязвима для атак оракула с открытым текстом. Читай дальше.
Что касается создания законных сообщений: это не пассивная атака.
- Это также обеспечивает аутентификацию, поскольку никто, кроме владельца ключа, не может создать такое сообщение?
Нет. Если вы играете человека посередине, вы можете изменить каждый бит сообщения и оставить магию нетронутой. В режиме CTR все биты открытого текста/зашифрованного текста не зависят друг от друга. Это также позволяет злоумышленнику выполнять атаки оракула с открытым текстом (изменяя часть открытого текста, а затем определяя, как система реагирует на это).
- Можно ли использовать IV/nonce с добавлением 0 к счетчику? Должен ли я добавлять счетчик к случайному числу (которое также сгорает на заводе)?
До тех пор, пока счетчик никогда не повторяется, режим CTR относительно безопасен — до тех пор, пока он используется правильно, что здесь не так.
- Что поставить на отступ, 0 или случайные числа? Это вообще необходимо?
Нет, для режима CTR заполнение не требуется.
- Логично ли использовать магическое число таким образом? Нужно ли генерировать случайную магию и отправлять ее как в незашифрованном, так и в зашифрованном виде для проверки получателем?
Обычно вы используете режим аутентификации для создания тега аутентификации. 32 бита обычно слишком мало, но в зависимости от варианта использования этого может быть достаточно для систем реального времени и т. д.
- Каков правильный/хорошо зарекомендовавший себя метод шифрования и аутентификации в таких условиях?
Если у вас просто AES, то режим CCM будет нормальным режимом.
NB
Схема, которую вы сейчас описываете, кажется более подходящей для прямого шифрования AES или AES-CBC. Например, если вы дополните и зашифруете счетчик, вы можете использовать его как IV для AES-CBC. Если бы вы поставили значение 02 в байтах заполнения сообщения, тогда у вас будет заполнение, совместимое с PKCS # 7. Преимущество этого заключается в том, что биты в блоке шифрования сообщения AES теперь все зависят друг от друга, поэтому магия будет работать несколько лучше.
Ваша текущая схема, кажется, ограничена только одним сеансом.Обычно вы будете получать новые сеансовые ключи для каждого сеанса.
Даже если режим изменен на CBC, $1 \более 2^{32}$ вероятность того, что злоумышленник создаст сообщение с действительной магией, просто случайно попытавшись. Остальная часть сообщения, вероятно, будет искажена, но обработка искаженного текста также может быть не очень хорошей идеей. Возможно, против этого могут быть реализованы дополнительные меры противодействия (однако большинство из них могут привести к DoS-атакам).
