AES, le big boss du chiffrement symétrique ?

Quand on parle de « cryptage » (le mot le plus adapté est « chiffrement« , même si ça fait moins hollywoodien), on distingue trois concepts principaux :

• Symétrique : On utilise la même clé pour le chiffrement et le déchiffrement d’un message.
  Algorithmes connus : AES, Serpent, Twofish, XChaCha20, …
  Exemples d’application : Gestionnaires de mots de passe, mais aussi les données envoyées et récupérées via HTTPS.
• Asymétrique : Un message est chiffré avec une clé publique (connue de tous) et déchiffré avec une clé privée (qui évidement n’est pas connue de tous).
  Algorithmes connus : RSA, DSA, ECC, …
  Exemples d’application : E-mails sécurisés avec PGP, initialisation des connexions HTTPS, certificats SSL/TLS, Blockchain.
• Hash : Bon ok, ce n’est pas une méthode de chiffrement, mais une méthode de transformation unidirectionnelle. Une fonction mathématique convertit un message en une chaîne de caractères unique. L’opération inverse est pratiquement impossible si l’algorithme est robuste.
  Algorithmes connus : MD5, SHA, RIPEMD, Whirlpool, …
  Exemples d’application : Vérification de l’intégrité des données (en comparant les hachages), enregistrement sécurisé des mots de passe en base de données (via des algorithmes comme bcrypt, argon2, …).

Aujourd’hui, nous allons parler de chiffrement symétrique avec AES !

Présentation de AES

AES, le fameux algorithme de chiffrement symétrique le plus utilisé au monde, réputé incassable même par les plus grandes agences gouvernementales. A-t-on encore besoin de le présenter ?

Eh bien, je pense que oui ! En réalité, en employant simplement « AES » pour le désigner, on oublie de rendre hommage à ses créateurs.
AES signifie Advanced Encryption Standard. Il s’agit du standard de chiffrement avancé qui a été adopté par le NIST (National Institute of Standards and Technology). Derrière ce nom se cache l’algorithme Rijndael (à prononcer « Rayndal »).

Un peu d’histoire

Rijndael a été immaginé en 1997 par Joan Daemen et Vincent Rijmen, deux chercheurs Belges. Son nom est une combinaison du nom de ceux de ses créateurs.

2 janvier 1997, l’Institut national des standards et de la technologie des États-Unis (National Institute of Standards and Technology, ou NIST) lance un appel aux cryptologues du monde entier. Son objectif : concevoir un nouvel algorithme pour remplacer le Triple DES, alors standard en vigueur, mais devenu potentiellement vulnérable face aux avancées technologiques. Aussi, des rumeurs laissent entendre que la NSA (National Security Agency of USA) pourrait être capable de casser ce chiffrement limité à des clés de 56 bits. Le futur standard, baptisé AES (Advanced Encryption Standard), devait répondre à un cahier des charges strict établi par le NIST.

Pas moins de 15 participants répondent à cet appel. Parmi eux, la France qui propose DFC, un algorithme conçu par des chercheurs de l’ENS et du CNRS. De leur côté, les Belges Joan Daemen et Vincent Rijmen soumettent leur création : Rijndael.

La communauté internationale de cryptographie est alors invitée à analyser les algorithmes candidats. Les critères d’évaluation sont stricts : sécurité, rapidité et compatibilité avec un large éventail d’environnements. Le rôle du NIST est de compiler et synthétiser les retours issus de ces tests rigoureux.

Mars 1999, lors d’une conférence, le NIST annonce l’élimination de cinq candidats :

• FROG (Costa Rica),
• Magenta (Allemagne),
• HPC (États-Unis),
• LOKI97 (Australie),
• DEAL (États-Unis et Danemark).

Ces algorithmes présentaient des failles de sécurité jugées rédhibitoires. De plus, plusieurs sources pointent du doigt la lenteur de Serpent (proposé par l’Angleterre, Israël et le Danemark) sur les processeurs Pentium. Cependant, sa marge de sécurité très élevée lui permet d’échapper à l’élimination à ce stade.

Août 1999, cinq autres candidats sont éliminés de la compétition :

