Générateur de clés Base64

Comment générer une clé

1. Cliquez sur le préréglage qui correspond à ce que vous configurez. 32 octets est sélectionné à l’ouverture de la page.
2. Copiez la valeur dans Valeurs aléatoires. Les préréglages accompagnés d’une ligne de configuration, comme Laravel ou Auth.js, l’affichent aussi sous Prêt à coller.
3. Appuyez sur Générer à nouveau pour obtenir une autre clé, ou augmentez Combien pour en créer plusieurs d’un coup, par exemple une par environnement.

Les préréglages fixent pour vous le nombre d’octets et le format. Modifiez l’un de ces champs et l’outil repasse sur Personnalisé en gardant vos valeurs.

Les préréglages et l’usage de chaque clé

Le préréglage de nonce CSP répond à un autre besoin et a sa propre page, le générateur de nonce CSP.

Les tailles découlent des algorithmes. Les clés AES font exactement 16, 24 ou 32 octets ; toute autre taille est refusée. La RFC 7518 exige des secrets HS256 d’au moins 256 bits, d’où les 32 octets du préréglage JWT. Une clé HMAC plus courte que la sortie du hachage affaiblit HMAC : 32 octets conviennent donc à HMAC-SHA256 et le préréglage de 64 octets à HMAC-SHA512. Le préréglage Django tire ses 50 caractères par échantillonnage avec rejet, si bien que chaque caractère de l’alphabet a la même probabilité, comme avec la fonction get_random_secret_key() de Django.

Une clé Base64 est du texte, la clé, ce sont les octets

La valeur que vous copiez est la représentation Base64 d’octets aléatoires. Le code qui l’utilise doit d’abord la décoder :

import base64, os

key = base64.b64decode(os.environ["AES_KEY"])
assert len(key) == 32

En Node.js, l’équivalent est Buffer.from(process.env.AES_KEY, "base64"). Si vous passez directement la chaîne de 44 caractères à une bibliothèque AES, soit elle la refuse (AESGCM key must be 128, 192, or 256 bits en Python, Invalid key length en Node.js), soit, dans les bibliothèques moins strictes, elle utilise les mauvais octets sans rien signaler. Les frameworks qui lisent eux-mêmes leurs clés, comme Laravel avec son préfixe base64:, font ce décodage pour vous.

Base64URL et le Base64 standard se décodent en les mêmes octets, mais les parseurs sont souvent stricts sur la variante qu’ils acceptent. Gardez le format produit par le préréglage, sauf si vous savez que le destinataire accepte l’autre.

Clés Fernet et autres formats

Le paquet Python cryptography attend une clé Fernet de 32 octets en Base64 URL-safe avec remplissage, soit 44 caractères. Les préréglages JWT et Jeton d’API donnent la forme URL-safe sans le = : ajoutez-en un à la fin, ou générez la clé en Python :

from cryptography.fernet import Fernet

print(Fernet.generate_key().decode())

Pour tout le reste, partez du nombre d’octets : choisissez Personnalisé, saisissez le nombre d’octets indiqué par la documentation de votre bibliothèque et choisissez Base64, Base64URL ou hex. Le générateur de Base64 aléatoire explique les longueurs de sortie, et HMAC en Base64 ou le chiffrement AES permettent d’essayer tout de suite une nouvelle clé.

Que faire des clés une fois générées

Une clé générée ici n’existe que dans cet onglet jusqu’à ce que vous la copiiez. Ensuite, elle est aussi sûre que l’endroit où vous la collez. Gardez les clés de production dans le magasin de secrets de votre plateforme ou dans un gestionnaire de secrets, utilisez une clé différente par environnement et ne les commitez jamais ; une clé qui a atterri dans un dépôt Git doit être considérée comme publique et remplacée. Faire tourner une clé de chiffrement implique de rechiffrer les anciennes données ou de conserver l’ancienne clé pour le déchiffrement : prévoyez-le avant de remplacer une APP_KEY sur un système en production.

FAQ