AES + EBC + random padding: это надёжно?

Я вот что подумал... Если у меня и так каждый пакет уникален из-за уникального id то может мне не стоит заморачиваться с паддингом? Забиваем конец пакета нулями до нужного размера (кратного 16 байт) и всё...

Если ты сериализуешь данные прямо в пакет, то расшифрованные данные легко разберутся на составляющие. Тут собственно вопрос в том смогут ли расшифровать данные :) А это уже не совсем зависит от транзита, сколько от эндпоинтов.

расшифрованные данные легко разберутся на составляющие

логично :). Так и задумано: пакеты не только генерятся и отправляются, но ещё принимаются и парсятся.

Тут собственно вопрос в том смогут ли расшифровать данные :)

в этом и вопрос :)

Непонятен смысл твоей затеи. Для чего udp пакеты? стриминг? Тогда тебе надо не блочное а поточное шифрование, наверное.

у меня IPC между тачками, udp мне больше подходит т.к. с ним предсказуемые таймауты.

ну а шифрование не поточное потому что как такового потока нет, идёт обмен сообщениями. В общем, tcp тут не в кассу.

Ничего, что режим ECB для шифрования не предназначен?

voip - тоже обмен пакетами, если что.

voip - тоже обмен пакетами, если что.

и? :)

Ничего, что режим ECB для шифрования не предназначен?

а для чего он предназначен? :)

ничего что у меня там каунтер который, по сути, представляет собой initialization vector превращает шифрование в поточное (точнее в CTR)?

Вопрос: в чём недостатки такого подхода?

В том, что

По-идее, после такого частотный анализ уже не прокатит.

ошибочно.

Поскольку данные упорядочены, фрикции с их положением только несколько усложняют частотный анализ, но ничуть его не исключают. Сколько-нибудь значимого эффекта можно добиться только при объёме дополнения во много раз больше собственно пакета данных.

Если тебе уж так хочется побороться с частотным анализом - используй циклический сдвиг на случайную величину.

а для чего он предназначен?

Ни для чего. Это просто модель.

ничего что у меня там каунтер который, по сути, представляет собой initialization vector

Ничего, поскольку твой «каунтер» ни какой не вектор.

превращает шифрование в поточное (точнее в CTR)?

И никакой не CTR ))

Поскольку данные упорядочены, фрикции с их положением только несколько усложняют частотный анализ, но ничуть его не исключают.

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

>>> from Crypto.Cipher import AES
>>> aes = AES.new("sdaa6734k&%$32", AES.MODE_ECB)
>>> aes.encrypt("mama mila ramu.0")
b'\x7f\x18tc\x02\x94Qe\xd0\x88G"\x89\xbe\x1b\x91'
>>> aes.encrypt("mama mila ramu.1")
b'\xfe\xb3>\xcc.]\xdf\xc8\xbc\x83?\x0eg\xfa\x04\xc0'
>>> aes.encrypt("mama mila ramu.2")
b'\xe5\xc7\xbeV\x1e\x03\xc9\xa3d\x9aL0\x12t0\x1a'
>>> aes.encrypt("mama mila ramu.3")
b'\xfd\xc7\xf5\xfbH\xday\x85T&\x07*iX\r\xda'
>>> aes.encrypt("mama mila ramu.4")
b'\xb3%\x07\x8a&"\xa3\xca\xbd\x1c\xdc\xc2\x84"\xca\x84'

Или ты имеешь в виду что и так понятно будет по длине пакета что за тип данных передаётся? Это не секрет в данном случае.

твой «каунтер» ни какой не вектор.

ну тогда пусть будет padding который сойдёт за вектор.

используй циклический сдвиг на случайную величину.

да, это идея. Спасибо. Рандомный паддинг+сдвиг для меня выглядит надёжно.

нашёл годную доку: http://www.cryptopp.com/wiki/Authenticated_Encryption

aes.encrypt(«mama mila ramu.0»)

Это слишком маленькая выборка на слишком коротком сообщении, чтобы на ней можно было замерить частоты.

В википедии же есть картинка, где всё наглядно показано.

Или ты имеешь в виду что и так понятно будет по длине пакета что за тип данных передаётся?

Я имею в виду, что пингвин будет слегка «размытым», но всё равно будет проступать.

тогда пусть будет padding который сойдёт за вектор.

Ты не вдупляешь. «Вектор» - в данном случае не часть пакета, а пачка данных равная блоку шифрования, по которой этот пакет дополнительно шифруется.

Рандомный паддинг+сдвиг для меня выглядит надёжно.

Нет смысла делать рэндомный паддинг, для атакующего он будет просто лишним шумом при атаке, и будет мешать, только если его объём будет достигать, а в идеале - превышать в разы объём собственно шифруемого текста.

Ну и сдвиг, хоть сильно затруднит атаку, но всё равно позволяет атаковать по структуре сообщения - т.е. не что в каком месте, а что за чем идёт.

Я имею в виду, что пингвин будет слегка «размытым», но всё равно будет проступать.

не будет потому что паддинг рандомный.

Ну и сдвиг, хоть сильно затруднит атаку, но всё равно позволяет атаковать по структуре сообщения - т.е. не что в каком месте, а что за чем идёт.

ты уверен? Мне казалось что нельзя установить степень родства между двумя пакетами если сдвиг шифруемых данных был разный.

не будет потому что паддинг рандомный.

Не важно какой будет паддинг. Важно, какими будут шифрованные данные. Всегда ваш, Кэп.

нельзя установить степень родства между двумя пакетами если сдвиг шифруемых данных был разный

Это сложно, но теоретически возможно. См. предыдущее утверждение.

Кстати, до кучи. Самая надежная защита от частотного анализа - банальное сжатие данных. Только реализацую надо выбирать с минимальным «заголовком» - т.е. служебными данными. В идеале, соотношение (служебные данные реализации сжатия)/(сами сжатые данные) должно стремиться к нулю.