esaulenka 7 1 июня, 2016 Опубликовано 1 июня, 2016 · Жалоба Здравствуйте, коллеги. Подскажите, пожалуйста, какую-нибудь библиотеку шифирования/дешифрования AES. Целевая платформа - 8-битник, ОЗУ свободно около 150 байт. Пока что нашёл https://github.com/kokke/tiny-AES128-C - там нужно около 200 байт. Или идеями поделитесь, если в "кишках" этого AES'а копались. Может, как-то расширение ключа делать по мере необходимости? Вроде б ничего не мешает хранить только текущий ключ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 6 июня, 2016 Опубликовано 6 июня, 2016 · Жалоба Здравствуйте, коллеги. Подскажите, пожалуйста, какую-нибудь библиотеку шифирования/дешифрования AES. Целевая платформа - 8-битник, ОЗУ свободно около 150 байт. Пока что нашёл https://github.com/kokke/tiny-AES128-C - там нужно около 200 байт. нужен только AES? альтернативы не рассматриваете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 6 июня, 2016 Опубликовано 6 июня, 2016 · Жалоба Уже успели пообещать, что у нас AES. Идея "расширять ключ, когда потребуется" вполне рабочая, если использовать только один блок. Для шифрования всё делается просто "влоб", для дешифрования надо изрядно подумать, но тоже можно. Но что-то подсказывает, что упрёмся в быстродействие, и будем смотреть что-то попроще... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 6 июня, 2016 Опубликовано 6 июня, 2016 · Жалоба вопрос насколько данные критичные и какова цена их потери. Если для галочки, то я бы советовал посмотреть xxtea Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 6 июня, 2016 Опубликовано 6 июня, 2016 · Жалоба Если нехорошие люди смогут сделать "подслушивалку", цена репутации измеряется... Миллионами, наверное... Другой вопрос, что ключи генерируются для каждого устройства (точнее, для пары), и "подслушивалка" должна быть довольно продвинутой. А чем плохи *TEA, что они "для галочки" ? Вроде б то же шифрование (о наличии "дырок" пока толком неизвестно), только перебирается на порядки быстрее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 6 июня, 2016 Опубликовано 6 июня, 2016 · Жалоба А чем плохи *TEA, что они "для галочки" ? Вроде б то же шифрование (о наличии "дырок" пока толком неизвестно), только перебирается на порядки быстрее. Ну как раз дырки таки известны... поэтом для какого-нибдуть SSL он не подойдет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 7 июня, 2016 Опубликовано 7 июня, 2016 · Жалоба Почитал описание дырки. Нужно 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 7 июня, 2016 Опубликовано 7 июня, 2016 · Жалоба У Атмела есть Application Note Atmel AVR231: AES Bootloader Применял его на Меге128. Внутрь не лез, применил как черный ящик, но там все исходники есть. Гляньте, может быть там и компактно у них сделано. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 8 июня, 2016 Опубликовано 8 июня, 2016 · Жалоба Внутрь Atmel'овской реализации не полез, но судя по описанию, у них сделан стандартный вариант: сначала - key expansion (11 блоков по 16 байт), а потом - дешифрование этим ключом. С учётом того, что им дешифровывать надо много, а свободной памяти в загрузчике обычно много, подход верный. У меня была идея расширять ключ непосредственно перед очередным раундом шифрования. Это медленнее, если надо шифровать больше одного блока одним и тем же ключом, зато экономится 160 байт ОЗУ. Как вчера выяснилось, это вовсе не моя идея, и в интернете полно таких реализаций :-) Вот, например, ещё и сишные исходники от TI: http://downloads.ti.com/tsu_encryption/tsu...8.zip?tracked=1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться