Найменша реалізація AES для мікроконтролерів?

Хто-небудь може порекомендувати невелику безкоштовну реалізацію AES-128 Rijndael для мікроконтролерів. В ідеалі для PIC18, хоча загальна реалізація в C була б корисною.

Для складання реалізації axTLS для PIC18 та шифрування / дешифрування блоку потрібно 6 КБ ПЗУ та 750b ОЗУ.

Для компіляції rijndael-alg-fst.c для PIC18 та шифрування / розшифровки блоку потрібно 28 КБ ПЗУ і 0,5 КБ оперативної пам’яті.

Для компіляції 8-бітного AES Брайана Гладмана для PIC18 та шифрування / розшифрування блоку потрібно 19 КБ ПЗУ та 190 байт оперативної пам’яті.

Чи доступні краще оптимізовані варіанти, специфічні для PIC?

(оновлені вимоги ОЗУ для версії axTLS)

Мені цікаво, як ви отримали 7,5 кБ оперативної пам’яті з axTLS. Дивлячись на код, у цій структурі зберігається весь контекст:

typedef struct aes_key_st 
{
    uint16_t rounds;
    uint16_t key_size;
    uint32_t ks[(AES_MAXROUNDS+1)*8];
    uint8_t iv[AES_IV_SIZE];
} AES_CTX;

Розмір цієї структури становить 2 + 2 + 4 * 15 * 8 + 16 = 504. Я не бачу глобальних змінних в aes.c, автоматичні змінні всі малі, тому використання стека також є розумним. То куди йде 7,5 КБ? Можливо, ви намагаєтесь використовувати всю бібліотеку, а не просто витягувати з неї реалізацію AES?

У будь-якому випадку ця реалізація виглядає досить просто, я б скоріше дотримувався цього коду і намагався його оптимізувати. Я знаю, що це може бути складним, але вивчення деталей AES може допомогти вам хоча б оцінити абсолютний мінімальний обсяг оперативної пам'яті.

Оновлення: Я щойно спробував скласти цю бібліотеку в IA-32 Linux і написати простий тест шифрування CBC AES-128. Отримали такі результати (перше число - це шістнадцятковий розмір секції):

 22 .data         00000028  0804a010  0804a010  00001010  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 23 .bss          00000294  0804a040  0804a040  00001038  2**5
                  ALLOC

Це всього 660 байт .bss (я оголосив AES_CTX як глобальну змінну). Більша частина .даних зайнята IV та ключовими. Я не включаю .text сюди, оскільки ви отримаєте абсолютно різні результати на PIC (розділи даних повинні бути приблизно однакового розміру для обох архітектур).

Я знаю, що це питання трохи старе, але я нещодавно мені довелося його самостійно досліджувати, коли я впроваджував AES128 на PIC16 та 8051, і тому мені було цікаво і це питання.

Я використовував щось подібне: http://cs.ucsb.edu/~koc/cs178/projects/JT/aes.c, і моє використання оперативної пам’яті становить пару сотень байт, а двійковий розмір менше 3 кб ПЗУ.

Моя найкраща порада - прочитати на сторінці Вікіпедії http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation та зрозуміти різні режими, наприклад, як AES в режимі сортування OFB використовує режим ECB як основний будівельний блок. Також XOR'ing (в режимі OFB) робить це симетричною операцією, тому шифрування / дешифрування - це та сама функція, яка також економить простір.

Коли я зрозумів, як AES насправді працює, я міг реалізувати його на C, а потім перевірити його на специфікацію NIST ** (зробіть це! Багато коду, знайденого в Інтернеті, є хибним) і реалізувати лише те, що мені абсолютно потрібно.

Мені вдалося помістити AES128 на 8051 разом з деякими іншими RF-прошивками, зробивши цю налаштування та оптимізацію. Використання оперативної пам’яті (для всієї системи) знизилося з ~ 2,5 кб до трохи нижче 2 кб, це означає, що нам не довелося оновити до 8051 з 4 кб SRAM, але ми могли продовжувати використовувати дешеву версію SRAM на 2 кб.

** Тестові вектори є у Додатку F: http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf

Редагувати:

Нарешті отримав код на Github: https://github.com/kokke/tiny-AES-c

Я трохи оптимізував розмір. Вихід розміру GCC при компіляції для ARM:

$ arm-none-eabi-gcc -O2 -c aes.c -o aes.o
$ size aes.o
   text    data     bss     dec     hex filename
   1024       0     204    1228     4cc aes.o

Тож використання ресурсу зараз становить 1 КБ, 204 байт оперативної пам’яті.

Я не пам'ятаю, як створити для PIC, але якщо 8-бітний AVR Atmel Mega16 є чимось схожим на PIC, використання ресурсів:

$ avr-gcc -Wall -Wextra -mmcu=atmega16 -O2 -c aes.c -o aes.o
$ avr-size aes.o
   text    data     bss     dec     hex filename
   1553       0     198    1751     6d7 aes.o

Так код 1,5 К і оперативна пам’ять 198 байт.

Нещодавно я взяв реалізацію axTLS і працював над тим, щоб зменшити її наскільки я міг. Ви можете легко генерувати S-скриньки самостійно і заощадити кілька сотень байт.

static uint8_t aes_sbox[256];   /** AES S-box  */
static uint8_t aes_isbox[256];  /** AES iS-box */
void AES_generateSBox(void)
{
    uint32_t t[256], i;
    uint32_t x;
    for (i = 0, x = 1; i < 256; i ++)
    {
        t[i] = x;
        x ^= (x << 1) ^ ((x >> 7) * 0x11B);
    }

    aes_sbox[0] = 0x63;
    for (i = 0; i < 255; i ++)
    {
        x = t[255 - i];
        x |= x << 8;
        x ^= (x >> 4) ^ (x >> 5) ^ (x >> 6) ^ (x >> 7);
        aes_sbox[t[i]] = (x ^ 0x63) & 0xFF;
    }
    for (i = 0; i < 256;i++)
    {
         aes_isbox[aes_sbox[i]]=i;
    }
}

Ви можете отримати повне джерело за посиланням: http://ccodeblog.wordpress.com/2012/05/25/aes-implementation-in-300-lines-of-code/

Я робив реалізацію лише в C, AES-128, що називається aes-min , з ліцензією MIT. Він орієнтований на невеликі мікропроцесори (наприклад, 8-розрядні) з невеликою кількістю ОЗУ / ПЗУ.

Він має необов'язковий розрахунок розкладу ключів на льоту, щоб зменшити потреби в пам'яті (уникаючи необхідності повного розкладеного розкладу ключів в оперативній пам'яті).

Ви можете знайти цю реалізацію цікавою. Це з криптовалюти з відкритим кодом AVR.

Ви можете знайти деякі загальні (застаріле) інформацію і статистичні дані про розмір коду та продуктивності тут .

AES:

Я грав лише з джерелом SHA-1 з цієї ліб, тому я не можу коментувати AES.

Я використовую реалізацію Техасу для msp430 в мікроконтролері Freescale S08SH8 з 512 ОЗУ та 8k спалаху, а також в Arduino без будь-яких змін.

http://www.ti.com/lit/an/slaa547a/slaa547a.pdf

http://www.ti.com/tool/AES-128

Найменший AES128, який я писав для серії PIC, може працювати в 900 інструкціях та 42 байтах оперативної пам’яті. Я використовую його сам на серії PIC12, але PIC10F206 також можливий :-).

Я не можу розкрити код, оскільки він отримав від моєї компанії, але я написав його в asm для серії PIC10-12-16. Шифрування займає 444 байти коду, включаючи таблицю пошуку в 256 байт, цей код також включає функцію завантаження ключа, яка становить близько 25 байт.

Я б радив перевірити папір AES і застосувати його самостійно !. Більшість реалізацій дуже погані і використовують шлях до великої кількості оперативної пам’яті.

Я також реалізував AES128 для dsPIC і PIC24 і використовую приблизно на 70% менше кодового простору порівняно з lib мікрочіпа, і мій код також трохи швидший. Номери реалізації dsPIC та PIC24:

"Шифрування займає близько 2995 циклів. 79.10uS @ 40 MIPS, 197.75uS @ 16 MIPS"

"DecKeySetup займає близько 567 циклів. 14.20uS @ 40 MIPS, 35.43uS @ 16 MIPS"

"Дешифрування займає приблизно 3886 циклів. 97.15uS @ 40 MIPS, 242.88uS @ 16 MIPS"

"Загальний розмір коду - 1050 слів, включаючи таблиці."

Краса ядра PIC24 полягає в тому, що деякі інструкції - це 32 біти, і це робить життя набагато простішим для створення невеликої реалізації AES128, мій код використовує всі 32-бітні інструкції, доступні, і він повністю працює в 32 бітах, тому я можу швидко перенести код на PIC32 або інші 32-бітні процесори.

AES дуже простий у здійсненні, тільки більшість людей навіть не намагаються !.

Подивіться за посиланням: http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf