Quelqu'un peut-il recommander une petite implémentation gratuite d'AES-128 Rijndael pour les microcontrôleurs. Idéalement, pour le PIC18, une implémentation générale en C serait utile.
La compilation de l'implémentation axTLS pour PIC18 et le chiffrement / déchiffrement d'un bloc nécessitent 6 Ko de ROM et 750 Mo de RAM.
La compilation de rijndael-alg-fst.c pour PIC18 et le chiffrement / déchiffrement d'un bloc nécessitent une mémoire vive de 28 Ko et une mémoire vive de 0,5 Ko.
La compilation de l’ AES 8 bits de Brian Gladman pour PIC18 et le chiffrement / déchiffrement d’un bloc nécessitent 19 Ko de ROM et 190 octets de RAM.
Existe-t-il des variantes optimisées spécifiques au PIC?
(exigences de RAM mises à jour pour la version axTLS)
pic
encryption
Toby Jaffey
la source
la source
Réponses:
Je me demande comment vous avez pu utiliser 7,5 Ko de RAM avec axTLS. En regardant le code, tout le contexte est stocké dans cette structure:
La taille de cette structure est 2 + 2 + 4 * 15 * 8 + 16 = 504. Je ne vois aucune variable globale dans aes.c, les variables automatiques étant toutes petites, l'utilisation de la pile est également raisonnable. Alors, où va 7,5 ko? Peut-être essayez-vous d'utiliser toute la bibliothèque au lieu d'en extraire l'implémentation AES?
Quoi qu'il en soit, cette mise en œuvre semble assez simple, je préfère m'en tenir à ce code et essayer de l'optimiser. Je sais que cela peut être délicat, mais l’apprentissage des détails de l’AES peut au moins vous aider à estimer l’utilisation minimale absolue de la mémoire RAM.
Mise à jour: je viens d’essayer de compiler cette bibliothèque sur Linux IA-32 et d’écrire un simple test de cryptage CBC AES-128. Vous obtenez les résultats suivants (le premier chiffre correspond à la longueur de la section hexadécimale):
C'est juste 660 octets de .bss (j'ai déclaré AES_CTX comme une variable globale). La plupart des fichiers .data sont occupés par IV et par clé. Je n'inclue pas .text ici, car vous obtiendrez un résultat totalement différent sur PIC (les sections de données devraient avoir presque la même taille sur les deux architectures).
la source
Je sais que cette question est un peu ancienne, mais je viens tout juste de faire des recherches moi-même, alors que je m’applique à AES128 sur un PIC16 et un 8051, et j’étais donc curieux de connaître cette question.
J'ai utilisé quelque chose comme ceci: http://cs.ucsb.edu/~koc/cs178/projects/JT/aes.c et mon utilisation de RAM est de quelques centaines d'octets et la taille binaire est inférieure à 3 Ko de ROM.
Mon meilleur conseil est de lire sur la page Wikipedia http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation et de comprendre les différents modes, par exemple comment AES en mode OFB utilise le mode ECB comme bloc de construction de base. De plus, le XOR (en mode OFB) en fait une opération symétrique. Crypter / décrypter est donc la même fonction, ce qui permet également de gagner de la place.
Lorsque j'ai compris le fonctionnement réel d'AES, je pouvais l'implémenter en C, puis le tester par rapport à la spécification NIST ** (beaucoup de code trouvé en ligne est défectueux) et ne mettre en œuvre que ce dont j'avais absolument besoin.
J'ai pu adapter AES128 sur un 8051 avec un autre micrologiciel RF en effectuant cette personnalisation et cette optimisation. L'utilisation de la mémoire RAM (pour l'ensemble du système) est passée d'environ 2,5 Ko à un peu moins de 2 Ko, ce qui signifie que nous n'avons pas eu besoin de passer à une 8051 avec SRAM de 4 Ko, mais que nous pouvions continuer à utiliser la version moins coûteuse de SRAM de 2 Ko.
** Les vecteurs de test figurent à l’Annexe F à l’ adresse suivante : http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf
MODIFIER:
Enfin obtenu le code sur Github: https://github.com/kokke/tiny-AES-c
J'ai optimisé un peu pour la taille. Sortie de taille GCC lors de la compilation pour ARM:
Ainsi, l’utilisation des ressources est désormais de 1 Ko, soit 204 octets de RAM.
Je ne me souviens pas comment construire pour le PIC, mais si le AVR Atmel Mega16 à 8 bits ressemble à un PIC, l'utilisation des ressources est la suivante:
Donc 1,5K code et 198bytes de RAM.
la source
J'ai récemment pris l'implémentation d'axTLS et j'ai travaillé à la réduire autant que possible. Vous pouvez facilement générer vous-même les boîtes S et économiser quelques centaines d’octets.
Vous pouvez obtenir le code complet à l’ adresse suivante : http://ccodeblog.wordpress.com/2012/05/25/aes-implementation-in-300-lines-of-code-
la source
Je réalise une implémentation en C, uniquement AES-128, appelée aes-min , avec licence MIT. Il cible les petits microprocesseurs (par exemple 8 bits) avec peu de RAM / ROM.
Il dispose d'un calcul de planification de clé à la volée facultatif pour réduire les besoins en mémoire (évitant ainsi la nécessité d'une planification de clé entièrement étendue dans la RAM).
la source
Vous pouvez trouver cette implémentation intéressante. C’est à partir d’un crypto-libary AVR open source.
Vous trouverez des informations générales (obsolètes) et des statistiques sur la taille du code et les performances ici .
AES:
Je n'ai joué qu'avec la source SHA-1 de cette librairie, donc je ne peux pas commenter sur AES.
la source
J'utilise l'implémentation de Texas pour msp430 dans un microcontrôleur Freescale S08SH8 avec 512 RAM et 8k de mémoire flash et également dans Arduino sans aucune retouche.
http://www.ti.com/lit/an/slaa547a/slaa547a.pdf
http://www.ti.com/tool/AES-128
la source
Le plus petit AES128 que j'ai écrit pour la série PIC peut fonctionner avec 900 instructions et 42 octets de RAM. Je l'utilise moi-même sur la série PIC12 mais le PIC10F206 est également possible :-).
Je ne peux pas divulguer le code car il provient de mon entreprise mais je l’ai écrit dans asm pour la série PIC10-12-16. Le cryptage prend 444 octets de code, y compris une table de consultation de 256 octets. Ce code incluait également la fonction de chargement de clé, soit environ 25 octets.
Je vous conseillerais de vérifier le papier AES et de le mettre en œuvre vous-même! La plupart des implémentations sont très mauvaises et utilisent beaucoup de ressources RAM et ROM.
J'ai également implémenté AES128 pour dsPIC et PIC24 et utilise environ 70% moins d'espace de code par rapport à la lib de microchip et mon code est également un peu plus rapide. Numéros d'implémentation de dsPIC et PIC24:
"Le cryptage prend environ 2995 cycles. 79.10uS @ 40 MIPS, 197.75uS @ 16 MIPS"
"DecKeySetup prend environ 567 cycles. 14.20uS @ 40 MIPS, 35.43uS @ 16 MIPS"
"Le déchiffrement prend environ 3886 cycles. 97.15uS @ 40 MIPS, 242.88uS @ 16 MIPS"
"La taille totale du code est de 1050 mots, y compris les tables."
La beauté du noyau PIC24 réside dans le fait que certaines instructions sont en 32 bits, ce qui simplifie grandement la tâche pour la construction d’une petite implémentation AES128. PIC32 ou autres processeurs 32 bits.
AES est très simple à mettre en œuvre que la plupart des gens n'essayent même pas!
Regardez le lien: http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf
la source