• CAST-256 (Canada) : Bien que sa sécurité soit comparable à celle de Serpent, son implémentation était trop coûteuse, ce qui a conduit à son élimination.
• Crypton (Corée du Sud) : Sa marge de sécurité était inférieure à celle de ses concurrents. L’algorithme risquait de devenir obsolète trop rapidement avec l’évolution des technologies.
• DFC (France) : Comme Crypton, il offrait une marge de sécurité inférieure à celle des meilleurs candidats. De plus, il ne performait correctement que sur des processeurs 64 bits, ne respectant pas le critère clé de polyvalence du concours, qui exigeait une compatibilité avec un maximum d’environnements.
• E2 (Japon) : Semblable à DFC et Crypton en termes de sécurité réduite, il souffrait aussi d’un coût d’implémentation élevé, comparable à celui de CAST-256.
• SAFER+ (USA) : Malgré une sécurité équivalente à celle de Serpent, sa lenteur notable l’a désavantagé par rapport à ce dernier.

Restaient en compétition cinq candidats : MARS (USA), RC6 (USA), Rijndael (Belgique), Twofish (USA) et Serpent (Angleterre, Israël, Danemark). Ce dernier, malgré quelques lenteurs, parvenait à maintenir sa place dans le concours grâce à sa marge de sécurité impressionnante, qui le rendait plus résistant aux potentielles nouvelles attaques basées sur la cryptanalyse.

Le NIST lance un nouvel appel aux contributions pour tester les cinq finalistes. À ce moment-là, la NSA s’implique considérablement dans le processus. Aucun des finalistes ne présente de vulnérabilité susceptible de compromettre la sécurité du chiffrement.

Avril 2000, lors d’une conférence sur l’implémentation matérielle des algorithmes de chiffrement, il est annoncé que MARS présente des coûts importants pour une implémentation matérielle. RC6, quant à lui, rencontre de fortes difficultés d’utilisation hardware. Un sondage auprès des participants à la conférence fait ressortir Rijndael comme favoris.

Il semble ne rester en course que Rijndael, Twofish et Serpent. Twofish, dernier candidat américain et présentant d’excellents résultats. Il semble naturellement se dessiner comme le futur vainqueur de ce concours, qui, rappelons-le, est américain.
Ces trois algorithmes étaient tous d’excellents candidats. En effet, Serpent offre une très bonne marge de sécurité, ce qui le rend particulièrement durable dans le temps. Twofish, quant à lui, semble proposer une sécurité équivalente à celle de Rijndael et se révèle plus compétitif en software, mais moins en hardware. Rijndael, enfin, se distingue par son équilibre global, étant performant sur tous les points et plus équilibré que ses concurrents.

Nous sommes le 2 octobre 2000. À la grande surprise de la communauté cryptographique internationale et même des participants au concours, qui doutaient de l’adoption d’un standard américain conçu par un non-Américain, Rijndael, de conception belge, est déclaré vainqueur du concours.

Grâce à son équilibre optimal entre sécurité et performances, sa flexibilité et sa facilité d’implémentation, Rijndael est propulsé comme le meilleur algorithme de chiffrement symétrique au monde.

Quelques mois plus tard, le 26 novembre 2001, le NIST annonce que Rijndael devient le AES (Advanced Encryption Standard), le nouveau standard de chiffrement, par la publication du FIPS 197, qui reste la référence de base jusqu’à aujourd’hui.

En juin 2003, une directive impose à tous les départements du gouvernement américain l’adoption de l’AES comme standard. Les documents classés SECRET doivent être chiffrés avec une clé minimale de 128 bits, tandis que ceux classés TOP SECRET requièrent une clé de 192 bits. L’implémentation de l’AES doit être certifiée par la NSA. Ces directives ont été régulièrement confirmées depuis.

En 2022, la NSA publie le « Commercial National Security Algorithm Suite 2.0 », qui impose l’utilisation de l’AES avec une clé de 256 bits pour tous les documents classés à partir de SECRET. Une réflexion est lancée pour anticiper les potentielles vulnérabilités des algorithmes de chiffrement actuels face aux menaces posées par les ordinateurs quantiques.

AES est il encore ultra-safe ?

