Кибернетика, автоматика, протоколы

Замечательный пример как сделать полную лажу! Начиная с того, что нужно не шифрование, а аутентификация. Шифрование никак не поможет от повторной посылки команды "открой все двери", например. Шифрование полезно для того, чтобы избежать сложных атак, как раз на грани социальной инженерии, когда незашифрованные данные можно где-либо применить нетривиальным образом. Но и здесь шифрование в чистом виде, как есть, может быть бесполезным, т.к. атакующий может набирать статистику на основе длины команды, их частоты посылок и т.п. Потом RTEA относится к тем алгоритмам, о свойствах которых _ничего_ _не_ _известно_. Они могут быть хорошие, а могут бы крайне плохие. И скорей последнее -- типичный "секретный алгоритм". Свойства классических XTEA, TEA и др. известны и понятно, где их не следует использовать хотя бы. Напомню, что именно XTEA использовался в XBOX и чем это кончилось. Из блочного шифра получить хэш функцию -- отдельная и непростая задача, с которой в микрософте не справились (в микрософте! А ты хочешь в ООО "Рога и Копыта"). Не всякий блочный шифр ещё подходит хорошо. Не лучше ли взять известный и проверенный алгоритм хэш функции? Например MD5. Известно, например, что в варианте HMAC-MD5 ему до сих пор можно доверять. Я самодельная MAC-функция на основе RTEA может иметь уязвимости 1) в самом алгоритме блочного шифра, 2) в алгоритме MAC-функции, 3) в защищаемые данные обязательно забудут добавить рандомный вектор инициализации (WEP -- все знают). И всё вышесказанное совершенно не важно, на самом деле, т.к. в базе везде лежат симметричные алгоритмы которые требуют для всех сторон знанания общего "секретного ключа". И не имея механизма распределения ключей -- остальное бессмысленно. Если ключ, например, свободно читается из памяти любого устройства (флэш защищён от чтения, но ключ копируется в RAM на 3-й секунде работы? На 4-й секунде даём резет, прогружаем свой монитор-отладчик и вычитываем ключ! Плюс ещё варианты с обливанием азотом для удержания электронов в транзисторах без регенерации и/или без питания). Механизм распределения ключей на производстве -- где гарантия что эти ключи кто-то не перепишет в файлик? Или что они не будут тупо идти по порядку: 1,2,3,4... Или умный программист сделает их "случайными". На базе библиотечной функции rand() -- берём ту же библиотеку, делаем srand(0) и генерим сколько нужно ключей. А если компоненты системы продаются или производятся раздельно и требуется их взаимная привязка в процессе установки и настройки? Ключи изначально утекают через канал связи -- о какой безопасности можно говорить потом. А в случае если одному из компонентов системы мы не можем доверять? Здесь сколько-нибудь адекватное решение лежит только в области несимметричных криптографических алгоритмов. Гораздо более ресурсоёмких, по отношению к МК. И даже здесь -- зачем генерить сертификат на каждую единицу изделия если можно зашить один на всех общий... идиотизм на местах может не знать границ...