[esaulenka 5]

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

 

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

Целевая платформа - 8-битник, ОЗУ свободно около 150 байт.

 

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

 

Или идеями поделитесь, если в "кишках" этого AES'а копались.

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

[slavka012 0]

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

 

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

Целевая платформа - 8-битник, ОЗУ свободно около 150 байт.

 

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

 

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

[esaulenka 5]

Уже успели пообещать, что у нас AES.

Идея "расширять ключ, когда потребуется" вполне рабочая, если использовать только один блок.

Для шифрования всё делается просто "влоб", для дешифрования надо изрядно подумать, но тоже можно.

 

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

[slavka012 0]

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

[esaulenka 5]

Если нехорошие люди смогут сделать "подслушивалку", цена репутации измеряется... Миллионами, наверное...

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

 

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

[slavka012 0]

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

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

[esaulenka 5]

Почитал описание дырки. Нужно 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 5]

У Атмела есть Application Note

Atmel AVR231: AES Bootloader

Применял его на Меге128.

Внутрь не лез, применил как черный ящик, но там все исходники есть.

Гляньте, может быть там и компактно у них сделано.

[esaulenka 5]

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

С учётом того, что им дешифровывать надо много, а свободной памяти в загрузчике обычно много, подход верный.

 

У меня была идея расширять ключ непосредственно перед очередным раундом шифрования. Это медленнее, если надо шифровать больше одного блока одним и тем же ключом, зато экономится 160 байт ОЗУ.

Как вчера выяснилось, это вовсе не моя идея, и в интернете полно таких реализаций :-)

Вот, например, ещё и сишные исходники от TI: http://downloads.ti.com/tsu_encryption/tsu...8.zip?tracked=1