Skip to content

Chiffrement et déchiffrement SM4 en ligne

Le déchiffrement SM4 échoue ? L'outil trouve le mode, le padding, l'IV ou l'encodage fautif et propose la correction. Tout reste dans le navigateur, rien n'est envoyé. ECB, CBC, CTR, CFB, OFB ; PKCS#7, zéros ou aucun padding.

Sans pistage Fonctionne dans le navigateur Gratuit
Le chiffrement s'exécute entièrement dans votre navigateur — la clé et les données saisies ne quittent jamais cet appareil.
Texte chiffré
Commande OpenSSL équivalente 
—

Nécessite OpenSSL 3. La commande contient la clé que vous avez saisie.

Vecteurs de test SM4 de GB/T 32907-2016

Calculés lors de la génération du site par le moteur qu'exécute cette page — vérifiez votre propre implémentation SM4 avec ces valeurs.
Clé 0123456789abcdeffedcba9876543210
Texte en clair 0123456789abcdeffedcba9876543210
Texte chiffré, 1 chiffrement 681edf34d206965e86b3e94f536e4246
Texte chiffré, 1 000 000 chiffrements 595298c7c6fd271f0402f804c33d3f66
Le moteur SM4 est testé contre les deux vecteurs de l'annexe A de GB/T 32907-2016 et vérifié par recoupement avec OpenSSL 3 en ECB, CBC, CTR, CFB et OFB. Les valeurs par défaut des bibliothèques ont été vérifiées en exécutant OpenSSL, Node.js, sm-crypto, gm-crypt, gmssl et deux bibliothèques Go, et en lisant le code source de Hutool et de BouncyCastle. — Équipe Sécurité Go Tools · 11 sept. 2026

Rédigé et relu par des développeurs qui conçoivent des outils de cryptographie. Chaque texte chiffré et chaque nombre d'octets cités sur cette page sont calculés par le moteur de l'outil et vérifiés par des tests.

SM4 en bref

Longueur de clé SM4

16 octets Exactement 128 bits : 16 octets, écrits en 32 chiffres hexadécimaux ou 16 caractères ASCII. Il n'existe pas de clé SM4 de 192 ou 256 bits.

Vecteur de test GB/T 32907

681edf34d206965e86b3e94f536e4246 Avec la clé et le texte en clair 0123456789abcdeffedcba9876543210, un chiffrement donne 681edf34d206965e86b3e94f536e4246.

Taille de bloc et tours de SM4

32 tours Blocs de 16 octets (128 bits), chiffrés en 32 tours.

Un mauvais IV provoque-t-il toujours une erreur en CBC ?

16 premiers octets Non. Seuls les 16 premiers octets sont mal déchiffrés, et le padding du dernier bloc reste valide.

Qu'est-ce que SM4 ?

SM4 est le chiffrement par blocs des normes chinoises de cryptographie commerciale. Publié sous la référence GM/T 0002-2012, il est devenu la norme nationale GB/T 32907-2016 (en vigueur depuis le 1er mars 2017), puis a été ajouté à la norme internationale ISO/IEC 18033-3 par un amendement en 2021. C'est un chiffrement symétrique : la même clé de 128 bits chiffre et déchiffre, et il travaille sur des blocs de 128 bits, soit 16 octets à la fois — la même taille de bloc que l'AES.

À l'intérieur, chaque bloc est découpé en quatre mots de 32 bits et passe par 32 tours. À chaque tour, trois des mots sont combinés avec une clé de tour, le résultat traverse une S-box de 8 bits et une transformation linéaire, puis il est intégré au quatrième mot. Les 32 clés de tour sont dérivées de la clé à l'aide de deux jeux de constantes fixes, et le déchiffrement est le même calcul avec les clés de tour dans l'ordre inverse.

Le chiffrement par blocs seul ne traite que 16 octets exactement : les données réelles passent donc toujours par un mode opératoire. Cet outil propose les cinq modes classiques : ECB et CBC, qui travaillent sur des blocs entiers et nécessitent un padding, et CTR, CFB et OFB, qui transforment SM4 en chiffrement par flot sans aucun padding. La plupart des déchiffrements ratés n'ont rien à voir avec SM4 lui-même : ils viennent d'un désaccord entre les deux côtés sur le mode, le padding, l'IV, l'encodage du texte ou la conversion de la chaîne de clé en octets, et les bibliothèques ne s'accordent même pas sur ce que signifie « SM4 » tout court.

L'API Web Crypto intégrée aux navigateurs n'inclut pas SM4 : cette page embarque donc sa propre implémentation et l'exécute localement. Elle est testée contre les deux vecteurs de test de GB/T 32907 et vérifiée par recoupement avec OpenSSL 3 dans chaque mode.

// SM4-CBC with PKCS#7 padding using Node.js and its bundled OpenSSL 3.
// Key and IV are both exactly 16 bytes (32 hex digits).
const crypto = require('node:crypto');

const key = Buffer.from('0123456789abcdeffedcba9876543210', 'hex');
const iv = Buffer.from('fedcba98765432100123456789abcdef', 'hex');

const cipher = crypto.createCipheriv('sm4-cbc', key, iv);
const ciphertext = Buffer.concat([cipher.update('hello', 'utf8'), cipher.final()]);
console.log(ciphertext.toString('base64')); // fUQPRg2HAXHGz5ZslzCpSQ==

const decipher = crypto.createDecipheriv('sm4-cbc', key, iv);
const plaintext = Buffer.concat([decipher.update(ciphertext), decipher.final()]);
console.log(plaintext.toString('utf8')); // hello

Fonctionnalités de l'outil SM4

Trouve pourquoi le déchiffrement a échoué

Quand le déchiffrement échoue, la page réessaie l'encodage du texte chiffré, le format de clé, le mode, l'IV, le padding et l'encodage du texte, puis affiche les réglages qui produisent un texte lisible.

Préréglages pour les suspects habituels

Un clic applique les valeurs par défaut d'OpenSSL, Hutool, sm-crypto, gm-crypt ou tjfoc/gmsm — des bibliothèques qui ne s'accordent même pas sur le fait que « SM4 » tout court signifie ECB ou CBC.

Cinq modes, trois paddings, UTF-8 ou GBK

ECB, CBC, CTR, CFB et OFB avec PKCS#7, padding par zéros ou sans padding. Le texte en clair peut être en UTF-8 ou en GBK, l'encodage que produit le vieux code Java sous Windows chinois. GCM n'est pas pris en charge.

Clé et IV SM4 : aléatoires, ou en hex, texte ou Base64

Générez une clé ou un IV aléatoire de 16 octets en un clic, ou saisissez-le tel que votre code l'écrit. Un compteur d'octets en direct confirme que vous avez exactement 16 octets avant de chercher d'autres causes.

Vecteurs de test GB/T 32907 sur la page

Les deux résultats de l'annexe A sont affichés dans un tableau et se chargent en un clic : vous pouvez ainsi vérifier n'importe quelle implémentation SM4 par rapport à la norme.

Commande OpenSSL équivalente

Chaque résultat est accompagné de la commande openssl enc qui le reproduit, pour le confirmer dans un terminal ou le transmettre à un collègue.

Entièrement dans votre navigateur

Le moteur SM4 s'exécute localement. Les clés et les données ne quittent jamais la page, et l'outil continue de fonctionner hors ligne.

Valeurs par défaut de SM4 dans les bibliothèques courantes

OpenSSL 3 (openssl enc)

-sm4 = CBC

-sm4 est un alias de -sm4-cbc. -K et -iv prennent de l'hexadécimal, PKCS#7 reste actif sauf si vous passez -nopad, et la sortie est en octets bruts sauf si vous ajoutez -base64 -A. Un -K de mauvaise longueur est tronqué ou complété par des zéros avec un simple avertissement.

Java : Hutool SmUtil.sm4(key)

ECB · PKCS#7

Hutool transmet un SM4 nu, que BouncyCastle exécute en ECB avec PKCS#7 (JCE l'appelle PKCS5Padding). Les méthodes de chaîne utilisent UTF-8 et encryptHex renvoie de l'hexadécimal en minuscules. Pour CBC, utilisez new SM4(Mode.CBC, Padding.PKCS5Padding, key, iv).

Java : BouncyCastle Cipher.getInstance("SM4")

ECB · PKCS#7

Dans un mode qui exige un IV mais n'en reçoit pas, le chiffrement génère en silence un IV aléatoire et le déchiffrement lève no IV set when one expected — un texte chiffré produit sans conserver cet IV ne peut donc être déchiffré nulle part.

JavaScript : sm-crypto

ECB · clé hex

sm4.encrypt(data, key) utilise par défaut ECB avec PKCS#7, attend la clé sous forme de chaîne hexadécimale de 32 chiffres et renvoie de l'hexadécimal en minuscules. Seul mode: 'cbc' change le mode ; toute autre valeur reste en ECB sans le signaler. sm-crypto-v2 se comporte de la même façon, mais utilise un IV entièrement nul quand CBC ne reçoit pas d'iv.

