В догонку, на счёт "кое-где". Это опять же типичный пример "мамой клянус, зашифровано!". Использовать CRC в качестве MAC-функции этот атас. Может кульхакер и не может понять что в сообщении, какие битики за что отвечают, зато он запросто может менять отдельные битики, например, и добиваться совпадения CRC. Ибо CRC не обладает никакими свойствами хеш-функции пригодной для применения в криптографии. Конечно на маленьких сообщениях это не так явно очевидно (вспоминая шикарный пример с MD5 и PDF (postscript) файлом). Более того, поскольку CRC там маленькой разрядности -- то можно устраивать брутфорс атаку и успешно один раз из N наталкиваться на совпадение CRC для случайных чисел (а оно ж эти команды выполнять начнёт!) Потом использование XTEA в чистом виде как есть (ECB mode), без вектора инициализации, позволяет во-первых обнаруживать повторяющийся текст, во-вторых имея plain text научиться его декодировать. Про смену ключа в документации написаны странные вещи, не понятно какой смысл такой смены ключей, если наблюдающий за каналом хакер получит новый ключ тоже. Защиту от replay attach изначально в протоколе не предусмотрели, потом тоже написаны какие-то странные вещи, честно говоря не вчитывался, но наводит на мысли, что от KeeLoq оно не далеко ушло (все знают, ага). Не понимаю даже почему так, ибо если у них "диалог", то решение очевидно, иначе же наиболее разумное -- нужны часы и какой-то метод их синхронизации (собственно для сетей без серверо-центрической архитектуры, видимо, что-то аналогичное).