base32/

Le Base32 écrit chaque groupe de 5 octets en 8 caractères pris dans un alphabet de seulement 32 (A-Z et 2-7 dans la forme standard), donc la sortie est environ 60 % plus longue que l'entrée, alors que le Base64 n'ajoute qu'environ un tiers. En contrepartie, il ne distingue pas les majuscules des minuscules et n'a ni 0, ni 1, ni 8, ni 9, ce qui évite de le confondre avec les lettres O, I et B. Cela convient à la copie à la main, à la dictée et aux contextes insensibles à la casse, comme les clés 2FA et les noms de fichiers.

Le Base32 que vous rencontrez au quotidien, y compris les clés 2FA et la sortie par défaut de la plupart des bibliothèques, est la variante standard (RFC 4648, section 6, alphabet A-Z et 2-7). Le Base32Hex (section 7, alphabet 0-9 et A-V) conserve pour le texte encodé le même ordre de tri que pour les octets d'origine, ce qui explique son usage dans le NSEC3 de DNSSEC. Ils ne peuvent pas se décoder l'un l'autre : un mauvais choix donne souvent l'erreur « n'est pas un caractère Base32 », et parfois simplement du texte illisible.

Oui. Un secret TOTP (le paramètre secret du lien otpauth:// d'un QR code, ou la clé saisie à la main) est normalement en Base32 standard, en général en majuscules et sans =, parfois affiché en groupes de 4 caractères séparés par des espaces ; le décodage ici accepte tout cela. Le résultat est composé d'octets aléatoires et non de texte : cochez « Afficher le résultat en hex » pour le voir. Par exemple, JBSWY3DPEHPK3PXP donne 48 65 6c 6c 6f 21 de ad be ef. Pour générer des codes à usage unique, utilisez l'outil 2FA de ce site.

« Longueur non valide » signifie qu'après suppression des =, le nombre de caractères laisse un reste de 1, 3 ou 6 dans la division par 8 ; un Base32 valide ne laisse que 0, 2, 4, 5 ou 7, donc des caractères ont très probablement été perdus à la copie. « N'est pas un caractère Base32 » indique la position du caractère : la variante standard n'a ni 0, 1, 8 ou 9, ni ponctuation, ni caractères pleine largeur ; si le contenu comporte des caractères 0-9 et A-V, il s'agit peut-être de Base32Hex, changez alors la variante. « = ne peut apparaître qu'à la fin » signifie que du contenu suit un =, peut-être plusieurs chaînes collées ensemble, à décoder séparément. Les espaces, les sauts de ligne, les minuscules et un = manquant ne provoquent jamais d'erreur.

Les = complètent la longueur jusqu'à un multiple de 8 et ne font pas partie des données. Le décodage fonctionne avec ou sans ; à l'encodage, « Ajouter le padding = » est coché par défaut, décochez-le si vous n'en avez pas besoin. Pouvoir l'omettre dépend du destinataire : le format de lien otpauth de Google Authenticator indique que le secret n'a pas besoin de padding, on l'omet donc en général, alors que base64.b32decode de Python l'exige et lève Incorrect padding sans lui.

Cela signifie que les octets décodés ne sont pas du texte UTF-8. Les clés 2FA, les valeurs de hachage et les données chiffrées sont des données binaires à l'origine : cochez « Afficher le résultat en hex » pour voir les octets bruts. Cet outil n'affiche le texte qu'en UTF-8. Si le texte d'origine utilisait GBK ou un autre encodage, cochez d'abord hex, puis servez-vous de l'outil texte / hexadécimal de ce site en choisissant GBK pour retransformer les octets en texte.

Vérifiez trois points. D'abord, si la saisie se termine par un saut de ligne ou un espace en trop : cet outil encode en UTF-8 exactement ce qui est saisi, sans retirer les blancs en début ni en fin de texte. Ensuite, si la variante est la même : en Python, la forme standard est base64.b32encode et le Base32Hex est base64.b32hexencode (disponible depuis la version 3.10). Enfin, si le padding = est activé. Les variantes à alphabet différent, comme Crockford et z-base-32, ne sont pas prises en charge et ne donneront pas le même résultat.

Non. L'encodage et le décodage se font dans votre navigateur, n'envoient aucune requête et ne conservent rien ; une clé secrète 2FA ne quitte jamais votre navigateur.