JavaScript : gm-crypt

CBC · clé texte · Base64

Utilise CBC par défaut, prend la clé et l'IV sous forme de chaînes UTF-8 de 16 caractères et renvoie du Base64. Une clé dont les octets ne forment pas de l'UTF-8 valide ne peut tout simplement pas lui être passée.

Python : gmssl CryptSM4

PKCS#7 · clé tronquée à 16 octets

Vous choisissez le mode en appelant crypt_ecb ou crypt_cbc. set_key ne lit que les 16 premiers octets : une clé plus longue est tronquée en silence, et une mauvaise clé renvoie généralement des octets vides au lieu d'une erreur.

Go : tjfoc/gmsm sm4

IV nul par défaut

Sm4Cbc utilise un IV global au package qui reste entièrement nul tant que SetIV n'est pas appelé, applique un padding PKCS#7 même en CFB et OFB, et ignore les erreurs de retrait du padding — une mauvaise clé renvoie nil sans erreur.

Exemples de chiffrement et de déchiffrement SM4

Vecteur de test GB/T 32907 (ECB, sans padding)

Clé 0123456789abcdeffedcba9876543210, texte en clair (hex) 0123456789abcdeffedcba9876543210
681edf34d206965e86b3e94f536e4246

C'est l'exemple 1 de l'annexe A de la norme GB/T 32907-2016 : la clé et le texte en clair ont la même valeur de 128 bits, et un seul chiffrement donne 681edf34d206965e86b3e94f536e4246. En rechiffrant ce résultat, un million de fois au total, on obtient 595298c7c6fd271f0402f804c33d3f66. Les deux valeurs figurent dans le tableau des vecteurs de test de cette page, calculées par le moteur que vous utilisez. Le bouton Vecteur de test GB/T 32907 charge la première.

CBC avec PKCS#7 : texte en entrée, Base64 en sortie

Clé 0123456789abcdeffedcba9876543210, IV fedcba98765432100123456789abcdef, texte en clair : SM4 interop test: order 20260911-0042
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y

Le texte en clair fait 37 octets en UTF-8. PKCS#7 le complète à 48 octets, soit trois blocs de 16 octets, que Base64 écrit en 64 caractères. Le bouton Charger l'exemple remplit exactement ces valeurs, et le panneau OpenSSL affiche une commande qui reproduit la même chaîne Base64 dans un terminal.

Mauvais IV en CBC : seuls les 16 premiers octets sont faux

Le texte chiffré ci-dessus, déchiffré avec l'IV 00000000000000000000000000000000
16 octets illisibles, puis ": order 20260911-0042"

CBC ne mélange l'IV qu'au premier bloc, et le padding PKCS#7 se trouve dans le dernier : la vérification du padding réussit donc quand même, et OpenSSL ne signale aucune erreur. Cette page repère le premier bloc illisible et vous indique que la clé et le mode sont bons et que le problème vient de l'IV — ou que les 16 premiers octets du texte chiffré sont eux-mêmes l'IV.

Comment utiliser l'outil de chiffrement et de déchiffrement SM4

  1. 1

    Choisissez un préréglage de bibliothèque, ou le mode et le padding

    Si vous connaissez la bibliothèque de l'autre côté, choisissez-la dans Reprendre les valeurs par défaut de. Sinon, sélectionnez Chiffrer ou Déchiffrer et alignez le mode et le padding. Les modes de flot (CTR, CFB, OFB) n'ont pas de padding : le sélecteur de padding est donc désactivé pour eux.

  2. 2

    Saisissez la clé et l'IV

    Les deux font exactement 16 octets. Choisissez le format dans lequel la chaîne est écrite — hex, texte ou Base64 — et vérifiez que le compteur d'octets passe au vert. Les boutons Aléatoire génèrent de nouvelles valeurs.

  3. 3

    Collez l'entrée

    Pour chiffrer, tapez du texte (UTF-8 ou GBK) ou collez des octets en hexadécimal. Pour déchiffrer, collez le texte chiffré et indiquez s'il est en Base64 ou en hex. Le résultat se met à jour pendant la saisie.

  4. 4

    Copiez le résultat ou vérifiez l'aller-retour

    Copiez la sortie, ou cliquez sur Déchiffrer ce texte chiffré pour l'envoyer dans l'onglet de déchiffrement avec la même clé et le même IV. Le panneau OpenSSL affiche une commande qui reproduit le résultat.

  5. 5

    Si le déchiffrement échoue, lisez le diagnostic

    Le diagnostic liste les réglages avec lesquels vos entrées se déchiffrent en texte lisible. Appliquez-en un d'un clic, ou lisez la note si seuls les 16 premiers octets échouent — c'est le signe d'un problème d'IV.

