[Alt.F4 2]

Здравствуйте.

 

Есть два девайса, которые посылают друг другу однотипные сообщения-команды.

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

Просто добавлять в блок с данными рандомное число?

Спасибо.

 

з.ы. Ключи жестко прописаны во Flash, или лучше их менять с каждой посылкой?

[Электронщик 1]

обратите внимание на систему счисления с остаточными классами...

[Flood 12]

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

 

https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%...%BD%D0%B8%D1%8F

[Alt.F4 2]

Flood, википедия - это хорошо, но какой режим предпочтителен для текущей задачи, гугел молчит (или мне не хочет говорить)?..

Вот натыкаюсь, что CTR не годится, когда шифротекст будет доступен хакеру более двух раз.

[Corner 0]

К сообщению добавляется СЧ. Само сообщение хешируется обратимым алгоритмом, в зависимости от СЧ и ключа. Алгоритм считается невскрываемым, если СЧ больше или равно по размеру шифруемому сообщению.

Изменено 23 февраля, 2017 пользователем Corner

[sigmaN 0]

Приколы начнутся при потерях этих пакетов )

[Herz 4]

Есть два девайса, которые ..

Просто добавлять в блок с данными рандомное число?

Вот если бы это были два устройства, то достаточно было бы случайного числа.

Автор, давайте не забывать, что мы на русскоязычном форуме...

[Pavia 0]

Для каждого сообщения создаёшь случайное число. Потом ксоришь свое сообщение с этим числом. И отправляешь это число вместе с сообщением.

А чтобы ещё больше запутать применяются перестановки.

Для защиты от внедрения случайное сообщение передаётся только один раз.

А что-бы ещё больше усложнить договариваются о ключах. В зависимости от ключа между сообщениями немного изменяется алгоритмы шифрования.

Стоит ли ключи делать постоянным?

Нет так как перехватив ключ в дальнейшем он может быть скомпрометирован. Или если целиком кто-то запишет, а потом проиграет последовательность сообщений.

Так что ключи надо тоже менять, но делать это надо через доверенные центры.

Но так как у нас всего 2 устройства, то это неудобно. Поэтому вариант с постоянными ключами тут уместнее.

по поводу потерь - пакетов. Гамма не обязательно должна зависеть от предыдущих сообщений. А это значит достаточно контрольной суммы на этапе рукопожатия.

[Alt.F4 2]

Herz, слова уже наверное русские, оба описаны в викисловаре + "рандомизацию" повсеместно вижу в различных статьях вики.

 

По теме: покопался в описаниях режимов в русском и английских сообществах и в примерах реализаций:

- для режимов CBC, CFB и OFB вектор инициализации (IV) не является секретным и может передаваться перед шифрованием, главное, чтобы он был для CBC и CFB непредсказуемым и для OFB - уникальным.

И, т.к. CTR - это тот же OFB, то начальное значение счетчика можно передавать в открытой форме, главное не повторяться.

И вот наткнулся на реализацию CTR в SimpliciTI, где значение счетчика передается в начале фрейма, но только младший байт. И что интересно, nonce у них статический (хотя он даже переводится, как одноразовый) и при каждом включении устройств, значение счетчика будет у всех 0, т.е. они используют повторно тот же IV, что приводит полному разрушению безопасности (For output feedback (OFB) mode, reusing an IV completely destroys security.)

Вот тебе и техасовцы...