Шифрование Опции

[asd6715]

Пакет данных будет передаваться по незащищенному каналу. Нужен алгоритм шифрования который бы кодировал пакет размером 256 байт в зашифрованный пакет того же размера (256 байт). Т.е. по каналу что в зашифрованном виде что в незашифрованном виде передается только 256 байт.
Каким алгоритмом рекомендуете шифровать? Выполнятся будет на микроконтроллере с архитектурой ARM7.

[x736C]

Какая стойкость нужна?
Для простой маскировки подойдет обычный xor, например.

[Artem_Petrik]

Каким алгоритмом рекомендуете шифровать?

Да любым! начиная от мало ресурсы жрущего XTEA, до DES-ов с AES-ами. На что тактов не жалко. Благо исходники готовые найти не проблема.

[head_sk]

Вот к примеру AES. НА SAM7 работает быстро.

Прикрепленные файлы

 aes.rar ( 4.14 килобайт ) Кол-во скачиваний: 68

 

[acex2]

Пакет данных будет передаваться по незащищенному каналу. Нужен алгоритм шифрования который бы кодировал пакет размером 256 байт в зашифрованный пакет того же размера (256 байт). Т.е. по каналу что в зашифрованном виде что в незашифрованном виде передается только 256 байт.
Каким алгоритмом рекомендуете шифровать? Выполнятся будет на микроконтроллере с архитектурой ARM7.

Вот вам простой, быстрый и достаточно надежный потоковый алгоритм: http://ru.wikipedia.org/wiki/RC4

[Harbour]

rc4 однозначно, aes это если дури лишней много

[demiurg_spb]

rc4 однозначно, aes это если дури лишней много

Если сравнить XTEA и rc4 у кого какие плюсы и минусы?

[Artem_Petrik]

Если сравнить XTEA и rc4 у кого какие плюсы и минусы?

Где-то читал, что у RC4 имеется уязвимость. У просто TEA тоже, а у XTEA вроде все в порядке. Но все эти уязвимости имеют значение, только если взломщик имеет возможность закодировать вашим ключом любую свою информацию. Так что, велика вероятность, что в вашем случае это не имеет значения. А вообще, это надо у знатоков спрашивать. Я когда интересовался данным вопросом, был вынесен гуглем на форум, где живут криптографы (или как их там.). Прочитал много интересного. Ничего не понял , почти.


А вообще, даже в википедии довольно многое по этому поводу написано.

[Nixon]

Если уж рассматривать XTEA, то лучше (и проще) использовать другой вариант - RTEA.

[Harbour]

Если сравнить XTEA и rc4 у кого какие плюсы и минусы?

см. http://defectoscopy.com/results.html

канечна rc4 банковскую инфу сегодня не шифруют, но с длинным ключем и в варианте с MCU он наиболее оптимален для 99% приложений

[AlexandrY]

Ну если чиста общие соображения, то

выбирать нужно нечто стандартное которое можно легко отладить на PC .
Еще лучше чтоб это можно было найти реализованное в ARM-ах аппаратно.

Ну так самый стандартный будет AES. AES есть даже в самых примитивных аппаратных криптодвижках на ARM-ах.
AES применяется и в SSL.
Море библиотек с AES есть.

На крайний случай вот тут можно найти экземплы реализации разных алгоритмов шифрования под разные компиляторы для ядра ARM
http://www.alylab.eu/OpenProjects/ARMDomin...RMDominator.htm

Как видно AES только где-то в 2-а раза уступает RC4 и в 3-и раза быстрее DES3

Но серьезно, чтоб начать сессию шифрования симметричными алгоритмами типа RC4 или AES нужно провести сеанс защищенного обмена ключами как минимум. Тут уже нужен алгоритм вроде Дифи-Хелмана : http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange
В таких алгоритмах если по честному, то нужна генерация длинных простых чисел. Так вот эта генерация самая длинная операция в криптографии.
Ее длительность слабо предсказуема и на ARM-ах может длиться минуты.

А еще же и атентификацию наверно надо бы проводить.

А иначе, если ключи будут статическими и храниться где-то во FLASH-и, то грош цена такому шифрованию.
( Конкретно по ценам прошу обращаться приватно )

Пакет данных будет передаваться по незащищенному каналу. Нужен алгоритм шифрования который бы кодировал пакет размером 256 байт в зашифрованный пакет того же размера (256 байт). Т.е. по каналу что в зашифрованном виде что в незашифрованном виде передается только 256 байт.
Каким алгоритмом рекомендуете шифровать? Выполнятся будет на микроконтроллере с архитектурой ARM7.

[Harbour]

А иначе, если ключи будут статическими и храниться где-то во FLASH-и, то грош цена такому шифрованию.

Если ключи будут храниться в защищенном флеше то это даст точно такую же безопасность как и остальные методы. Для того что бы делать подобные выводы, следует трезво оценивать трудоемкость получения ключа из защищенного флеша, перехват открытого ключа на этапе кодирования по ДХМ или взлом используемого алгоритма. К тому же в двух первых случаях необходимо получить физический доступ к устройству, что усугубляет

[Rst7]

А еще же и атентификацию наверно надо бы проводить.

Наверное? Обязательно

In the original description, the Diffie-Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish two distinct Diffie-Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed between them. A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack.