Да, това е брой блокове дето да се декрептират, може да пускаш колкото си искаш наведнъж или да викаш функцията колкото пъти ти трябва...

По-важно е преди това да си извикал aes_tmos_de_key() с правилната дължина на ключа, защото от нея се смята броя на рундовете и се попълва в контекста... Дължината се задава в думи, аз съм и направил константи за по-сигурно (AES_256_KEY_SIZE)....

Това с грешката го видях, скоростта обаче нещо не ми харесва... Очаквах малко по-голяма разлика щото все пак ползвам 32-бит аритметика, макар че какво се учудвам нещо дето на М3 става с 1 инструкция аз го портнах с 4:



става на


Изобщо това механичното портване от една платформа на друга не е добра идея, ама нямам време сега да се занимавам. Ще гледам само да оправя да смята правилно пък друг път евентуално ще го оптимизирам...

Dimitar, открих малко грешки... сега вече връща същото като М3 версията, която знам че работи с AES128 и 192.

Обаче никога не съм тествал с AES256 и реални данни, пробвай (качено е на репа) и ако с твоите данни не излезе тогава ще го мисля

Миро, пробвах го на 16 байта, дето знам как трябва да се разкодират и не вади правилни данни. Не знам дали не правя нещо грешно - ей така го пробвам:
Първо в h файла промених #define ENCRYPTION_KEY_LENGTH да е 32 за 256 бита ключ и после в кода ей така:

И това, дето трябва да получа в tmp2 от кодираното tmp3 не е това, дето трябва да се получи.

Довечера ще пробвам повече - кажи дали не бъркам нещо.

Иначе за да пробваш и ти:

Абе Димитре ти си го пуснал на AES1024 бре

Казах ти че дължината на ключа е в думи, а не байтове... то така и цикли повече, виж пак скоростта




Аз ти получавам данните, макар че тествам на М3

Не ставаш да обясняваш като хората .
Значи инициализацията на ключа трябва да е:

а #define ENCRYPTION_KEY_LENGTH трябва да е 32, нали?
Довечера ще тествам пак.

да, бе то в хедъра си ми е дефинирано AES_256_KEY_SIZE...

btw то ти е мазало по паметта, ама явно имаш бол памет та не си го усетил
В твоя код си има ASSERT, ама аз нямам и каквато дължина дадеш с такава маже...

Миро, при мен пак не работи, но като оправих дължината на ключа и вече декодира 128 байта за 0.46msec, демек 278.2 килобайта за секунда.
Иначе аз го правя само в началото на програмата ми и да е омазало нещо из паметта, не е повлияло на нищо.
Не знам аз ли пак бъркам нещо - ето това правя:

И най-интересното е, че резултата tmp2 не се променя като се бъзикам с ключа или ако се променя се променят само някакви битове.
Ти освен тоя файл "aes_tmos.S" нещо друго променял ли си, щото аз само него и h файла подмених, след като каза че си оправил грешката?

Как така няма да се променя резултата, това е AES,, един бит на входа трябва да обръща изхода тотално.
Явно не си попълнил таблиците, само с нулеви таблици може да стане така. По-горе ти дадох един aes_test.cpp. В него с дефине първо се определя дали ще ползваш таблици от флаша или ще си ги генерираш в РАМ. После преди да ползваш контекста му попълваш указатели към таблиците и чак тогава викаш декрипт кеу....

Тоя файл с таблиците въобще не го бях видял - сега всичко бачка .
Обаче сега като ъпдейтвам целия файл и с твоя aes се бави повече с 150 msec за целия файл спрямо предишния aes, която нещо няма логика, ама довечера ще го гледам повече.

Важното е че бачка

Иначе, ето малко разяснения в случаи че не си задълбавал досега:

Първо има два начина на смятане - твоя код смята на 8-бит, моя е 32-бит. Аз ползвам 32-битовия щото съм го писал за куртекс М3/4 щото благодарение на инструкшън сета се постига 4 пъти по-висока скорост без да се раздува кода. Само forward и reverse таблиците от 256 байта стават на 1К, но тъй като обикновено ги слагам в RAM това не голям проблем.
При М0 кодът обаче се разду видимо.... освен това М0 по принцип е с малко RAM, така че не знам дали 8-битовия алгоритъм не е по-добро решение. Според твоите замервания излиза че е 4-5 пъти по-бърз, обаче според мен разликата трябва да е около и под 3 пъти. Мисля че ако твоя код се оптизира ще стигне към 100kB/s.

Относно таблиците, за размера казах вече разликата. За генерирането им - те са константи, може да ги набичиш във флаша ако искаш и няма да губиш време да ги генерираш. Иначе трябва ги генерираш (ЕДНОКРАТНО) след тръвагване на приложението. Там аз съм дал учебникарската функция, която не е оптимизирана изобщо, не съм сметнал за нужно...

Относно контекста...
Първо в него слагам указатели към таблиците, така съм решил че ще е по-гъвкаво щото не знам кой къде ще ги сложи и за да не се подават като параметри... Та просто трябва да сетнеш указателите и толкоз. Като не винаги са нужни всички таблици... при декриптиране едната не се ползва, при криптиране пък другата не се ползва, та затова единия от указателите може да е NULL...
Второто нещо след указателите е да инициализираш контекста спрямо ключа - това също е еднократно, т.е. викаш aes_tmos_de_key() само веднъж преди да отпочнеш. Ако я викаш на всеки блок естествено ще е много бавно, все едно слагаш sleep().
И накрая викаш само aes_tmos_de_ecb() толкова пъти колкото данни имаш. Разбира се ако ги имаш всички данни на куп може да я извикаш еднократно за съответния брой блокове (дължина).

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

Пробвах го тая сутрин с константните таблици (без да ги генерирам) и декриптирането на ключа и инициализацията на контекста ги викам само веднъж и после декриптирането на файла го правя на порции от по 128 байта, демек викам твоята функция само веднъж за всяка порция с 8 за брой блокове. С оригиналния аес правя същото, само че викам декриптирането 8 пъти, защото работи само на един блок от 16 байта. Демек според меренията и заради това че викам твоята функция само един път на 128 байта би трябвало с твоя алгоритъм да е доста по-бързо, а реално целия бутлоад се забави с 150 милисекунди като нищо друго не съм пипал, само съм сменил оригиналния аес с твоя. Мислиш ли че може да е щото таблиците са във флаша, а не в рам-а? Щото като го мерих преди и като не ги бях инициализирал явно е ползвал рама щото си е мислил, че са там. Довечера ще го премеря пак както са така таблиците да видя какво ще покаже.

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

Бе не ми се вярва... има едно четене на 6 инструкции средно, трябва мноооого да се забави това четене че да стане общо 4 пъти по-бавно

Миро, объркал съм се - твоя аес за целия файл от 13840 байта е с около 0.3 секунди по-бърз, което си е точно колкото трябва да е по-бърз по всички сметки.
Демек всичко е ОК. Големината на твоя код с таблици във флаша е около 6.5 килобайта - около 3 пъти повече от другия код, а не ми стигна рам да ги генерирам в рам-а таблиците.

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

Трябва да се оптимизира твоя код, но нито имам време нито зор да го правя. Предполагам и на теб не ти занимава, така че освен ако не намерим някой заек с мерак да се учи... аз ще му обясня какво трябва да се направи, само мераклия да има

"Моя" код е само 1.8к и ми се събира в бутлоадера, а с твоя бутлоадера стана 33к и излезна от заделените 32к за него,а трябва и да сменя sha256 с sha512, което ще глътне още памет. Та за сега оставам с него щото за пълен файл от 90к забавянето ще е само около 2 сек, което е пренебрежимо малко. Твоя съм го сложил в архива и ще знам, че ако ми потрябва скорост и паметта не е проблем има решение. Пък ти междувременно можеш да го резнеш на половина като имаш време .