.
Image de WikpediaL’avantage est , contrairement au CBC, le cryptage peut être effectué en parallèle et tous les blocs dépendent de l’IV, pas seulement le premier. Une grosse mise en garde est, qu’un IV ne doit jamais être réutilisé avec la même clé car un attaquant peut trivialement calculer la clé utilisée à partir de cela.
Puis-je être sûr que personne n’a modifié mon message ?
La dure vérité : le cryptage ne protège pas automatiquement contre la modification des données. Il s’agit en fait d’une attaque assez courante. Lisez ici une discussion plus approfondie sur cette question.
Alors que pouvons-nous faire ? Nous ajoutons simplement un code d’authentification de message (MAC) au message crypté. Un MAC est similaire à une signature numérique, à la différence que la clé de vérification et la clé d’authentification sont pratiquement les mêmes. Il existe différentes variantes de cette méthode, le mode qui est recommandé par la plupart des chercheurs est appelé Encrypt-then-Mac. C’est-à-dire qu’après le cryptage, un MAC est calculé sur le texte chiffré et ajouté. Vous utiliserez généralement le code d’authentification de message basé sur le hachage (HMAC) comme type de MAC.
Alors, maintenant, ça commence à se compliquer. Pour l’intégrité/authenticité, nous devons choisir un algorithme MAC, choisir un mode de balise de chiffrement, calculer le mac et l’annexer. Cela est également lent puisque l’ensemble du message doit être traité deux fois. Le côté opposé doit faire de même mais pour le décryptage et la vérification.
Cryptage authentifié avec GCM
Ce ne serait pas génial s’il y avait des modes qui gèrent tous les trucs d’authentification pour vous ? Heureusement, il existe une chose appelée cryptage authentifié qui fournit simultanément des assurances de confidentialité, d’intégrité et d’authenticité sur les données. L’un des modes de bloc les plus populaires qui supporte cela est appelé Galois/Counter Mode ou GCM pour faire court (il est par exemple également disponible en tant que suite de chiffrement dans TLS v1.2)
GCM est fondamentalement un mode CTR qui calcule également une balise d’authentification de manière séquentielle pendant le chiffrement. Cette balise d’authentification est ensuite généralement annexée au texte chiffré. Sa taille est une propriété de sécurité importante, elle doit donc avoir une longueur d’au moins 128 bits.
Il est également possible d’authentifier des informations supplémentaires non incluses dans le texte en clair. Ces données sont appelées données associées. Pourquoi sont-elles utiles ? Par exemple, les données cryptées ont une méta-propriété, la date de création, qui est utilisée pour vérifier si le contenu doit être re-crypté. Un attaquant pourrait maintenant modifier trivialement la date de création, mais si elle est ajoutée en tant que donnée associée, GCM vérifiera également cet élément d’information et reconnaîtra le changement.
Une discussion animée : Quelle taille de clé utiliser ?
L’intuition dit : plus c’est gros, mieux c’est – il est évident qu’il est plus difficile de forcer brutalement une valeur aléatoire de 256 bits qu’une de 128 bits. Avec nos connaissances actuelles, le forçage brutal de toutes les valeurs d’un mot de 128 bits nécessiterait une quantité astronomique d’énergie, ce qui n’est pas réaliste pour quiconque à une époque raisonnable (je vous regarde, NSA). Donc la décision est fondamentalement entre l’infini et l’infini fois 2¹²⁸.
AES a en fait trois tailles de clés distinctes parce qu’il a été choisi comme un algorithme fédéral américain apte à être utilisé dans divers domaines sous le contrôle du gouvernement fédéral américain . (…) Les fins cerveaux militaires ont donc eu l’idée qu’il devait y avoir trois « niveaux de sécurité », afin que les secrets les plus importants soient cryptés avec les méthodes lourdes qu’ils méritent, mais que les données de moindre valeur tactique puissent être cryptées avec des algorithmes plus pratiques, bien que plus faibles. (…) Le NIST a donc décidé de suivre formellement la réglementation (demander trois tailles de clés) mais aussi de faire le plus intelligent (le niveau le plus bas devait être incassable avec une technologie prévisible)(Source)
L’argument est le suivant : un message chiffré en AES ne sera probablement pas cassé par brute forcing de la clé, mais par d’autres attaques moins coûteuses (non connues actuellement). Ces attaques seront aussi néfastes au mode de clé de 128 bits qu’au mode de 256 bits, donc choisir une taille de clé plus grande ne sert à rien dans ce cas.
Donc, fondamentalement, une clé de 128 bits est une sécurité suffisante pour la plupart des cas d’utilisation, à l’exception de la protection par ordinateur quantique. De plus, l’utilisation d’une clé de 128 bits permet de chiffrer plus rapidement qu’une clé de 256 bits et le schéma de clés pour les clés de 128 bits semble être mieux protégé contre les attaques par clé connexe (cependant, cela n’est pas pertinent pour la plupart des utilisations dans le monde réel).
En guise de note latérale : les attaques par canal secondaire
Les attaques par canal secondaire sont des attaques qui visent à exploiter des problèmes spécifiques à certaines implémentations. Les schémas de chiffrement eux-mêmes ne peuvent pas être intrinsèquement protégés contre elles. Les implémentations AES simples peuvent être sujettes à des attaques de synchronisation et de cache, entre autres.
A titre d’exemple très basique : un algorithme simple qui est sujet à des attaques de synchronisation est une méthode equals()
qui compare deux tableaux d’octets secrets. Si la equals()
a un retour rapide, c’est-à-dire qu’après la première paire d’octets qui ne correspondent pas, elle termine la boucle, un attaquant peut mesurer le temps que met la equals()
à se terminer et peut deviner octet par octet jusqu’à ce que tous correspondent.