Pourquoi le déchiffrement SM4 échoue

Lire une clé hexadécimale comme du texte

Une chaîne hexadécimale de 32 caractères ne fait 16 octets que si elle est décodée en hexadécimal. Lue comme du texte, elle fait 32 octets, ce que SM4 refuse — ou, dans du code qui tronque ou complète les clés en silence, elle devient une tout autre clé.

✗ Incorrect 
Clé (texte) : 0123456789abcdeffedcba9876543210  -> 32 octets, refusée
✓ Correct 
Clé (hex) :   0123456789abcdeffedcba9876543210  -> 16 octets

Déchiffrer en ECB un texte chiffré en CBC

Les deux côtés doivent utiliser le même mode. Un texte chiffré en CBC puis déchiffré en ECB donne des données illisibles dans chaque bloc, et échoue généralement à la vérification du padding à la fin.

✗ Incorrect 
chiffrement :   SM4/CBC/PKCS5Padding
déchiffrement : SM4/ECB/PKCS5Padding  -> bad decrypt
✓ Correct 
chiffrement :   SM4/CBC/PKCS5Padding
déchiffrement : SM4/CBC/PKCS5Padding, même IV

Utiliser un autre IV

En CBC, un mauvais IV ne déclenche aucune erreur : les 16 premiers octets sortent brouillés et le reste se déchiffre normalement. Si seul le début de votre texte en clair est cassé, comparez les IV.

✗ Incorrect 
IV de déchiffrement 00000000000000000000000000000000
-> 16 octets illisibles + ": order 20260911-0042"
✓ Correct 
IV de déchiffrement fedcba98765432100123456789abcdef
-> "SM4 interop test: order 20260911-0042"

Traiter un texte chiffré en Base64 comme de l'hexadécimal

Base64 et l'hexadécimal sont deux façons d'écrire les mêmes octets. Lire l'un comme l'autre fournit au chiffrement une entrée erronée dès le départ.

✗ Incorrect 
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  lu comme hex -> invalide
✓ Correct 
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  lu comme Base64 -> 48 octets

Le padding par zéros supprime de vrais zéros finaux

Le padding par zéros ne distingue pas le padding des données : un texte en clair qui se termine réellement par 0x00 perd ces octets. Utilisez PKCS#7 pour tout ce qui n'est pas du texte brut.

✗ Incorrect 
padding zéros : 61 62 00  -> déchiffré en 61 62
✓ Correct 
PKCS#7 :        61 62 00  -> déchiffré en 61 62 00

Croire que « SM4 » désigne partout le même mode

OpenSSL traite sm4 comme CBC. BouncyCastle — et donc SmUtil.sm4(key) de Hutool — traite SM4 comme ECB avec PKCS#7. Deux systèmes qui « utilisent simplement SM4 » peuvent ne pas être d'accord sur le mode.

✗ Incorrect 
Java:    Cipher.getInstance("SM4")  -> ECB + PKCS#7
OpenSSL: openssl enc -sm4           -> CBC
✓ Correct 
Java:    Cipher.getInstance("SM4/CBC/PKCS5Padding")
OpenSSL: openssl enc -sm4-cbc

Chiffrer des octets GBK d'un côté et UTF-8 de l'autre

En Java, getBytes() sans jeu de caractères utilise l'encodage par défaut de la plateforme, c'est-à-dire GBK sur un JDK 17 ou antérieur sous Windows chinois. Le même texte chinois donne alors un texte chiffré différent, et l'autre côté le déchiffre en mojibake.

✗ Incorrect 
"国密SM4 test".getBytes()  // GBK sur un JDK <= 17 sous Windows chinois
-> texte chiffré ECB 3188d06cf28db70092f8753cbd5ee518
✓ Correct 
"国密SM4 test".getBytes(StandardCharsets.UTF_8)
-> texte chiffré ECB d830308b0ae4fa7b9a2b5d59f7f65ca5

Quand chiffrer ou déchiffrer en SM4 en ligne

