woody, на м0 блок от 16 байта е около 10к цикъла за аес256, аес128 мисля пада до 6к цикъла .

виж си клока на който работи боотлоадера!

Работи на същия като апликейшъна - 48MHz.

Нещо е много зле в този сорс. Но път откъм добрата страна - можеш да гътнеш почти порядък.

EDIT ... ако имаш достатъчно флаш за таблиците.

Ето това е сорса, дето ползвам:
https://github.com/ctz/cifra

Идея си нямам калпав ли е, бавен ли е какво е - нали затова питам тук та да сравним .
Иначе не искам повече да раздувам флаша за бутлоадера с още таблици, щото и без това вече е 30к, т.е. доста си е голям.

Не съм замервал скорости, но на М3 @120Мхц изобщо не се усеща, със сигурност доста над 1MB/s... Понеделник ще погледна точно как бяха циклите, че го нямам кода сега а смотания гугъл не само че ми свалиха репозиторито ами и не ибават да си преиндексират. Още пренасочват към техния сървър дето вече го няма.
На М0 по принцип ще е по-бавно, вероятно и с по-нисък клок, но при всички случаи трябва да е 10-ки или 100-ци кБайта/с...

@woody, нещо се бъркаш... AES не се ускорява с таблици както е да кажем CRC, а друг е въпросът че по принцип при АРМ таблиците често водят до забавяне вместо да помагат

Баси не си знам репозиторито... но успях да си намеря файловете на сървъра на чичи гошо.

Сега пъй тоя сървър не ще асемблерски файлове, днес май сървърите са се наговорили нещо

Портването обаче ще е маалко сложничко, М0-та не може да ползва горните регистри като хората, май ще трябва аз да си ги портвам, иначе не е много кода, надявам се да съм успял да го прикача де...

На автора на блога пише 37кБ/сек за aes256 на М0+ ама моите наблюдения са други. Освен нещо друго да бърка работата. Днес ще пробвам да го премеря със скопа и ще видим.

Аз затова си направих да изровя асемблера...

Значи за разлика от твоя сорс тук прелюдиите са доста оптимизирани, практически е само самото декодиране, което е един цикъл и на око ги броя 60-на инструкции и се завърта 10-на пъти мисля бяха. Демек 600-700 инструкции за блок, айде заради load/store клоковете са малко повечко. Но нямат 1000 де. Това прави един байт за 60-на клока или около 2MB/s като за моя проц.

Да кажем че М0 е с 10 пъти по-нисък клок и заради проблема с регистрите му трябват 4 пъти повече инструции пак трябва да постига към 50к/с....
Май се сещам къде бъркаш... в твоя сорс видях една цялостна функция дето и даваш поинтер и дължина и тя пере и готви... Ако с нея мериш това обяснява проблема. Значи при AES има едно първоначално разджуркване на F/S боксовете с ключа. Но това се прави еднократно! След това няма не само че няма смисъл, ами може да се ресетваш само при някои от чипърите. Отделно ти в тоя куртекс едва ли имаш толкоз РАМ че да смелиш всичко... Затова в моя код се работи с контекст - първо си викаш инит на контекста с ключовете и след това с контекста декриптираш/криптираш колкото пъти искаш. Единственото ограничение е да го работиш с кратни на блока парчетам т.е. поне 16 байта.... Примерно за флашване може да работиш с пакети от 256 байта, получаваш един пакет, флашваш ги, получаваш следващ и т.н.
Но джуркането е само преди първия и затова аз не го броя в сметките, вероятно ти си го включил и него, щото те компилатора и сорсовете ти не добри, ама чак пък 100 пъти да са по-кофти - едва ли

Колко пък да се бъркам?

@Dimitar: целият проблем с използвания от теб сорс, е че на пръв поглед имплементацията е учебна - няма никакви алгоритмични оптимизации спрямо дефиницията на AES. Ето ти нещо (случайно) с таблици:
http://lxr.free-electrons.com/source/cr ... _generic.c

Стига да ти стигат ресурсите, естествено. Има и вариант, в който таблиците се смятат runtime, ако имаш достатъчно RAM.

При старите x86 шифтване с xor са две независими операции, които отнемат повече от 1 клок, докато работа с паметта е 1 клок. Тези таблици дето даваш са просто операция шифт на байт с xor. С таблица просто си гарантираш че какъв да е х86 даже без екстеншъни ще го направи за 1 клок.

При АРМ е точно обратното - две операции (шифт + add/xor/..) стават за 1 клок по принцип, докато работата с паметта при малките армчета е поне 2 клока. Така нещо дето го можеш за 1 клок го правиш за 2, но не е само това... за индексирането по таблица ти трябват 2 регистъра, като поне единия е овърхед. И ако алгоритъма е с голям шифт регистър, както в случая с AES трябваха към 10-на май за да минеш само с регистри, та мисълта ми беше че заради таблиците трябва да се лишиш от регистри, което значи че няма да завършиш целия цикъл и ще се наложиш да спасяваш и възстановяваш....
Така осирането става ТОТАЛНО, пак казвам заместваш една инструкция дето отнема 1 клок с нещо което може да ти струва 3-4-5-6 клока... Ако това наричаш ускорение

Намерих го къде е ключа за бараката:


Ако това CF_CACHE_SIDE_CHANNEL_PROTECTION е разрешено (пише че било за контролери с кеш) е около 71 пъти по-бавно и на М0+ AES256 декодира 864 байта за секунда.
Като го забраня това и скоростта се вдига на 61 килобайта за секунда и разликата за файла от 12.5 килобайта с криптиране и без криптиране е само 1 сек.
Така се ядва супер и не ми трябват никакви асемблери щото сега даже и с максималното приложение от 80к и двойно разкодиране (щото искам цифровата сигнатура да е на некодирания файл) целия ъпдейт ще отнеме най-много 20 секунди .
AES256 спрямо AES192 и AES128 е 100%:86%:73% - Демек няма идея да се ползва по-малко от AES256.

Миро, не ми се спори, а и е неделя освен всичко друго.

А на Димитър, ако смята че си е решил проблема - честито. Проверката е най-вероятно викане на функция за инвариантно минаване през кеша, за да няма изтичане ("leak") на информация, и от това се е бавело.

Въпреки, че е ясно че може да се оптимизира още много наистина проблема го смятам за решен, защото за целта по-бързо не ми и трябва .

Няма нищо лошо в споровете по принцип, а в случая на мен много би ми се искало да има някой с който да спорим на тема АРМ архитектура или алгоритми. Идея нямаш с кеф ще загубя такъв бас. Е примерно ако намериш по-бърз AES от моя за М3 веднага ти пращам каса бира... Обаче - уви, все няма такива мераклии и обикновено ми се налага да викам неволята