Avec une clé de 256 bits, il existe 2²⁵⁶ possibilités. Imaginons qu’un supercalculateur puisse effectuer 10¹⁸ tests par seconde (ce qui reste extrêmement optimiste). Il faudrait alors 2²⁵⁶ / 10¹⁸ secondes, soit environ 10⁵⁸ secondes.
Que dire de 10⁵⁸ secondes ? Cela représente environ 317 octillions d’années, soit :
317 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 ans.
Pour t’aider à mettre en perspective, le big bang s’est produit il y a environ 10¹⁸ secondes, soit :
13 700 000 000 ans.
😳

Attention, la robustesse de la clé est primordiale. En effet, face à un temps de force brute aussi démesuré, les attaques par brute force ne se baseront évidement pas sur l’essai de toutes les combinaisons possibles. Elles s’appuieront plutôt sur un échantillon beaucoup plus restreint, comme les dictionnaires, les générateurs de mots de passe et l’ingénierie sociale.

Une clé comme « youpi123 » sera évidemment cassée en moins de 10 secondes. Il est donc essentiel d’utiliser une clé à la fois longue, complexe et aussi aléatoire que possible.

Le fait que le gouvernement des États-Unis, et notamment la NSA, impose l’utilisation d’AES, est en soi, un gage de confiance.

À ce jour, personne n’a prouvé être capable de déchiffrer une donnée correctement chiffrée avec AES sans connaître la clé.

Certaines techniques d’attaque peuvent théoriquement réduire la complexité d’AES, mais aucune n’a permis de compromettre l’algorithme de manière significative.

L’algorithme quantique de Grover pourrait théoriquement réduire la complexité du brute-force de 2²⁵⁶ à 2¹²⁸ possibilité. Cela reste un nombre astronomique (environ 10¹⁹ secondes), et bien que la recherche sur l’informatique quantique progresse, ce genre de calcul est encore hors de portée des ordinateurs quantiques actuels.

Entrons dans le détail du fonctionnement technique de l’AES

AES est un algorithme de chiffrement symétrique, ce qui signifie qu’il utilise la même clé pour chiffrer et déchiffrer les données. Plusieurs séries d’opérations sont appliquées au message à chiffrer. L’une de ces opérations consiste notamment à introduire un brouillage dans les blocs de données à l’aide de la clé secrète. Cette clé secrète est la pierre angulaire du chiffrement, alors prenons le temps de l’examiner de plus près.

La clé secrète

AES supporte différentes tailles de clé pour le chiffrement : 128 bits, 192 bits et 256 bits. Évidemment, plus la clé est grande, plus le chiffrement est robuste.

Dans le cas d’un chiffrement automatique, comme avec le protocole HTTPS, il est facile de générer une clé secrète de la taille souhaitée, car nous, humains, ne la voyons jamais et n’avons pas besoin de la retenir ; c’est le navigateur qui s’en charge.

Mais dans le cas d’un gestionnaire de mots de passe, tu dois te souvenir de ta clé secrète (le mot de passe maître), sinon bye bye tous tes mots de passe. Et j’imagine que tu es conscient que si ton mot de passe est « youpi123 », soit 8 caractères de 8 bits chacun (en code ASCII), tu as une clé de 64 bits. Oups, on n’est pas encore à notre ultra-safe 256 bits ! Il nous faudrait 32 caractères pour atteindre cette longueur. Heureusement, il existe une technique pour étendre cette clé.

Pour cela, on va utiliser une fonction de dérivation, idéalement très robuste, pour éviter au maximum les collisions (lorsque deux clés secrètes différentes étendues donnent le même résultat). Pour simplifier, c’est une sorte de MD5 appliqué à ma clé secrète qui donnera 32 caractères, soit 256 bits.

En réalité, ce sont des algorithmes bien plus sophistiqués, appelés KDF (Key Derivation Function), qui sont utilisés. Ces algorithmes se basent généralement sur des fonctions de hachage (comme SHA-256), accompagnées d’un salt, et d’un nombre d’opérations élevé. Ce dernier facteur ajoute un temps de calcul considérable, rendant pratiquement impossible pour des machines puissantes de réaliser une attaque par force brute. Le salt aide aussi à contrer les attaques par rainbow tables et par dictionnaire.
L’objectif est d’obtenir une clé de 256 bits qui soit extrêmement unique, avec le minimum de collisions possibles, et surtout irréversible.

Tu comprendras donc qu’une clé de 256 bits générée à partir d’un mot de passe fort est bien plus sécurisée qu’un mot de passe trop faible, qui te rendrait vulnérable aux attaques par force brute.

Ok ! À ce stade nous avons notre clé de 256 bits !

La division en bloc

AES est un algorithme de chiffrement par blocs, ce qui signifie qu’il divise le message à chiffrer en blocs de 128 bits (soit 16 octets) avant de leur appliquer une série d’opérations pour les chiffrer. Peu importe que l’on utilise AES-128, AES-192 ou AES-256, la taille des blocs reste toujours de 128 bits. Il est donc important de noter qu’il existe une distinction entre la taille de la clé (qui peut être de 128, 192 ou 256 bits) et la taille des blocs (toujours de 128 bits).

Chaque bloc de 128 bits est chiffré indépendamment des autres. À aucun moment les blocs ne sont mélangés entre eux. Par exemple, il serait possible de ne déchiffrer que les 128 premiers bits d’un contenu chiffré si nécessaire.

À noter que le chiffrement n’affecte pas la taille d’origine du contenu à chiffrer. Si mon texte à chiffrer fait 10 Ko, alors mon texte chiffré fera également 10 Ko. À l’exception de certains logiciels qui ajoutent des métadonnées aux fichiers chiffrés, telles que des informations sur l’algorithme d’extension de la clé, l’algorithme de chiffrement, etc., pour faciliter le déchiffrement. Dans ce cas, la taille du fichier peut augmenter légèrement, mais ce n’est pas directement lié au chiffrement en lui-même.

Les tours (rounds)

Sur chacun de ces blocs de 128 bits, AES effectue 4 opérations, que nous détaillerons ci-dessous. Ces opérations sont répétées plusieurs fois, 14 fois pour être exact en AES-256. Ces répétitions sont appelées des tours (ou rounds). Il y aura 10 tours en AES-128 et 12 tours en AES-192.

Génération des rounds keys

Pour complexifier encore les choses, à chaque tour, une clé secrète différente sera utilisée. Heureusement, nous n’aurons pas besoin de retenir 14 clés différentes ; celles-ci seront générées à partir de notre clé secrète principale.

Avec une clé de 256 bits, nous devons effectuer 14 tours, ce qui signifie que nous avons besoin de 14 clés, plus une pour l’initialisation du chiffrement. Nous les appellerons des « roundKeys« . Pour les obtenir, nous allons diviser la clé principale en sous-blocs de 32 bits, ce qui nous donne 8 sous-blocs de 32 bits. À partir de ces sous-blocs, nous allons constituer nos 15 clés de 128 bits uniques. En effet, nos blocs à chiffrer font 128 bits, donc il nous faut des clés de 128 bits.

Plusieurs opérations logiques sont effectuées sur ces 8 sous-blocs pour obtenir nos 15 clés. Cela implique des rotations circulaires d’octets sur les sous-blocs, ainsi que des opérations logiques liées au numéro du tour. Il faut bien suivre pour saisir tous les détails, mais pour rester dans l’esprit de la vulgarisation, je te laisse consulter les sources pour des explications approfondies.

Bien ! Nous avons maintenant nos 15 roundKeys et nous pouvons commencer le chiffrement !

0 – Étape d’initialisation (AddRoundKey)

Chaque bloc de 128 bits de notre message à chiffrer est mélangé avec notre première roundKey. Dans cette première étape, notre message en clair est combiné avec la clé à l’aide d’une opération logique XOR.

L’opération XOR (ou « eXclusive OR ») est une opération binaire logique utilisée pour comparer deux valeurs bit par bit. Elle renvoie 1 si les bits sont différents et 0 s’ils sont identiques. ⊕ est le symbole de l’opération XOR

4D 6F 6E 20 6D 65 73 73 61 67 65 20 74 6F 70 20        # Mon bloc 128 bits
⊕                                                     # Symbole XOR
2B 7E 15 16 28 AE D2 A6 AB F7 09 CF 4F 3C 08 1D        # Ma clé initiale
=
66 11 7B 36 45 CB A1 D5 CA 90 6C EF 3B 53 78 3D        # Résultat du XOR

