Библиотека AES Опции

[esaulenka]

Здравствуйте, коллеги.

Подскажите, пожалуйста, какую-нибудь библиотеку шифирования/дешифрования AES.
Целевая платформа - 8-битник, ОЗУ свободно около 150 байт.

Пока что нашёл https://github.com/kokke/tiny-AES128-C - там нужно около 200 байт.

Или идеями поделитесь, если в "кишках" этого AES'а копались.
Может, как-то расширение ключа делать по мере необходимости? Вроде б ничего не мешает хранить только текущий ключ...

[ar__systems]

Здравствуйте, коллеги.

Подскажите, пожалуйста, какую-нибудь библиотеку шифирования/дешифрования AES.
Целевая платформа - 8-битник, ОЗУ свободно около 150 байт.

Пока что нашёл https://github.com/kokke/tiny-AES128-C - там нужно около 200 байт.

нужен только AES? альтернативы не рассматриваете?

[esaulenka]

Уже успели пообещать, что у нас AES.
Идея "расширять ключ, когда потребуется" вполне рабочая, если использовать только один блок.
Для шифрования всё делается просто "влоб", для дешифрования надо изрядно подумать, но тоже можно.

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

[ar__systems]

вопрос насколько данные критичные и какова цена их потери. Если для галочки, то я бы советовал посмотреть xxtea

[esaulenka]

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

А чем плохи *TEA, что они "для галочки" ? Вроде б то же шифрование (о наличии "дырок" пока толком неизвестно), только перебирается на порядки быстрее.

[ar__systems]

А чем плохи *TEA, что они "для галочки" ? Вроде б то же шифрование (о наличии "дырок" пока толком неизвестно), только перебирается на порядки быстрее.

Ну как раз дырки таки известны... поэтом для какого-нибдуть SSL он не подойдет.

[esaulenka]

Почитал описание дырки. Нужно 5e17 запросов, чтобы подобрать ключ.

Предположим, что у злоумышленника есть зашифрованный текст, какие-то догадки по содержимому исходного текста (предположим, он знает половину из 16-ти байт) и медленный канал, по которому можно слать свои запросы. Ему надо уметь подделывать исходный текст, т.е. знать ключ.
Запрашивать что-то, предположим, можно, но явно не 5e17 раз (за сутки через канал пролезет сильно меньше миллиона пакетов. чисто физически).
В общем, кажется мне, эта дырка - не про embedded шифрование, когда скорость взлома перебором сильно ограничена.
Или я что-то принципиальное не понимаю?


PS нарыл микрочиповские app note http://www.microchip.com/Developmenttools/...PartNO=SW300052
Они молодцы, у них AES работает сильно быстрее, чем у нас получилось. Надо разбираться, их реализация по скорости очень нравится.
А вот XTEA у них получилось медленнее AES'а. Так что алгоритм *TEA на 8-битниках не очень-то и полезен...

PPS вот, кстати, ещё одна реализация, претендующая на супер-компактность: https://github.com/cmcqueen/aes-min

[Baser]

У Атмела есть Application Note
Atmel AVR231: AES Bootloader
Применял его на Меге128.
Внутрь не лез, применил как черный ящик, но там все исходники есть.
Гляньте, может быть там и компактно у них сделано.

[esaulenka]

Внутрь Atmel'овской реализации не полез, но судя по описанию, у них сделан стандартный вариант: сначала - key expansion (11 блоков по 16 байт), а потом - дешифрование этим ключом.
С учётом того, что им дешифровывать надо много, а свободной памяти в загрузчике обычно много, подход верный.

У меня была идея расширять ключ непосредственно перед очередным раундом шифрования. Это медленнее, если надо шифровать больше одного блока одним и тем же ключом, зато экономится 160 байт ОЗУ.
Как вчера выяснилось, это вовсе не моя идея, и в интернете полно таких реализаций :-)
Вот, например, ещё и сишные исходники от TI: http://downloads.ti.com/tsu_encryption/tsu...8.zip?tracked=1