Aligner la sortie SM4 entre backend et frontend
Votre service Java et votre client web produisent des textes chiffrés différents pour le même texte. Reproduisez ici chaque côté avec le préréglage de sa bibliothèque et voyez quel paramètre diffère.
Déboguer un déchiffrement raté venant d'un système partenaire
Un partenaire envoie un texte chiffré SM4 qui refuse de se déchiffrer. Collez-le avec la clé et l'IV convenus et laissez le diagnostic trouver le mode, le padding ou l'encodage réellement utilisés.
Vérifier une implémentation SM4
Passez votre code sur les vecteurs GB/T 32907 de cette page, puis comparez un aller-retour CBC, avant que l'implémentation n'approche la moindre donnée de production.
Préparer des données de test pour une migration vers SM4
Quand un système passe de l'AES à SM4, générez ici des triplets clé, IV et texte chiffré connus, à utiliser comme fixtures dans les nouveaux tests.
Observer le comportement des modes de chiffrement par blocs
Chiffrez deux blocs identiques en ECB et en CBC, ou déchiffrez avec un mauvais IV, et observez ce qui change dans le texte chiffré et dans la sortie.

Fonctionnement de SM4 et de ses modes

Taille de bloc, taille de clé et tours
SM4 chiffre des blocs de 128 bits avec une clé de 128 bits en 32 tours. Chaque tour applique une S-box de 8 bits à un mot de 32 bits, puis une transformation linéaire qui combine par XOR le mot avec quatre rotations de lui-même. Le déchiffrement exécute les mêmes 32 tours avec les clés de tour dans l'ordre inverse.
ECB : chaque bloc isolément
ECB chiffre chaque bloc de 16 octets indépendamment. Il n'a pas besoin d'IV, mais des blocs de texte en clair identiques donnent des blocs chiffrés identiques : les motifs des données restent visibles. Il nécessite un padding, sauf si l'entrée est un multiple de 16 octets.
CBC : blocs chaînés et IV
CBC combine par XOR chaque bloc de texte en clair avec le bloc chiffré précédent avant de le chiffrer, et utilise l'IV pour le premier bloc. Comme l'IV n'intervient que dans le premier bloc, un mauvais IV corrompt exactement les 16 premiers octets du texte en clair et laisse intact le padding du dernier bloc : il n'y a donc souvent aucune erreur.
CTR, CFB et OFB : SM4 en chiffrement par flot
Ces modes chiffrent un compteur ou une valeur de rétroaction et combinent le résultat par XOR avec les données : le texte chiffré a la même longueur que le texte en clair, et il n'y a pas de padding. En CTR, l'IV de 16 octets est incrémenté en entier comme un seul compteur big-endian de 128 bits, comme dans OpenSSL. Un mauvais IV brouille tout le message en CTR et OFB, mais seulement le premier bloc en CFB.
Règles de padding
PKCS#7 ajoute de 1 à 16 octets de valeur n : un message qui compte déjà un nombre entier de blocs reçoit donc quand même un bloc complet de padding. Le padding par zéros n'ajoute des octets 0x00 que si nécessaire et retire tous les zéros finaux au déchiffrement. Sans padding, les données restent telles quelles et une entrée qui ne remplit pas des blocs entiers est refusée.

Bonnes pratiques de chiffrement SM4

Ne choisissez pas ECB pour une nouvelle conception
ECB révèle quels blocs sont identiques. Utilisez CBC ou CTR, sauf pour vous aligner sur un système existant qui utilise déjà ECB.
Utilisez un nouvel IV aléatoire pour chaque message
L'IV n'est pas secret, mais il ne doit pas se répéter avec la même clé. Générez-le aléatoirement pour chaque message, puis stockez-le ou envoyez-le avec le texte chiffré.
Authentifiez le texte chiffré
GB/T 17964-2021, la norme chinoise sur les modes de chiffrement par blocs, précise que les modes qu'elle décrit protègent la confidentialité, pas l'intégrité. En CBC, modifier un seul octet de l'IV transforme pay=100.00 en pay=900.00, et le déchiffrement réussit quand même. Calculez un MAC sur l'IV et le texte chiffré et vérifiez-le avant de déchiffrer, par exemple avec le générateur HMAC.
Écrivez chaque paramètre dans la spécification d'interface
« Chiffré en SM4 » n'est pas une spécification. Notez le mode, le padding, l'encodage de la clé et de l'IV, le jeu de caractères du texte en clair et le format du texte chiffré, hex ou Base64.
Tenez les vraies clés à l'écart des pages web et du code source
Utilisez cette page avec des clés de test. Les clés de production ont leur place dans un système de gestion de clés ou un module matériel de sécurité (HSM), chargées à l'exécution plutôt que collées dans une page ou versionnées dans un dépôt.

FAQ sur le chiffrement SM4

