Какой шифр для шифрования пакетов UDP?

У меня есть приложение, которое осуществляет срочную связь через UDP (например, потоковое видео или игру). Пакеты могут быть потеряны, и их не нужно повторно передавать.

Какой шифр следует использовать для шифрования дейтаграмм?

Я склоняюсь к иглобрюху в режиме ECB. Я знаю, что в режиме ECB есть проблемы, но мне нужно поддерживать отсутствующие пакеты, поэтому шифрование не может полагаться на предыдущие блоки. Есть ли лучший шифр или режим, который я могу использовать для уменьшения проблем с ECB режим и по-прежнему разрешать отсутствующие пакеты?

(Я бы хотел, чтобы все было на чистом Java, поэтому я не могу использовать DTLS.)


java encryption aes udp blowfish
person Eric Lathrop    schedule 06.10.2010    source источник
comment
Просто добавьте к пакету префикс IV и используйте режим CBC или режим CTR с CMAC.   -  person President James K. Polk    schedule 06.10.2010
comment
Я не верю, что могу использовать режим CBC или CTR, потому что они зависят от вывода из предыдущих блоков, которые находятся в предыдущих пропавших без вести пакетах UDP.   -  person Eric Lathrop    schedule 06.10.2010
comment
Вы можете использовать режим CBC. Допустим, каждый пакет UDP, который вы собираетесь отправить, имеет размер 1300 байт. Этот пакет либо будет доставлен, либо потерян. Перед отправкой пакета зашифруйте его с помощью AES-CBC. AES с его 16-байтовым размером блока превратит его в 1312 байт. Добавьте к пакету префикс уникального 16-байтового IV, который вы сгенерировали только для этого пакета, и это означает, что вы отправляете пакет размером 1328 байт, который не зависит ни от какого предыдущего пакета, ни от которого не зависит ни один будущий пакет. Это CBC или как ECB, если AES имеет размер блока 1312 байт.   -  person Ian Boyd    schedule 05.04.2020

Ответы (3)


arrow_upward
1
arrow_downward

Вы можете использовать режим CBC, вам просто нужно зашифровать каждый пакет как отдельный поток CBC. Это означает перезапуск CBC для каждого пакета с новым IV.

Между прочим, Blowfish — это всего лишь 64-битный (размер блока) блочный шифр, что в наши дни по своей сути дает ему довольно низкий уровень безопасности.

person caf    schedule 06.10.2010

arrow_upward
2
arrow_downward

Возможно использование AES в режиме счетчика (CTR). При установлении соединения вы запускаете счетчик со случайно выбранного значения, известного как отправляющей, так и принимающей программам. Если каждый пакет видеоданных содержит порядковый номер (n), достаточно длинный, чтобы не повторяться в пределах одного соединения, принимающая программа может добавить его к начальному значению счетчика, чтобы получить значение счетчика, используемого для зашифровать этот пакет.

Конечно, для сообщений длиннее одного блока вам потребуется увеличивать счетчик более одного раза в пакете. Я бы определил, сколько блоков будет самым длинным переданным пакетом, например 16 блоков, и использовал значения счетчика 16*n для первого блока в пакете, 16*n+1 для второго и так далее.

person PleaseStand    schedule 06.10.2010

arrow_upward
1
arrow_downward

ECB открыт для атаки, потому что каждый зашифрованный блок совершенно независим от всех остальных, что позволяет как делать выводы о содержании зашифрованного текста, замечая, что некоторые два (или более) зашифрованных блока идентичны, так и незаметно изменять сообщение путем перестановки. блоков шифра или замены блоков шифра из других сообщений, зашифрованных с использованием того же ключа (что само по себе не очень хорошая идея).

Если ваши пакеты UDP содержат некоторую информацию о последовательности, вы можете использовать ее в качестве счетчика в режиме CTR или вы можете использовать режим XEX (или XTS). XEX был разработан для ситуаций шифрования, в которых шифрование данных может выполняться в случайном порядке блоков, как в случае с зашифрованными устройствами с произвольным доступом, такими как жесткие диски, и идеально подходит для такой ситуации, как ваша.

См. http://en.wikipedia.org/wiki/Disk_encryption_theory#XEX.

person dajames    schedule 07.10.2010