Встречал кто-то полные исходники под АВР 8бит платформу.

Все что удалось найти из официальных источников это AVR231: AES Bootloader, но там не полный алгоритм, только часть шифрование,

Также был найден проект под пик "Advanced Encryption Standard Using the PIC" вещь понравилась но всё на асме, как то не хотелось переписывать велосипед.

А в остальном всё для РС и под СРР, если кто-то встречал , прозьба помочь.

С ув.

http://www.das-labor.org/wiki/Crypto-avr-lib сам не смотрел, но обещают много.

Не знаю где вы смотрели, но AVR231 имеет ПОЛНЫЙ готовый проект с чётким описанием под IAR C. И именно для AVR. Более того он реализован под разные процы. Причём реализован декодер. А шифровальщик реализован тоже, и находится в исходниках для GCC IBM. Есть также в исходниках и прога передающая.

Я, к примеру, подправил исходники под себя, переписал саму прогу передачи и получил готовый bootloader для rs485.

К слову очень многие пользуют именно эти исходники для написания. Так тут проскакивали сообщения, что по этим исходникам делали bootloader для ARM7.

Короче чё то вы не разобрались. Копайте глубже.
PS: Да и ещё. Воспользоваться исходниками от PIC на ASM мне почти не разу не удавалось. Как правило идёт ярко выраженная борьба программиста с кристаллом, оттачивается владение извращениями в программировании ну и борьба с железом в самом кристалле. Выудить из этого алгоритм самого действия - сложное занятие.

согдасен полностью с вами, но боюсь не осилю переписать с РС С++ на АВР С, вот поэтому и ищу вторую половинку

http://www.imagecraft.com/
В разделе ATMEL AVR
Compiler Tools

AVR231: AES Bootloader
This is a port of the Atmel Application Note AVR231: AES Bootloader to ICCAVR. This code contains: - AES Bootloader ported to an ICCAVR v7.xx project - Atmel utility applications ported to Microsoft Visual Studio 2005 solutions

Вы имеете ввиду шифратор?
Честно говоря он и на ПиСишке то не очень быстро пашет. А у меня не слабый проц и памяти хватает. Думаю под AVRом совсем тоскливо будет. Хотя если честно, то я не разбирался.

Это как со сжатием. Разжимает шустро, можно на лету делать, а вот сжатие весьма болезненно протекает.

на сайте микрочипа есть исходники AN953

вполне рабочие
http://www.microchip.com/stellent/idcplg?I...ppnote=en022056

тока их нет почему то на сайте , приложил во вложение





это как?
Алгоритм симметричный поэтому, должен за одинаковое время кодить/декодить.

Падаждите Так AES как и DES - симметричные. Так что по ресурсам один хрен. Только вот в бутлоадере там хитрость применена, заранее заготовленные таблицы вместо произвольного ключа, если я правильно понял. Так что более универсальный алгоритм будет малость похуже. Хотя надо внимательно разбираться.

К автору топика - если асилите, выложите, пожалуйста, исходники на общее обозрение. В хозяйстве пригодится.

это наверно S-блоки

А разве они зависят от ключа? Там именно при генерации ключа генерится не ключ, а какие-то таблицы, и записываются в отдельный файл, который инклудится на этапе компиляции лоадера. Вообщем, надо внимательно смотреть.

А вообще, всю эту красоту криптографическую имеет смысл под AVR плотнее затачивать. А то она уж очень много места жрет. Я тут с MD5 парился. Вроде чего там - обычный исходник, бери - собирай. Собираться то он собирается, но 6.5килобайт как с куста и немеряно озу. Пришлось пободаться. Сначала - включил кросскол (который у меня выключен обычно) и переписал фронт-энд - стало легче (2.5 килобайта). Потом переписал все - стал 1.7килобайта без кросскола. И расход озу упал на стеки и буфера. Даже, пожалуй, по производительности не проиграл, потому как все равно в регистрах все переменные не помещались.

AVR411

В нете есть такая книга, кому интересно можете поискать, очень интересно расписано, но для начинаючих сложновато будет.

Там сказано что этот алгоритм заточен под 8 и 32 битовую структуру, и разрабатывался как для широкого круга так и для мобильных устройств, даже сравнения размаров кода есть, жаль что АВР там нету