Les données ci-dessus sont en hexadécimal, Pour comprendre comment XOR fonctionne, il nous faut les convertir en binaire. Prenons par exemple les valeurs hexadécimales 4D et 2B :

4D s'écrit 01001101 en binaire
2B s'écrit 00101011 en binaire

01001101 ⊕ 00101011 = ?
On prend les premiers bits de chaque octet (0 et 0), ils sont identiques donc le résultat est 0. Les deuxièmes bits (1 et 0) sont différents donc le résultat est 1. Et ainsi de suite ...

Résultat : 01100110 qui s'écrit 66 en hexadécimal

L’initialisation est faite ! Nous allons maintenant répéter les étapes suivantes 14 fois (dans le cas de AES-256).

1 – Étape de remplacement (S-Box)

Chaque octet du bloc de 128bits est remplacé par un autre octet en fonction de la table S-Box. La table S-Box est fixe et connue, elle ne change jamais et est disponible dans la documentation d’AES. Cette étape est cruciale car elle introduit de la non-linéarité, ce qui renforce la résistance du chiffrement contre les attaques par analyse linéaire et différentielle.

C’est assez simple, je prend les bits de mon blocs en notation hexadécimal et je les transforme avec ce tableau. Si j’ai A9, je prend la ligne A et la colonne 9, j’obtiens : D3

66 11 7B 36 45 CB A1 D5 CA 90 6C EF 3B 53 78 3D    # Mon bloc 128 bits qui a commencé à être chiffré

66 => 33
11 => 82
7B => 21
...

33 82 21 05 6E 1F 32 03 74 60 50 DF E2 ED BC 27    # Résultat après passage dans la S-Box

Bien entendu, cette opération est réversible, et sa table de réversion est également accessible dans la documentation.

2 – Étape de déplacement circulaire matriciel (ShiftRows)

À cette étape, AES transforme les données en des matrices de 4 x 4 octets (16 octets). Ensuite, une opération de décalage est réalisée sur cette matrice.

• La première ligne reste inchangée, c’est-à-dire qu’aucun décalage n’est effectué.
• La deuxième ligne est décalée d’un octet vers la gauche.
• La troisième ligne est décalée de deux octets vers la gauche.
• La quatrième ligne est décalée de trois octets vers la gauche.

Cette opération contribue à la diffusion des données à travers les blocs et complique l’analyse du chiffrement.

3 – Étape de mélange (MixColumns)

Une étape un peu technique. Chaque chaque colonne de notre matrice précédente est transformé par une opération mathématique dans le champs de Galois. Outch … Pas facile à comprendre ça.
Concrètement, chaque colonne va être multipliée par une matrice fixe, définie pour l’AES, que voici :

| 02  03  01  01 |
| 01  02  03  01 |
| 01  01  02  03 |
| 03  01  01  02 |

Les éléments de cette matrice sont des coefficients dans le champ de Galois (GF(2^8))

B'=(02⋅B)⊕(03⋅F)⊕(01⋅J)⊕(01⋅N)
F'=(01⋅B)⊕(02⋅F)⊕(03⋅J)⊕(01⋅N)
J'=(01⋅B)⊕(01⋅F)⊕(02⋅J)⊕(03⋅N)
N'=(03⋅B)⊕(01⋅F)⊕(01⋅J)⊕(02⋅N)

Le symbole ⋅ représente la multiplication dans le champ de Galois GF(2⁸), et non pas une multiplication arithmétique classique.

Ça fait beaucoup trop chauffer les neurones, alors on ne va pas aller plus loin dans l’explication. Je te laisse faire des recherches à ce sujet si ça t’intéresse. Tu peux commencer par ici (à partir de la page 23). L’essentiel est de comprendre qu’on ajoute un brouillage supplémentaire, non linéaire, et que ce processus est réversible.

Cette étape n’est pas effectuée lors du dernier round.

4 – Étape de chiffrage (AddRoundKey)

