Comment choisir un mode de cryptage AES (CBC ECB CTR OCB CFB) ?

Question

Lesquelles sont préférables dans quelles circonstances ?

J'aimerais voir la liste des critères d'évaluation pour les différents modes, et peut-être une discussion sur l'applicabilité de chaque critère.

Par exemple, Je pense que l'un des critères est la "taille du code" pour le cryptage et le décryptage, ce qui est important pour les systèmes intégrés à micro-code, comme les adaptateurs réseau 802.11. SI le code requis pour implémenter CBC est beaucoup plus petit que celui requis pour CTR (je ne sais pas si c'est vrai, c'est juste un exemple), alors je pourrais comprendre pourquoi le mode avec le plus petit code serait préféré. Mais si j'écris une application qui tourne sur un serveur, et que la bibliothèque AES que j'utilise implémente de toute façon à la fois CBC et CTR, alors ce critère n'est pas pertinent.

Vous voyez ce que je veux dire par "liste des critères d'évaluation et applicabilité de chaque critère" ?

Ce n'est pas vraiment lié à la programmation mais à l'algorithme.

Answer 1

Vous pourriez choisir en fonction de ce qui est largement disponible. Je me suis posé la même question et voici les résultats de mes recherches limitées.

Limites du matériel

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Limites des sources ouvertes

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Answer 2

Lisez les autres réponses, les recommandations contre ECB concernent la sécurité (la plupart ne mentionnent pas les raisons), et la facilité avec laquelle il peut être cassé.

Si vous choisissez CBC, CFB ou OFB, vous devrez envoyer avec vos données un vecteur d'initialisation (IV), qui est en fait quelque chose d'aléatoire (chaque fois que vous cryptez dans ces modes, le résultat crypté est différent). Vous ne pouvez décrypter les données que si vous avez le IV.

Si l'envoi d'une perfusion est incommode, impossible (restrictions de protocole, code déjà en place ou wtvr). ou ECB est le seul mode AES disponible, pour rendre ECB plus sûr, rembourrer le début des données à crypter avec des octets aléatoires (longueur variable en fonction de la valeur du premier octet) ; pas clavier aléatoire, mais aléatoire à chaque fois que l'on tamponne). GZip ou compressez les données avec ce dont vous disposez. Cryptez.

Après le décryptage et la décompression, il suffit de retirer le rembourrage avant d'utiliser les données.

Note : ECB crypte les blocs suivants NON en fonction de la façon dont le bloc précédent a été crypté (quelle que soit la quantité de données à crypter, le remplissage avec des octets aléatoires au début ne modifiera PAS tous les blocs, seulement le premier ou ceux que vous avez remplis). Ce problème est atténué par l'algorithme de compression et de remplissage aléatoire (cependant, cela ne fonctionne pas toujours - vous pourriez peut-être crypter en xor avec un mot de passe aléatoire stocké au début avant de crypter avec ECB).

Answer 3

Je connais un aspect : Bien que le CBC offre une meilleure sécurité en changeant le IV pour chaque bloc, il n'est pas applicable à un contenu crypté auquel on accède de manière aléatoire (comme un disque dur crypté).

Utilisez donc le CBC (et les autres modes séquentiels) pour les flux séquentiels et l'ECB pour les accès aléatoires.