Méthodologie des outils développeur

Le cluster Codepropose dix utilitaires, tous s’exécutant entièrement dans le navigateur et aucun n’envoyant sa charge utile où que ce soit. Cette page documente ce que chaque outil fait réellement — les RFC auxquelles ils se conforment, les primitives qu’ils utilisent, et ce qu’ils ne font délibérément pas.

Base64 (RFC 4648)

Alphabet standard : A-Z a-z 0-9 + /, rembourré avec = pour des multiples de 4. La variante URL-safe (base64url) remplace + par - et / par _, sans rembourrage.

Implémentation : le btoa / atobnatif de JavaScript gère l’encodage, mais ils ne supportent que les chaînes Latin-1 (chaque octet est un caractère). Pour UTF-8, nous encodons d’abord la chaîne avecTextEncoder, puis exécutons btoasur le tableau d’octets résultant. C’est le seul moyen de Base64-encoder un texte Unicode arbitraire dans le navigateur sans dépendances.

Décodeur JWT (inspection uniquement, sans vérification)

Les JWT (RFC 7519) sont trois segments encodés en base64url séparés par des points : header.payload.signature. Notre décodeur divise, décode en base64url l’en-tête et la charge utile, les analyse comme JSON et affiche le résultat. Nous ne vérifions pas la signature.

La vérification de signature nécessite la clé de signature — typiquement un secret HMAC ou une clé publique RSA/ECDSA — qui doit venir de l’émetteur. Un outil uniquement navigateur ne peut pas vérifier de façon significative un JWT émis par une tierce partie, donc nous ne prétendons pas le faire. Utilisez le décodeur pour l’inspection ; utilisez le stack côté serveur de votre application pour la vérification réelle.

Convertisseur de casse

Traduit entre camelCase, snake_case, kebab-case, PascalCase, CONSTANT_CASE, Title Case, Sentence case et minuscules / MAJUSCULES. L’algorithme divise l’entrée en “mots” en utilisant une regex qui correspond aux transitions de casse, tirets, underscores et espaces, puis réassemble dans la convention cible.

Cas limite : les chiffres dans les identifiants. Notre convention est de traiter les frontières chiffre-lettre comme des frontières de mots (ainsi parseInt32 se divise en parse, int, 32) mais pas de diviser les frontières lettre-chiffre dans des séquences clairement identifiantes (ainsi md5reste un seul mot, pas md_5).

Générateur de hash

SHA-1, SHA-256, SHA-384, SHA-512 via l’API Web Crypto (crypto.subtle.digest), qui est une fine couche au-dessus de l’implémentation native du système d’exploitation. Nous n’incluons délibérément pas MD5 — le navigateur ne le fournit pas nativement (car il est cryptographiquement cassé), et nous préférons ne pas importer un shim de 2 Ko pour supporter une fonction de hachage que personne ne devrait utiliser pour quoi que ce soit de sensible à la sécurité.

La sortie est en hexadécimal minuscule. Toutes les opérations sont synchrones du point de vue de l’utilisateur malgré l’API Web Crypto étant asynchrone — la latence sur les appareils modernes est inférieure à la milliseconde pour les entrées inférieures à un mégaoctet.

Générateur UUID

Deux variantes :

• v4 (aléatoire) : crypto.randomUUID() quand disponible, avec un repli sur un générateur manuel piloté par crypto.getRandomValues. 122 bits d’entropie.
• v7 (horodatage + aléatoire) : 48 bits d’horodatage Unix ms + 74 bits d’aléatoire. Triable par heure de génération, ce qui fait de v7 le choix préféré pour les clés primaires de base de données.

Générateur de mot de passe

Utilise crypto.getRandomValuesavec rejection sampling contre le plus grand multiple de la taille du jeu de caractères qui tient dans un uint32. Cela élimine le biais modulo — l’approche naïve random32 % charsetSizeest biaisée quand charsetSize ne divise pas 2³² exactement, ce qui est le cas de tout jeu de caractères réaliste.