De nouveau, chaque bloc est mélangé avec la roundKey du round en cours via une opération logique XOR. Cela fonctionne exactement comme pour l’étape 0, mais cette fois avec la clé du round en cours et les données issues de l’étape précédente.

A3 F2 C7 B9 E4 D5 A8 B5 F2 B9 C4 C7 F3 E5 A9 F0        # bloc 128 bits
⊕
D5 A1 B3 F9 C7 E5 A6 D9 F5 E3 C7 A9 D6 F2 B9 F0        # roundkey
=
76 53 74 60 23 30 2E 6C 47 7A 8F 6C 07 13 20 00        # Résultat du XOR

Et c’est reparti, on recommence !

Déchiffrage

Pour le déchiffrement, toutes les opérations précédentes sont effectuées dans le sens inverse.

Les remplacements par la S-Box sont réversibles, il suffit d’utiliser la table de réversion disponible dans la documentation AES (voir les sources).

Les déplacements circulaires d’octets sont également réversibles, il suffit de décaler dans l’autre sens.

Pour l’étape de mélange par transformation dans le champ de Galois, il « suffit » 😅 de multiplier par la matrice inverse :

| 0E  0B  0D  09 |
| 09  0E  0B  0D |
| 0D  09  0E  0B |
| 0B  0D  09  0E |

Enfin, les opérations logiques XOR utilisées pour le chiffrement sont naturellement réversibles.

bit_chiffré = bit_secret ⊕ bit_message
bit_message = bit_secret ⊕ bit_chiffré

1 ⊕ 1 = 0      En inversant      0 ⊕ 1 = 1
0 ⊕ 1 = 1        le sens         1 ⊕ 1 = 0  
1 ⊕ 0 = 1     on retombe sur     1 ⊕ 0 = 1
0 ⊕ 0 = 0    le bit d'origine    0 ⊕ 0 = 0

Bien entendu, sans la clé secrète, on se retrouve dans une impasse, et cette « soupe de bits » ne sera qu’un ensemble incompréhensible de données indigestes. Hé oui, la clé est essentielle !

Des outils pour chiffrer de façon symétrique

Quel sentiment de puissance lorsqu’on enferme une donnée dans un fichier que toi seul es capable d’ouvrir, la clé bien au chaud dans ta tête ! Si tu veux ressentir cette puissance, j’ai deux outils que j’utilise au quotidien à te recommander.

Pas de sponsorisation, juste deux projets gratuits et surtout open source.

1 – Veracrypt

LE logiciel à utiliser si tu veux mettre des données à l’abri de tout risque. Compatible Windows, Mac et Linux, c’est le digne successeur de Truecrypt et de sa fin tragique (pression de la NSA ? 🤔 mystère).

Il te permet de créer des containers chiffrés en AES et bien d’autres algorithmes de chiffrement réputés, dont l’excellent Serpent 🤩, et même de l’AES dans du Serpent qui lui-même est dans Twofish si tu es du genre gros parano. Tu y trouveras aussi des algos russes et japonais. Tu peux aussi choisir l’algorithme de dérivation de tes clés ou rajouter des fichiers de clés, rendant ta clé privée ultra-béton !

Comme je le disais, il est open source, ce qui permet un audit de sécurité ouvert à tous. Un rapport d’audit professionnel est disponible publiquement, garantissant qu’il ne contient pas de porte dérobée pour un éventuel gouvernement un peu trop curieux.

Un petit tips pour les agents secrets qui me lisent :
Il se peut que tu sois forcé de révéler ton mot de passe, sous la pression d’une autorité ou sous la torture, par exemple.
Veracrypt permet l’utilisation d’un volume caché. Concrètement, un faux mot de passe donne accès au container dans lequel tu as mis des données d’apparence sensibles. Mais un container caché est inclus dedans, et il est indétectable. Seul le vrai mot de passe pourra ouvrir ce container.

Site officiel

2 – KeespassXC

Un gestionnaire de mot de passe open source très complet.
Lui aussi compatible Windows, Mac et Linux.

Il te permet d’enregistrer l’ensemble de tes mots de passe au même endroit, protégés par un chiffrement AES-256, Twofish, ou même ChaCha20. Une seule clé maîtresse pour l’ensemble de tes mots de passe. Si tu ne le fais pas encore, alors fais-le !