Pourquoi mon déchiffrement SM4 échoue-t-il avec une erreur de padding ou un texte illisible ?
Le déchiffrement ne fonctionne que si tout correspond au côté qui a chiffré : les octets de la clé, le mode, l'IV, le padding, et la façon dont le texte chiffré a été écrit (hex ou Base64). L'erreur obtenue — « bad decrypt », une exception de padding ou un écran de caractères illisibles — ne dit pas lequel est en cause, et certaines bibliothèques renvoient une sortie vide au lieu d'une erreur. Collez quand même ici le texte chiffré, la clé et l'IV. Quand le déchiffrement échoue, la page essaie toutes les combinaisons d'encodage du texte chiffré, de format de clé, de mode, d'IV et de padding — y compris les clés qu'une bibliothèque a tronquées en silence à 16 octets et le texte en clair encodé en GBK — et liste les lectures qui donnent un texte lisible, en signalant celles dont le padding PKCS#7 est valide. Si seuls les 16 premiers octets sont faux, la clé et le mode sont bons, mais pas l'IV.
Quelle est la longueur d'une clé SM4, et peut-elle faire 256 bits ?
Une clé SM4 fait exactement 128 bits, soit 16 octets — la même taille que le bloc. GB/T 32907 ne définit que cette longueur de clé : il n'existe pas de SM4 à 192 ou 256 bits. Si quelqu'un vous réclame une clé SM4 de 256 bits, vérifiez si une chaîne hexadécimale de 32 chiffres n'a pas été comptée comme 32 caractères de 8 bits chacun. Seize octets s'écrivent en 32 chiffres hexadécimaux ou en 16 caractères ASCII, et confondre les deux est l'erreur de clé la plus courante : 0123456789abcdeffedcba9876543210 lu en hexadécimal fait 16 octets, mais la même chaîne lue comme du texte fait 32 octets et est refusée. Le sélecteur de format et le compteur d'octets à côté du champ de clé sont là précisément pour détecter cette confusion.
Qu'est-ce que l'IV SM4, et quelle doit être sa longueur ?
L'IV (vecteur d'initialisation) est une valeur de 16 octets mélangée au premier bloc en CBC, CTR, CFB et OFB ; ECB n'en utilise pas. Il doit faire exactement 16 octets (32 chiffres hexadécimaux ou 16 caractères ASCII) : si vous obtenez une erreur de longueur d'IV, vérifiez si une chaîne hexadécimale de 32 chiffres n'a pas été lue comme 32 octets de texte. L'IV n'est pas secret, mais il ne doit pas se répéter avec la même clé : générez-le aléatoirement et envoyez-le avec le texte chiffré, souvent placé devant. En CBC, un mauvais IV ne déclenche généralement aucune erreur et ne brouille que les 16 premiers octets. Certaines bibliothèques utilisent en silence un IV entièrement nul quand aucun n'est fourni (sm-crypto-v2, tjfoc/gmsm en Go), tandis que BouncyCastle, côté Java, en génère un aléatoire — si cet IV n'est pas conservé avec le texte chiffré, personne ne pourra le déchiffrer.
Quelle est la différence entre SM4 ECB et CBC, et lequel utiliser ?
Utilisez CBC (ou CTR) avec un nouvel IV aléatoire pour chaque message. ECB chiffre des blocs de 16 octets identiques en blocs chiffrés identiques, si bien que la structure répétée des données transparaît dans le texte chiffré. Ne choisissez ECB que pour dialoguer avec un système qui l'utilise déjà. Notez qu'aucun de ces deux modes ne détecte les altérations : si c'est important, envoyez aussi un MAC calculé sur l'IV et le texte chiffré, par exemple avec le générateur HMAC.
Quel padding SM4 utiliser : PKCS5Padding, PKCS#7, padding par zéros ou aucun padding ?
PKCS#7 ajoute toujours de 1 à 16 octets, chacun contenant le nombre d'octets ajoutés, ce qui permet au destinataire de le retirer sans ambiguïté. Pour un chiffrement par blocs de 16 octets comme SM4, le PKCS5Padding de Java est exactement le même padding — BouncyCastle fait passer les deux noms par le même code. Le padding par zéros ajoute des 0x00 uniquement jusqu'à la prochaine frontière de bloc. Au déchiffrement, Hutool et BouncyCastle retirent tous les 0x00 finaux, y compris les octets nuls qui faisaient réellement partie des données, alors que gmssl en Python n'en retire qu'un. Sans padding, l'entrée doit compter un nombre entier de blocs de 16 octets. CTR, CFB et OFB sont des modes de flot et n'utilisent jamais de padding. Si le texte déchiffré se termine par des espaces, des carrés ou des sauts de ligne parasites, le padding n'a pas été retiré : des données PKCS#7 déchiffrées sans padding gardent à la fin n octets de valeur n (0x09, 0x0A et 0x0D s'affichent comme des tabulations et des sauts de ligne) ; passez la sortie en Hex et examinez le dernier bloc.
Quelle est la longueur d'un texte chiffré SM4, et peut-on en déduire le mode ?
Comptez en octets. Avec PKCS#7 en ECB ou CBC, le texte en clair est arrondi au multiple de 16 supérieur, et un message qui est déjà un multiple de 16 reçoit un bloc complet de plus — 5 ou 15 octets deviennent 16, et 16 octets deviennent 32. Le padding par zéros complète seulement jusqu'au multiple de 16 suivant, l'absence de padding conserve la longueur, et en CTR, CFB et OFB le texte chiffré a exactement la longueur du texte en clair. L'hexadécimal double le nombre d'octets ; Base64 utilise 4 × ⌈octets / 3⌉ caractères, donc 16 octets donnent 24 caractères, 32 en donnent 44 et 64 en donnent 88. Ajoutez 16 octets si l'IV est placé devant. Le texte chiffré seul ne révèle pas le mode, mais deux indices aident : une longueur qui n'est pas un multiple de 16 exclut quasiment ECB ou CBC avec padding, et deux blocs de 16 octets identiques orientent vers ECB. En cas de doute, collez-le dans l'onglet de déchiffrement : le diagnostic automatique essaie les modes pour vous.
SM4 donne-t-il toujours le même texte chiffré, et pourquoi celui d'un autre outil est-il différent ?
ECB — ou tout mode avec un IV fixe — donne toujours le même texte chiffré pour la même clé et le même texte en clair ; avec un nouvel IV aléatoire à chaque exécution, la sortie change à chaque fois, comme il se doit. Au-delà, comparez le mode, le padding, la lecture de la clé en hexadécimal ou en texte, l'encodage du texte en clair — UTF-8 dans la plupart des programmes, mais GBK quand du vieux code Java appelle getBytes() sur un Windows chinois — et la façon dont le résultat est affiché : Base64, hexadécimal en minuscules ou en majuscules. Avec des réglages identiques et un IV fixe, deux implémentations correctes produisent une sortie identique. Si vous soupçonnez l'un des outils, vérifiez d'abord les deux avec le vecteur de test GB/T 32907.
Comment vérifier que ma propre implémentation SM4 est correcte ?
Commencez par les deux vecteurs de l'annexe A de GB/T 32907-2016. Avec une clé et un texte en clair valant tous deux 0123456789abcdeffedcba9876543210, un chiffrement doit donner 681edf34d206965e86b3e94f536e4246 et un million de chiffrements enchaînés 595298c7c6fd271f0402f804c33d3f66. Ces vecteurs ne testent que le chiffrement par blocs : chiffrez ensuite du texte en CBC avec une clé et un IV fixes, et comparez avec cette page ou avec la commande OpenSSL qu'elle affiche. Le moteur de cette page est testé contre les deux vecteurs et contre OpenSSL 3 dans les cinq modes.
OpenSSL peut-il chiffrer et déchiffrer en SM4 ?
Oui. OpenSSL 3 inclut SM4 en ECB, CBC, CFB, OFB et CTR. Utilisez openssl enc -sm4-cbc -K <32 hex digits> -iv <32 hex digits> : -K prend la clé brute en hexadécimal, donc aucun mot de passe n'intervient, -nopad désactive PKCS#7, et -base64 -A lit ou écrit du Base64 sur une seule ligne. Attention à deux pièges : -sm4 tout court signifie CBC, et une valeur -K de mauvaise longueur est tronquée ou complétée par des zéros avec un simple avertissement. Le panneau OpenSSL de cette page construit la commande à partir de vos réglages actuels ; openssl enc n'a pas de padding par zéros, donc le panneau le signale au lieu d'afficher une commande qui ne correspondrait pas.
Comment déchiffrer un texte chiffré SM4 venant de Java (Hutool) ou de JavaScript (sm-crypto) ?
Commencez par déterminer le mode et le padding qu'utilise vraiment l'autre côté — souvent, le code ne le dit nulle part. SmUtil.sm4(key) de Hutool ne transmet que le nom SM4, et BouncyCastle complète avec ECB avec PKCS#7 (le PKCS5Padding de Java) ; seule une chaîne complète comme SM4/CBC/PKCS5Padding signifie CBC. En JavaScript, sm-crypto utilise lui aussi ECB par défaut, attend la clé sous forme de chaîne hexadécimale de 32 chiffres et renvoie de l'hexadécimal en minuscules, tandis que gm-crypt utilise CBC par défaut, attend une clé texte de 16 caractères et renvoie du Base64. Vérifiez ensuite le jeu de caractères du texte en clair : les méthodes de chaîne de Hutool utilisent toujours UTF-8, mais un getBytes() sans argument sur un JDK 17 ou antérieur sous Windows chinois peut signifier GBK, ce qui change le texte chiffré. Choisissez la bibliothèque dans Reprendre les valeurs par défaut de pour tout régler en un clic, ou saisissez les réglages vous-même ; si l'un d'eux est incertain, collez quand même le texte chiffré, et le diagnostic automatique essaie les combinaisons de mode, de padding, d'IV et d'encodage.
SM4 est-il sûr, et mes données sont-elles envoyées ?
En tant qu'algorithme, SM4 utilise une clé de 128 bits et 32 tours ; la RFC 8998 (2021) indique qu'au moment de sa rédaction, aucune clé faible ni aucun problème de sécurité n'était connu pour SM4. Les risques pratiques viennent de la façon dont on l'utilise : ECB laisse fuiter des motifs et CBC ne détecte pas les altérations. Quant à cette page, rien n'est envoyé. Les navigateurs n'intègrent pas SM4 : cette page embarque donc sa propre implémentation et l'exécute localement ; vous pouvez ouvrir l'onglet Réseau et constater qu'aucune requête ne part, ou vous déconnecter et continuer à utiliser l'outil. Cela convient très bien pour des données de test, le débogage et l'apprentissage. Cela ne fait pas pour autant d'une page web le bon endroit pour des clés de production : leur place est dans un système de gestion de clés ou un module matériel, pas dans une zone de texte d'un site web, quel qu'il soit.
Quelle est la différence entre SM4 et AES ?
Ce sont deux chiffrements par blocs de 128 bits, et les modes et le padding fonctionnent de la même façon pour les deux — c'est pourquoi les bugs d'interopérabilité SM4 ressemblent trait pour trait à ceux de l'AES. SM4 effectue 32 tours et n'a qu'une seule taille de clé, 128 bits ; l'AES-128 effectue 10 tours, et l'AES accepte aussi des clés de 192 et 256 bits. SM4 est la norme nationale chinoise GB/T 32907-2016 et fait partie, depuis 2021, de la norme internationale ISO/IEC 18033-3 aux côtés de l'AES ; on l'utilise là où la cryptographie commerciale chinoise est exigée. L'AES est la norme FIPS 197 du NIST. Pour l'AES, utilisez l'outil de chiffrement AES.