L’entropie est calculée comme longueur × log₂(jeuCaractères) bits et affichée en temps réel. L’étiquette de force mappe l’entropie sur cinq bandes (très faible / faible / acceptable / fort / très fort) avec des seuils correspondant aux recommandations de sécurité courantes (NIST SP 800-63B recommande ≥ 80 bits pour un usage à fort enjeu).

Détails de l’algorithme : les primitives d’entropie et d’aléatoire

Les générateurs de mots de passe et d’UUID sont les seuls outils de ce cluster qui dépendent d’un aléatoire cryptographiquement fort ; leur exactitude repose sur deux primitives navigateur.

Sélection de caractères non biaisée (rejection sampling)

Étant donné un jeu de caractères de taille K et un tirage aléatoire 32 bits non signé r, le naïfr % K est biaisé vers les indices plus petits sauf si K divise 2³². Nous calculons seuil = 2³² − (2³² mod K), tirons, et rejetons tout r ≥ seuil. Nombre de tirages attendus par caractère : < 1,05 pour toutK ≤ 2³²/16. La sortie est uniformément distribuée sur le jeu de caractères.

Comptabilité de l’entropie

L’entropie du mot de passe est longueur × log₂(K) bits. Nos bandes de force suivent les recommandations du NIST SP 800-63B :

Structure UUID v7 (RFC 9562)

bits[0..47]   = unix_ms (48 bits)
bits[48..51]  = version = 0111 (4 bits)
bits[52..61]  = aléatoire ou compteur sub-ms (10 bits)
bits[62..63]  = variant = 10 (2 bits)
bits[64..127] = aléatoire (64 bits)
total aléatoire : 74 bits — résistant aux collisions en pratique

Sources & références

Chaque outil du cluster correspond à une spécification primaire : Base64 à la RFC 4648, JWT à la RFC 7519, hachages à FIPS PUB 180-4, UUID à la RFC 9562, entropie des mots de passe au NIST SP 800-63B. L’API Web Crypto elle-même est une recommandation W3C. Voir le bloc Sources ci-dessous pour les URL canoniques.

Hypothèses & limites

• Exécution uniquement dans le navigateur. Les outils supposent un navigateur moderne avec Web Crypto. Les environnements anciens ou durcis (certains kiosques verrouillés, Node côté serveur sans shims) utiliseront un repli en JS et perdront la force cryptographique.
• Aucune vérification de signature.Le décodage JWT inspecte mais ne vérifie pas. N’utilisez pas cet outil dans un pipeline d’authentification.
• Pas de MD5. Cryptographiquement cassé pour un usage authentifié ; intentionnellement omis même pour les checksums. Utilisez SHA-256 avec un léger compromis de performance.
• Pas de streaming pour les grandes entrées.Les outils de hachage et Base64 chargent l’entrée complète en mémoire. Les entrées >100 Mo mettront l’onglet en pause pendant l’encodage.
• Aucune télémétrie sur les charges utiles.Nous ne consignons, stockons ni transmettons rien de ce qui est collé dans ces outils. Le compromis : nous ne pouvons pas non plus déboguer pourquoi une entrée spécifique s’affiche mal sans que l’utilisateur la reproduise.
• Les horodatages UUID v7 sont précis à la milliseconde. Générer >1000 UUID dans la même milliseconde repose sur l’aléatoire sub-ms de 10 bits pour l’unicité de l’ordre.
• La force du mot de passe est une heuristique.La difficulté d’attaque réelle dépend des patterns connus de l’attaquant (dictionnaire, ensembles de mots de passe divulgués), pas seulement de l’entropie.

Ce que nous ne faisons pas

• Chiffrer ou déchiffrer du contenu. L’API Web Crypto le supporte ; nous n’exposons pas d’interface car mal utiliser les API crypto est risqué.
• Vérifier les JWT. Voir ci-dessus.
• Formater structurellement — nous préservons le formatage de l’utilisateur autant que possible. Pour un formatage complet, utilisez un formateur dédié.
• Journaliser les charges utiles. Rien de ce que l’utilisateur colle ne quitte jamais le navigateur.