À l’inverse des gestionnaires de mots de passe en ligne que je ne te recommande pas du tout, KeePassXC te permet de choisir où enregistrer tes mots de passe. Il te suffit de synchroniser le fichier .kdbx généré sur n’importe quel cloud (idéalement celui que tu auto-héberges, mais sinon rien de grave, c’est chiffré !). Tu pourras ainsi y accéder partout, même sur ton téléphone avec une application qui gère le format .kdbx.

Ce que permet keepassXC :

• Remplir automatiquement les champs login/mot de passe sur les navigateurs (avec une extension).
• Partager des bases de mots de passe entre plusieurs utilisateurs (KeeShare).
• Ajouter des clés à l’agent SSH pour se connecter en SSH sans mot de passe.
• Gérer la double authentification TOTP.
• Générer des mots de passe aléatoires forts.
• Vérifier que tes mots de passe ne sont pas compromis avec le service « Have I Been Pwned ».
• Ajouter des pièces jointes (comme des fichiers de clé privée, par exemple).
• Supporte les YubiKey / OnlyKey.
• Et d’autres petites surprises encore…

Bref, si tu n’as pas encore de gestionnaire de mots de passe ou si tu n’es pas pleinement satisfait de celui que tu utilises, jette un œil à ce projet ! Et n’oublie pas : des mots de passe forts, uniques par service, idéalement changés fréquemment, c’est la clé de la tranquillité. Ajoute à cela une double authentification TOTP dès que tu peux et tu peux dormir sur tes deux oreilles, tout est en sécurité grâce à AES !

Pssiit : Tu peux même ajouter un fichier de clé + un mot de passe pour déverrouiller ton keepassXC. Et si tu mettais ton fichier de clé dans un container Veracrypt ? 🤫

Site officiel

Conclusion

AES, ou Rijndael, est encore 25 après sa création l’un des meilleurs algorithmes de chiffrement symétrique et est très largement déployé dans de très nombreuses applications. Pari gagné car sa robustesse n’a jamais été ébranlée.

Mais n’oublions pas de mettre en perspective le but d’AES : forte sécurité, forte interopérabilité (software et hardware), bonne performance sur tout type de matériel, … Le concours AES ne se contentait pas de sélectionner un algorithme en se basant sur une sécurité ultime mais plutôt un juste équilibre entre sécurité, flexibilité et polyvalence. L’algorithme devait pouvoir être utilisé par des cartes électroniques, des routeurs, des processeurs, des logiciels, etc. AES est aujourd’hui partout, dans notre navigation internet, dans nos mails, dans le trafic entier de communication de serveur à serveur.

En comparaison aux 14 tours de chiffrement de AES, Serpent, lui, propose 32 rounds. Même si cela ne changera pas grand-chose face aux attaques conventionnelles, il sera plus robuste face aux attaques basées sur la cryptanalyse qui pourraient être découvertes à l’avenir. Mais déséquilibré sur les autres points, l’adoption à grande échelle de Serpent comme standard a été compromise. Malgré ça, il est considéré par beaucoup aujourd’hui comme l’algorithme de chiffrement symétrique le plus sûr. À noter aussi qu’il est compatible avec une clé de 512 bits. On refait le calcul sur le nombre de secondes qu’il faut pour le casser ? 🤯

Commence à émerger XChaCha20, un sérieux concurrent qui est de plus en plus utilisé par de grands groupes privés. Sur le papier, il offre de meilleures performances, une mise en œuvre simplifiée et une sécurité plus ou moins équivalente à AES. Il reste pour le moment assez jeune, donc plus sujet à d’éventuelles failles, alors que AES a fini son rodage depuis longtemps.

Alors AES, big boss du chiffrement symétrique ? À toi de me le dire !

Sources :

• Livre « The Design of Rijndael: AES – The Advanced Encryption Standard » par Joan Daemen et Vincent Rijmen.
• Federal Information Processing Standards Publication 197 (FIPS PUB 197)
• Commercial National Security Algorithm Suite 2.0
• Commercial National Security Algorithm Suite and Quantum Computing FAQ
• Directive CNSSP-15