[КУДИЦ-Образ - Стандарт криптографической защиты - AES (Advanced Encryption Standart). Конечные поля.2002.djvu]




Огромное спасибо за исходники, их то я как раз и искал, я их так и не нашо в сети, даташит по ним пожалуйста а самих нету.

Гдето вычитал что у фирмы МИКРОЧИП из за них начались какието проблемы с законодательством, поэтому они их и прикрыли

Если жалко места и не жалко процессорного времени, можно использовать очень простой и надежный алгоритм XTEA.

http://ru.wikipedia.org/wiki/XTEA

Прям внизу страницы википедии ссылка на XXTEA


Конечно, надо читать, что там за уязвимость, может ломается не за возраст вселенной, а только за 1/10 этого возраста )

Я бы обратил внимание на алгоритм RC4 - простейшая реализация (правда, необходим буфер в ОЗУ на 256 байт). Вроде поиск по инету не говорит о каких либо серьезных уязвимостях.

Ну насчет лицензирования ничего говорить не буду, нам на это какать с высокой колокольни )

Пересобрал исходники AN953, спасибо digital.

Вроде всё работает, шифрует-дишефрует, только непонял ещё зачем нужна пепеременная calcKey.

Кстати собрал пиковские соурсы на IAR for AVR 4.21A под мегу8
размер кода 3.44кб

скорость работы
2.22мсек на кодировку и декодировку одного блока 16байт при 20мгц кваце,
при 1.0 мгц - 44.39мсек

правда пришлось стек подрулить до 0х80, ато сознание терять стал эмулятор


p.s.

забыл включить оптимизацию

по размеру
2.812кб--20мгц--2.81мсек
2.812кб--1мгц--56.23мсек

по скорости
2.968кб--20мгц--1.59мсек
2.968кб--1мгц--31.75мсек

Тут появился вопросик, незнаю как быть, домустим у меня идёт поток информации, я поочерёдно заполняю буфер, как только он достигает 16 байт, то всё нормально а если у меня остаётся хфост байтов от 1-15 ???

можно впринцыпе прогнать через крипт и так но потом как потом там определят что конец посылки не 16 а допустим 5байт

А как это у Вас без шифрования определяется? Длина где-то передается?

пока нет надо наверно городить какойто протокол верхнего уровня.

обычно дополняют нулями.



должна быть еще длина нешифрованого текста, т.к. шифрованый всегда выровнен по границе 16 байт

Если шифруете больше чем 16 байт, то надо шифровать не каждый блок в отдельности, а сцепляя их

Почитайте
http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%...%BD%D0%B8%D1%8F

использую ЕСВ раелизацию, каждый блок отдельно

Дополнение нулями считается очень плохой криптографической практикой. Существуют несколько стандартов более высокого уровня для конкретных приложений на базе AES, которые разбираются а не-кратными остатками исходного текста, например, стандарт дискового шифрования XTX (with CTS - cipher text stealing).

можно конечно было бы в памяти озу контроллера сделать виртуальный диск, и скидывать туда информацию через драйвер дискового шифрования, но думаю возни много будет

Использую AVR231: AES Bootloader для локальной и удаленной (по GPRS) перепрошивки устройств на базе меги 128. Пока не использовал в меге внешнее ОЗУ, Bootloader замечательно работал, но после того как к меге подцепил Wiznet на внешнюю шину и туда же ОЗУ и указал в компиляторе "использовать внешнее ОЗУ", то работать перестало. Т.е. мега зашитая программатором прекрасно работает, а зашитая бутлоадером - нет, как программа начинает обращаться к переменным из внешнего ОЗУ - все "падает".
Кто-нибудь сталкивался с подобным?
Спасибо.

А может, проблемы с внешним ОЗУ? Если тактовая частота высокая, далеко не все микросхемы RAM будут работать безошибочно. Проверьте тестами. Можно попробовать поставить ещё один такт задержки для обращения к внешней RAM.

Все таки большое подозрение, что дело не в ОЗУ, ОЗУ это я использую давно и никогда проблем не было. Та же самая программа, но прошитая в мегу обычным программатором - прекрасно работает с ОЗУ, а если эту прошивку закриптовать и раскриптовать во флеш бутлоадером, то вместо ОЗУ программа лезет черт знает куда. Даже проверял: помещаю массив во внутреннее ОЗУ, прошиваю бутлоадером - все работает, помещаю во внешнее, шью программатором - работает, бутлоадером - нет.
И еще одна проблема после прошивки бутлоадером: вызываю функцию явно - работает, по указателю - нет!

