0 bits d'entropie
Longueur de clé
Encodage
Des clés AES aléatoires de 128, 192 et 256 bits, générées dans votre navigateur. Aucun réseau, aucun journal, aucun envoi.
Appuyez sur Espace pour regénérer, C pour copier. Généré par crypto.getRandomValues sur votre appareil ; la page ne charge aucune ressource externe.
Une clé AES est un bloc d'octets aléatoires de longueur fixe : 16 pour AES-128, 24 pour AES-192, 32 pour AES-256. Contrairement à un mot de passe, il n'y a ni minimum ni maximum à arbitrer — l'algorithme n'accepte que l'une de ces trois longueurs, et chacun de ses bits doit être impossible à deviner.
Les octets proviennent directement de crypto.getRandomValues, le générateur de nombres aléatoires cryptographiquement sûr du navigateur, puis sont écrits en hexadécimal ou en Base64. Ni horodatage, ni compteur, ni Math.random sur ce chemin. Les deux écritures portent les mêmes octets : prenez celle qu'attend votre bibliothèque ou votre coffre à clés.
Tout se passe sur votre appareil. La page n'émet aucune requête réseau une fois chargée : cette clé n'a donc jamais existé ailleurs et ne circule nulle part. Rechargez et elle disparaît.
AES-256, sauf contrainte contraire — non parce que 128 serait cassable, mais parce que la clé plus longue ne coûte presque rien et clôt la question pour de bon. AES-128 reste parfaitement sûr face à la force brute et se révèle nettement plus rapide sur du matériel sans accélération AES. AES-192 existe et fonctionne, mais il est si peu utilisé que certaines bibliothèques et certains chemins matériels le traitent moins bien que les deux autres.
Non : l'écart est de 2^128 fois, pas de deux. Mais les deux nombres dépassent depuis longtemps le seuil où la force brute veut encore dire quelque chose — compter jusqu'à 2^128 excède le budget énergétique de la planète, quel que soit le matériel imaginé. Ce n'est pas la taille de clé qui fait tomber les systèmes réels, mais les nonces réutilisés, les clés dérivées de mots de passe et les clés rangées à côté des données qu'elles protègent.
Non, et confondre les deux est l'erreur la plus fréquente avec AES. La clé est un secret de longue durée. L'IV (le nonce en GCM) est une valeur propre à chaque message, absolument pas secrète, transmise en clair à côté du chiffré la plupart du temps. Générez un IV neuf pour chaque message ; générez une clé une fois et conservez-la.
Non. Une clé chiffre de nombreux messages, à condition que chacun ait son propre IV ou nonce. Ce qui ne doit jamais se répéter, c'est le nonce sous une même clé : en GCM, le réutiliser divulgue le XOR de deux textes clairs et permet à un attaquant de forger des messages — une rupture totale, pas un affaiblissement marginal. L'usage est un nonce aléatoire de 96 bits par message.
Pas directement. Un mot de passe est court et tiré d'un petit espace, alors qu'une clé AES doit être indiscernable de l'aléatoire. Si l'entrée doit être mémorisée par un humain, passez-la dans une fonction de dérivation — Argon2id, scrypt, ou PBKDF2 avec un nombre élevé d'itérations — et servez-vous de la sortie comme clé. Hacher une fois un mot de passe en SHA-256 donne bien 32 octets, mais pas 32 octets d'imprévisibilité.
GCM, dans presque tous les cas. Il authentifie en plus de chiffrer : altérer le chiffré est détecté au lieu d'être déchiffré silencieusement en données absurdes que votre code prendra ensuite pour argent comptant. CBC seul n'offre aucune intégrité et doit être associé à un MAC distinct, appliqué dans le bon ordre — exactement le genre de détail qui casse sans bruit.
Les mêmes octets dans les deux cas : une clé de 256 bits fait 64 caractères en hexadécimal ou 44 en Base64, pour une robustesse identique. Utilisez le format attendu par le système destinataire : les coffres à clés dans le nuage et les bibliothèques des langages réclament souvent du Base64, tandis que les fichiers de configuration, les options de ligne de commande et tout ce qui traverse un shell passent mieux en hexadécimal, qui ne contient que 0-9 et a-f.
Dans un service de gestion de clés si vous en avez un, sinon dans une variable d'environnement ou un fichier de secrets tenu hors du contrôle de version. Jamais à côté du chiffré qu'elle protège : une clé rangée dans la même base, la même sauvegarde ou le même dépôt que les données n'offre plus rien dès que ce stockage est copié. Notez aussi que changer une clé AES suppose de rechiffrer les données, si bien que la rotation demande un plan et non une simple tâche planifiée.
Uniquement si la page ne peut pas la transmettre, et cela se vérifie au lieu de se supposer. Ouvrez les outils de développement, restez sur l'onglet Réseau et générez autant de clés que vous voulez : rien n'est demandé après le chargement. Aucun serveur derrière pour recevoir quoi que ce soit, aucune mesure d'audience ni script tiers pour la laisser fuir.