Outils connexes

Voir tous les outils →

Outil de déchiffrement AES — compatible OpenSSL et CryptoJS

Outils de sécurité

Déchiffrez de l'AES en ligne — GCM/CBC/CTR, phrase secrète ou clé brute, détection automatique du format OpenSSL et CryptoJS « U2FsdGVkX1 ». 100 % dans le navigateur, les clés ne quittent jamais la page.

Outil de chiffrement AES — GCM, CBC et CTR

Outils de sécurité

Chiffrement AES en ligne gratuit — AES-128/192/256, GCM/CBC/CTR, phrase secrète (PBKDF2) ou clé brute. 100 % dans votre navigateur ; rien n'est envoyé.

Générateur et vérificateur de hachage Bcrypt

Outils de sécurité

Générez et vérifiez des hachages bcrypt en ligne — coût ajustable, préfixes $2b$/$2a$/$2y$. 100 % dans votre navigateur ; mot de passe jamais envoyé.

Calculateur de somme de contrôle CRC

Outils de sécurité

Collez du texte ou de l'hexadécimal : les 63 variantes CRC-8, CRC-16 et CRC-32 d'un coup. Somme de contrôle impossible à reproduire ? Saisissez-la, l'outil nomme la variante : MODBUS, CCITT-FALSE, XMODEM. Tout reste local.

Générateur HMAC & vérificateur de signature

Outils de sécurité

Générateur et vérificateur HMAC en ligne gratuit. Calculez HMAC-SHA256/SHA1/SHA384/SHA512 avec des clés en texte, hex ou Base64 et une sortie Hex/Base64/Base64URL. 100 % dans votre navigateur — les clés ne quittent jamais la page.

Décodeur JWT

Outils de sécurité

Décodez des jetons JWT en ligne avec notre décodeur JWT gratuit. Inspectez en-tête, charge utile, signature, expiration et revendications. 100 % navigateur — votre jeton ne quitte jamais votre appareil. Sans inscription ni suivi.