После прошивки бутлоадером прочитайте содержимое программатором и сравните с тем, что шьёте программатором.
Подозреваю, что будет разница.
По крайней мере будете знать, в бутлоадере ли дело.

Написал реализацию алгоритма AES-128. За день, без оптимизации. Как всегда, на 1С С эмуляцией XOR-ов, сдвигов, без квадратных массивов (их там просто нет ) и т.п.
Навскидку первые впечатления: дешифрование существенно более затратно чем шифрование - и по времени и по ресурсам. Несмотря на то, что алгоритм симметричный или как это там называется.
1) Если делать замены байтов через таблицы (а не математикой), то на этапе шифрования нам нужна одна таблица 256 байт, а при дешифровании две - прямая для получения всех расширений ключа и обратная для замен в раундах.
2) При шифровании мы можем помнить только ключ текущего раунда а последующие рассчитывать на его основе. При дешифровании нам надо сразу рассчитать прямым способом все ключи раундов и помнить их, ибо используются в обратном порядке
3) При операции MixColumns при кодировании используется хитрое умножение с переносом по модулю только на 2 и на 3, что достаточно лаконично реализуется в коде, а при дешифровании - гораздо больше и на бОльшие по значению константы, что явно не способствует скорости выполнения и даже является основанием для многочисленных исследовательских работ на эту тему - как оптимизировать процедуру InvMixColumns в AES

ЗЫ я дешифрование написал сам, просто выполняя операции шифрования в обратном порядке. Хотя во всем инете, просмотренном мной за вчера, на эту тему было написано имхо явно не то, то есть приведенные алгоритмы дешифрования НЕ являлись обратным порядком шифрования Правда, есть одна фраза, что существуют 2 алгоритма дешифрования AES - простой и эквивалентный, при последнем надо проделать InvMixColumns со всеми ключами раундов - то есть дополнительная операция, а в остальном вроде все так же, так что выигрыша нет - если я правильно понимаю.

Если позволите, выложу свою реализацию шифрации-дешифрации.

138 байт (можно 3...255) на 20 мегагерцах 10 миллисекунд
программа занимает ~450 байт (225 слов) из которых 256 байт кодирующий блок, грубо говоря пароль.

Извиняюсь за свой Algorithm Builder.

@ digital - присоединяюсь к спасибу за исходники! Интересна приведенная процедура получения ключа раунда при дешифровке DecKeySchedule, от последнего пошагово к предыдущему. Надо только проверить её работоспособность, так как применяется таблица прямых замен Sbox, а мне навскидку очень кажется что должна применяться обратная. Собственно, это логично - если есть прямое однозначное преобразование, то должно быть и обратное, только я не встречал упоминания этой возможности при описании алгоритма. А вот процедура inverse mix column имхо далеко не оптимальна - содержит очень много операций, да ещё и требует 3 таблицы замен по 256 байт каждая.

ЗЫ только что проверил в своем 1С-симуляторе. Да, как написано в исходниках - работает правильно. То есть, мы можем получать ключи раундов при расшифровке последовательным обратным преобразованием, начиная с последнего - к первому, исходному. Причем, используя таблицу прямых замен. Но я все равно подозреваю, что можно придумать алгоритм получения ключей раундов и с таблицей обратных замен. Зачем? Чтобы при расшифровке забыть про таблицу прямых замен вообще, а передавать не исходный ключ, а последние 16 байт расширенного Алгоритм от этого не станет несимметричным, а четверть килобайта сэкономим. Хотя, в AVR231 сделано хитрее - эта таблица создается через математику кода, производится расширение ключа а потом она стирается, но тоже лишние телодвижения

Один вопрос по теории AES шифрования. Функция mixcolumns и обратная ей. В спецификации сказано что произведение проводится по модулю 10011b. И тут я теряю понимание: ведь с таким модулем мы никогда не получим результат больше четвертой степени полинома. то есть больше 0x0F. Но ведь нас интересует результат равный целому байту а не 4 битам. Объясните что я неправильно понимаю.