Skip to content

SM4 online ver- und entschlüsseln

SM4 online ver- und entschlüsseln. Scheitert das Entschlüsseln, findet das Tool den Fehler — Modus, Padding, IV oder Kodierung — samt Lösung. Läuft im Browser, kein Upload. ECB, CBC, CTR, CFB, OFB; PKCS#7, Zero oder kein Padding.

Kein Tracking Läuft im Browser Kostenlos
Die Verschlüsselung läuft vollständig in Ihrem Browser — eingegebene Schlüssel und Daten verlassen dieses Gerät nie.
Chiffretext
Entsprechender OpenSSL-Befehl

Erfordert OpenSSL 3. Der Befehl enthält den eingegebenen Schlüssel.

SM4-Testvektoren aus GB/T 32907-2016

Beim Build von derselben Engine berechnet, die auf dieser Seite läuft — prüfen Sie Ihre eigene SM4-Implementierung dagegen.
Schlüssel 0123456789abcdeffedcba9876543210
Klartext 0123456789abcdeffedcba9876543210
Chiffretext, 1 Verschlüsselung 681edf34d206965e86b3e94f536e4246
Chiffretext, 1.000.000 Verschlüsselungen 595298c7c6fd271f0402f804c33d3f66
Die SM4-Engine ist gegen beide Vektoren aus Anhang A von GB/T 32907-2016 getestet und in ECB, CBC, CTR, CFB und OFB mit OpenSSL 3 abgeglichen. Die Standardwerte der Bibliotheken wurden überprüft, indem OpenSSL, Node.js, sm-crypto, gm-crypt, gmssl und zwei Go-Bibliotheken ausgeführt und der Quellcode von Hutool und BouncyCastle gelesen wurde. — Go Tools Security Team · Sep 11, 2026

Geschrieben und geprüft von Entwicklerinnen und Entwicklern, die Kryptografie-Tools bauen. Jeder Chiffretext und jede Byteanzahl auf dieser Seite wird von der Engine des Tools berechnet und durch Tests überprüft.

Schnellantworten zu SM4

SM4-Schlüssellänge

16 Byte Genau 128 Bit: 16 Byte, geschrieben als 32 Hex-Ziffern oder 16 ASCII-Zeichen. SM4-Schlüssel mit 192 oder 256 Bit gibt es nicht.

Testvektor GB/T 32907

681edf34d206965e86b3e94f536e4246 Mit Schlüssel und Klartext 0123456789abcdeffedcba9876543210 ergibt eine Verschlüsselung 681edf34d206965e86b3e94f536e4246.

SM4-Blockgröße und Runden

32 Runden Blöcke mit 16 Byte (128 Bit), verschlüsselt in 32 Runden.

Führt ein falscher IV bei CBC immer zu einem Fehler?

ersten 16 Byte Nein. Nur die ersten 16 Byte werden falsch entschlüsselt, und das Padding im letzten Block ist weiterhin gültig.

Was ist SM4?

SM4 ist die Blockchiffre der chinesischen Standards für kommerzielle Kryptografie. Sie wurde als GM/T 0002-2012 herausgegeben, wurde zum nationalen Standard GB/T 32907-2016 (in Kraft seit dem 1. März 2017) und 2021 per Änderung in den internationalen Standard ISO/IEC 18033-3 aufgenommen. Es handelt sich um eine symmetrische Chiffre: Derselbe 128-Bit-Schlüssel ver- und entschlüsselt, und sie arbeitet auf 128-Bit-Blöcken, also 16 Byte auf einmal — dieselbe Blockgröße wie bei AES.

Intern wird jeder Block in vier 32-Bit-Wörter aufgeteilt und durch 32 Runden geschickt. Jede Runde verknüpft drei der Wörter mit einem Rundenschlüssel, schickt das Ergebnis durch eine 8-Bit-S-Box und eine lineare Transformation und faltet es in das vierte Wort ein. Die 32 Rundenschlüssel werden mit zwei festen Konstantensätzen aus dem Schlüssel abgeleitet, und die Entschlüsselung ist dieselbe Berechnung mit den Rundenschlüsseln in umgekehrter Reihenfolge.

Die Blockchiffre allein verarbeitet nur exakt 16 Byte, deshalb laufen echte Daten immer durch einen Betriebsmodus. Dieses Tool bietet die fünf klassischen an: ECB und CBC, die auf ganzen Blöcken arbeiten und Padding brauchen, sowie CTR, CFB und OFB, die SM4 in eine Stromchiffre ganz ohne Padding verwandeln. Die meisten gescheiterten Entschlüsselungen haben mit SM4 selbst nichts zu tun — sie entstehen, weil sich beide Seiten bei Modus, Padding, IV, Textkodierung oder der Umwandlung des Schlüsselstrings in Bytes nicht einig sind, und die Bibliotheken sind sich nicht einmal einig, was ein bloßes „SM4“ bedeutet.

Die im Browser eingebaute Web Crypto API enthält kein SM4, deshalb bringt diese Seite ihre eigene Implementierung mit und führt sie lokal aus. Sie ist gegen die beiden Testvektoren aus GB/T 32907 getestet und in jedem Modus mit OpenSSL 3 abgeglichen.

// 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

Funktionen des Tools für SM4

Sagt Ihnen, warum die Entschlüsselung scheitert

Scheitert die Entschlüsselung, probiert die Seite Chiffretext-Kodierung, Schlüsselformat, Modus, IV, Padding und Textkodierung durch und zeigt die Einstellungen, die lesbaren Text ergeben.

Bibliotheks-Voreinstellungen für die üblichen Verdächtigen

Ein Klick übernimmt die Standardwerte von OpenSSL, Hutool, sm-crypto, gm-crypt oder tjfoc/gmsm — Bibliotheken, die sich nicht einmal einig sind, ob ein bloßes „SM4“ ECB oder CBC bedeutet.

Fünf Modi, drei Padding-Varianten, UTF-8 oder GBK

ECB, CBC, CTR, CFB und OFB mit PKCS#7, Zero-Padding oder ohne Padding. Der Klartext kann UTF-8 oder GBK sein — die Kodierung, die älterer Java-Code unter chinesischem Windows erzeugt. GCM wird nicht unterstützt.

SM4-Schlüssel und IV: zufällig oder als Hex, Text oder Base64

Erzeugen Sie per Klick einen zufälligen 16-Byte-Schlüssel oder -IV, oder geben Sie ihn so ein, wie Ihr Code ihn schreibt. Ein Live-Byte-Zähler bestätigt genau 16 Byte, bevor Sie anderen Ursachen nachjagen.

Testvektoren aus GB/T 32907 direkt auf der Seite

Beide Ergebnisse aus Anhang A stehen in einer Tabelle und lassen sich per Klick laden, sodass Sie jede SM4-Implementierung gegen den Standard prüfen können.

Entsprechender OpenSSL-Befehl

Zu jedem Ergebnis gibt es den openssl enc-Befehl, der es reproduziert — zum Bestätigen im Terminal oder zum Weitergeben an Kollegen.

Läuft vollständig im Browser

Die SM4-Engine läuft lokal. Schlüssel und Daten verlassen die Seite nie, und das Tool funktioniert auch offline.

Standardwerte für SM4 in gängigen Bibliotheken

OpenSSL 3 (openssl enc)

-sm4 = CBC

-sm4 ist ein Alias für -sm4-cbc. -K und -iv erwarten Hex, PKCS#7 bleibt aktiv, solange Sie nicht -nopad angeben, und die Ausgabe besteht aus rohen Bytes, sofern Sie nicht -base64 -A hinzufügen. Ein -K mit falscher Länge wird nur mit einer Warnung gekürzt oder mit Nullen aufgefüllt.

Java: Hutool SmUtil.sm4(key)

ECB · PKCS#7

Hutool übergibt ein bloßes SM4, das BouncyCastle als ECB mit PKCS#7 ausführt (JCE nennt es PKCS5Padding). Die String-Methoden verwenden UTF-8, und encryptHex gibt Hex in Kleinbuchstaben aus. Für CBC verwenden Sie new SM4(Mode.CBC, Padding.PKCS5Padding, key, iv).

Java: BouncyCastle Cipher.getInstance("SM4")

ECB · PKCS#7

In einem Modus, der einen IV braucht, aber keinen bekommt, erzeugt die Verschlüsselung stillschweigend einen zufälligen IV, und die Entschlüsselung wirft no IV set when one expected — Chiffretext, bei dem dieser IV nicht gespeichert wurde, lässt sich deshalb nirgends mehr entschlüsseln.

JavaScript: sm-crypto

ECB · Hex-Schlüssel

sm4.encrypt(data, key) verwendet standardmäßig ECB mit PKCS#7, erwartet den Schlüssel als 32-stelligen Hex-String und gibt Hex in Kleinbuchstaben zurück. Nur mode: 'cbc' ändert den Modus; jeder andere Wert bleibt stillschweigend bei ECB. sm-crypto-v2 verhält sich genauso, verwendet bei CBC ohne iv aber einen Null-IV.

JavaScript: gm-crypt

CBC · Textschlüssel · Base64

Verwendet standardmäßig CBC, erwartet Schlüssel und IV als UTF-8-Strings mit 16 Zeichen und gibt Base64 zurück. Ein Schlüssel, dessen Bytes kein gültiges UTF-8 sind, lässt sich gar nicht erst übergeben.

Python: gmssl CryptSM4

PKCS#7 · Schlüssel auf 16 Byte gekürzt

Den Modus wählen Sie, indem Sie crypt_ecb oder crypt_cbc aufrufen. set_key liest nur die ersten 16 Byte, ein längerer Schlüssel wird also stillschweigend gekürzt, und ein falscher Schlüssel liefert meist leere Bytes statt eines Fehlers.

Go: tjfoc/gmsm sm4

standardmäßig Null-IV

Sm4Cbc verwendet einen IV auf Paketebene, der aus lauter Nullen besteht, bis SetIV aufgerufen wird, füllt selbst in CFB und OFB mit PKCS#7 auf und verwirft Fehler beim Entfernen des Paddings — ein falscher Schlüssel liefert nil ohne Fehler.

Beispiele zum Ver- und Entschlüsseln mit SM4

Testvektor aus GB/T 32907 (ECB, kein Padding)

Schlüssel 0123456789abcdeffedcba9876543210, Klartext (Hex) 0123456789abcdeffedcba9876543210
681edf34d206965e86b3e94f536e4246

Dies ist Beispiel 1 aus Anhang A von GB/T 32907-2016: Schlüssel und Klartext sind derselbe 128-Bit-Wert, und eine Verschlüsselung ergibt 681edf34d206965e86b3e94f536e4246. Wird diese Ausgabe immer wieder verschlüsselt, insgesamt eine Million Mal, ergibt sich 595298c7c6fd271f0402f804c33d3f66. Beide Werte stehen in der Testvektor-Tabelle auf dieser Seite, berechnet von derselben Engine, die Sie gerade verwenden. Die Schaltfläche Testvektor GB/T 32907 lädt den ersten.

CBC mit PKCS#7: Text rein, Base64 raus

Schlüssel 0123456789abcdeffedcba9876543210, IV fedcba98765432100123456789abcdef, Klartext: SM4 interop test: order 20260911-0042
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y

Der Klartext umfasst 37 Byte UTF-8. PKCS#7 füllt ihn auf 48 Byte auf, also drei 16-Byte-Blöcke, die Base64 als 64 Zeichen schreibt. Die Schaltfläche Beispiel laden trägt genau diese Werte ein, und der OpenSSL-Bereich zeigt einen Befehl, der im Terminal denselben Base64-String erzeugt.

Falscher IV bei CBC: nur die ersten 16 Byte gehen kaputt

Der Chiffretext von oben, entschlüsselt mit IV 00000000000000000000000000000000
16 Byte Datenmüll, dann ": order 20260911-0042"

CBC mischt den IV nur in den ersten Block ein, und das PKCS#7-Padding steht im letzten Block — die Padding-Prüfung besteht also weiterhin, und OpenSSL meldet keinen Fehler. Diese Seite bemerkt den unlesbaren ersten Block und sagt Ihnen, dass Schlüssel und Modus stimmen und der IV das Problem ist — oder dass die ersten 16 Byte des Chiffretexts selbst der IV sind.

So ver- und entschlüsseln Sie mit SM4

  1. 1

    Bibliotheks-Voreinstellung wählen — oder Modus und Padding

    Kennen Sie die Bibliothek auf der Gegenseite, wählen Sie sie unter „Standardwerte übernehmen von“. Andernfalls wählen Sie Verschlüsseln oder Entschlüsseln und stellen Modus und Padding passend ein. Stream-Modi (CTR, CFB, OFB) haben kein Padding, deshalb ist die Padding-Auswahl für sie deaktiviert.

  2. 2

    Schlüssel und IV eingeben

    Beide sind genau 16 Byte lang. Wählen Sie das Format, in dem die Zeichenkette geschrieben ist — Hex, Text oder Base64 — und achten Sie darauf, dass der Byte-Zähler grün wird. Die Schaltflächen „Zufällig“ erzeugen neue Werte.

  3. 3

    Eingabe einfügen

    Zum Verschlüsseln geben Sie Text (UTF-8 oder GBK) ein oder fügen Hex-Bytes ein. Zum Entschlüsseln fügen Sie den Chiffretext ein und geben an, ob er Base64 oder Hex ist. Das Ergebnis aktualisiert sich während der Eingabe.

  4. 4

    Ergebnis kopieren oder Gegenprobe machen

    Kopieren Sie die Ausgabe, oder klicken Sie auf „Diesen Chiffretext entschlüsseln“, um ihn mit demselben Schlüssel und IV in den Tab „Entschlüsseln“ zu übernehmen. Der OpenSSL-Bereich zeigt einen Befehl, der das Ergebnis reproduziert.

  5. 5

    Scheitert die Entschlüsselung: Diagnose lesen

    Die Diagnose listet die Einstellungen auf, unter denen Ihre Eingaben zu lesbarem Text entschlüsselt werden. Übernehmen Sie eine davon per Klick, oder lesen Sie den Hinweis, falls nur die ersten 16 Byte scheitern — das deutet auf den IV.

Warum die Entschlüsselung mit SM4 scheitert

Hex-Schlüssel als Text gelesen

Ein 32-stelliger Hex-String ist nur dann 16 Byte lang, wenn er als Hex dekodiert wird. Als Text gelesen sind es 32 Byte, die SM4 ablehnt — oder, in Code, der Schlüssel stillschweigend kürzt oder auffüllt, ein ganz anderer Schlüssel.

✗ Falsch
Schlüssel (Text): 0123456789abcdeffedcba9876543210  -> 32 Byte, abgelehnt
✓ Richtig
Schlüssel (Hex):  0123456789abcdeffedcba9876543210  -> 16 Byte

CBC-Chiffretext als ECB entschlüsselt

Beide Seiten müssen denselben Modus verwenden. CBC-Chiffretext, der als ECB entschlüsselt wird, ergibt in jedem Block Datenmüll und scheitert meist an der Padding-Prüfung am Ende.

✗ Falsch
verschlüsseln: SM4/CBC/PKCS5Padding
entschlüsseln: SM4/ECB/PKCS5Padding  -> bad decrypt
✓ Richtig
verschlüsseln: SM4/CBC/PKCS5Padding
entschlüsseln: SM4/CBC/PKCS5Padding, gleicher IV

Ein anderer IV

Bei CBC löst ein falscher IV keinen Fehler aus: Die ersten 16 Byte kommen verstümmelt heraus, der Rest wird normal entschlüsselt. Ist nur der Anfang Ihres Klartexts kaputt, vergleichen Sie die IVs.

✗ Falsch
entschlüsseln mit IV 00000000000000000000000000000000
-> 16 Byte Datenmüll + ": order 20260911-0042"
✓ Richtig
entschlüsseln mit IV fedcba98765432100123456789abcdef
-> "SM4 interop test: order 20260911-0042"

Base64-Chiffretext als Hex behandelt

Base64 und Hex sind zwei Schreibweisen für dieselben Bytes. Wird das eine als das andere gelesen, bekommt die Chiffre von Anfang an die falsche Eingabe.

✗ Falsch
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  als Hex gelesen -> ungültig
✓ Richtig
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  als Base64 gelesen -> 48 Byte

Zero-Padding löscht echte Nullen am Ende

Zero-Padding kann Padding nicht von Daten unterscheiden, deshalb verliert Klartext, der tatsächlich auf 0x00 endet, diese Bytes. Verwenden Sie PKCS#7 für alles, was kein reiner Text ist.

✗ Falsch
Zero-Padding: 61 62 00  -> entschlüsselt zu 61 62
✓ Richtig
PKCS#7:       61 62 00  -> entschlüsselt zu 61 62 00

Annahme, „SM4“ bedeute überall denselben Modus

OpenSSL behandelt sm4 als CBC. BouncyCastle — und damit auch SmUtil.sm4(key) von Hutool — behandelt SM4 als ECB mit PKCS#7. Zwei Systeme, die beide „einfach SM4 verwenden“, können sich beim Modus uneinig sein.

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

GBK-Bytes auf der einen, UTF-8 auf der anderen Seite verschlüsselt

getBytes() ohne Zeichensatz verwendet in Java den Plattform-Standard, und der ist unter chinesischem Windows mit JDK 17 oder älter GBK. Derselbe chinesische Text wird dann zu anderem Chiffretext, und die Gegenseite entschlüsselt ihn zu Mojibake (Zeichensalat).

✗ Falsch
"国密SM4 test".getBytes()  // GBK unter chinesischem Windows, JDK <= 17
-> ECB-Chiffretext 3188d06cf28db70092f8753cbd5ee518
✓ Richtig
"国密SM4 test".getBytes(StandardCharsets.UTF_8)
-> ECB-Chiffretext d830308b0ae4fa7b9a2b5d59f7f65ca5

Wann Sie SM4 online brauchen

SM4-Ausgabe zwischen Backend und Frontend abgleichen
Ihr Java-Service und Ihr Web-Client erzeugen für denselben Text unterschiedlichen Chiffretext. Bilden Sie hier jede Seite mit ihrer Bibliotheks-Voreinstellung nach und sehen Sie, welcher Parameter abweicht.
Gescheiterte Entschlüsselung aus einem Partnersystem debuggen
Ein Partner schickt SM4-Chiffretext, der sich nicht entschlüsseln lässt. Fügen Sie ihn mit dem vereinbarten Schlüssel und IV ein, und die Diagnose findet Modus, Padding oder Kodierung, die tatsächlich verwendet wurden.
Eine SM4-Implementierung verifizieren
Prüfen Sie Ihren Code gegen die Vektoren aus GB/T 32907 auf dieser Seite und vergleichen Sie dann eine CBC-Gegenprobe, bevor die Implementierung auch nur in die Nähe von Produktionsdaten kommt.
Testdaten für eine Migration auf SM4 vorbereiten
Wechselt ein System von AES zu SM4, erzeugen Sie hier bekannte Tripel aus Schlüssel, IV und Chiffretext, die Sie als Fixtures in den neuen Tests verwenden.
Verstehen, wie sich Blockchiffre-Modi verhalten
Verschlüsseln Sie zwei identische Blöcke in ECB und CBC oder entschlüsseln Sie mit einem falschen IV, und beobachten Sie, was sich im Chiffretext und in der Ausgabe ändert.

So funktionieren SM4 und seine Modi

Blockgröße, Schlüsselgröße und Runden
SM4 verschlüsselt 128-Bit-Blöcke mit einem 128-Bit-Schlüssel in 32 Runden. Jede Runde wendet eine 8-Bit-S-Box auf ein 32-Bit-Wort an und danach eine lineare Transformation, die das Wort per XOR mit vier Rotationen seiner selbst verknüpft. Die Entschlüsselung durchläuft dieselben 32 Runden mit den Rundenschlüsseln in umgekehrter Reihenfolge.
ECB: jeder Block für sich
ECB verschlüsselt jeden 16-Byte-Block unabhängig. Es braucht keinen IV, aber gleiche Klartextblöcke werden zu gleichen Chiffretextblöcken, sodass Muster in den Daten sichtbar bleiben. Padding ist nötig, sofern die Eingabe kein Vielfaches von 16 Byte ist.
CBC: verkettete Blöcke und ein IV
CBC verknüpft jeden Klartextblock vor dem Verschlüsseln per XOR mit dem vorherigen Chiffretextblock und verwendet für den ersten Block den IV. Weil der IV nur in den ersten Block eingeht, verfälscht ein falscher IV genau die ersten 16 Byte des Klartexts und lässt das Padding im letzten Block intakt — oft gibt es daher überhaupt keinen Fehler.
CTR, CFB und OFB: SM4 als Stromchiffre
Diese Modi verschlüsseln einen Zähler- oder Rückkopplungswert und verknüpfen das Ergebnis per XOR mit den Daten, sodass der Chiffretext genauso lang ist wie der Klartext und kein Padding anfällt. In CTR wird der gesamte 16-Byte-IV als ein 128-Bit-Big-Endian-Zähler hochgezählt, passend zu OpenSSL. Ein falscher IV verfälscht in CTR und OFB die gesamte Nachricht, in CFB dagegen nur den ersten Block.
Padding-Regeln
PKCS#7 fügt 1 bis 16 Byte mit dem Wert n hinzu, sodass auch eine Nachricht, die bereits aus ganzen Blöcken besteht, einen vollen Padding-Block bekommt. Zero-Padding fügt 0x00-Bytes nur bei Bedarf hinzu und entfernt beim Entschlüsseln alle abschließenden Nullen. Ohne Padding bleiben die Daten unverändert, und Eingaben, die keine ganzen Blöcke füllen, werden abgelehnt.

Best Practices für SM4

ECB nicht für neue Designs wählen
ECB verrät, welche Blöcke gleich sind. Verwenden Sie CBC oder CTR, sofern Sie nicht ein bestehendes System nachbilden, das bereits ECB einsetzt.
Für jede Nachricht einen frischen, zufälligen IV verwenden
Der IV ist nicht geheim, darf sich unter demselben Schlüssel aber nicht wiederholen. Erzeugen Sie ihn für jede Nachricht zufällig und speichern oder senden Sie ihn zusammen mit dem Chiffretext.
Den Chiffretext authentifizieren
GB/T 17964-2021, der chinesische Standard zu den Betriebsmodi von Blockchiffren, hält fest, dass die darin beschriebenen Modi die Vertraulichkeit schützen, nicht die Integrität. In CBC macht die Änderung eines einzigen Bytes im IV aus pay=100.00 ein pay=900.00, und die Entschlüsselung gelingt trotzdem. Berechnen Sie einen MAC über IV und Chiffretext und prüfen Sie ihn vor dem Entschlüsseln, zum Beispiel mit dem HMAC-Generator.
Jeden Parameter in die Schnittstellenspezifikation schreiben
„SM4-verschlüsselt“ ist keine Spezifikation. Halten Sie Modus, Padding, die Kodierung von Schlüssel und IV, den Zeichensatz des Klartexts und das Format des Chiffretexts (Hex oder Base64) schriftlich fest.
Echte Schlüssel aus Webseiten und Quellcode heraushalten
Verwenden Sie diese Seite mit Testschlüsseln. Produktionsschlüssel gehören in ein Schlüsselverwaltungssystem oder Hardware-Sicherheitsmodul und werden zur Laufzeit geladen, statt eingefügt oder eingecheckt zu werden.

FAQ zur Verschlüsselung mit SM4

Warum scheitert meine SM4-Entschlüsselung mit einem Padding-Fehler oder Zeichensalat?
Entschlüsseln funktioniert nur, wenn alles zur verschlüsselnden Seite passt: die Schlüsselbytes, der Modus, der IV, das Padding und die Schreibweise des Chiffretexts (Hex oder Base64). Die Fehlermeldung — „bad decrypt“, eine Padding-Exception oder ein Bildschirm voller Zeichensalat — verrät nicht, was davon nicht stimmt, und manche Bibliotheken liefern statt eines Fehlers einfach eine leere Ausgabe. Fügen Sie Chiffretext, Schlüssel und IV trotzdem hier ein. Scheitert die Entschlüsselung, probiert die Seite jede Kombination aus Chiffretext-Kodierung, Schlüsselformat, Modus, IV und Padding durch — einschließlich Schlüsseln, die eine Bibliothek stillschweigend auf 16 Byte gekürzt hat, und Klartext in GBK-Kodierung — und listet die Lesarten auf, die lesbaren Text ergeben; Treffer mit gültigem PKCS#7-Padding sind markiert. Sind nur die ersten 16 Byte falsch, stimmen Schlüssel und Modus, der IV aber nicht.
Wie lang ist ein SM4-Schlüssel, und kann er 256 Bit haben?
Ein SM4-Schlüssel hat genau 128 Bit, also 16 Byte — so groß wie ein Block. GB/T 32907 definiert nur diese eine Schlüssellänge; SM4 mit 192 oder 256 Bit gibt es nicht. Verlangt jemand einen 256-Bit-Schlüssel für SM4, prüfen Sie, ob ein 32-stelliger Hex-String als 32 Zeichen zu je 8 Bit gezählt wurde. Sechzehn Byte lassen sich als 32 Hex-Ziffern oder als 16 ASCII-Zeichen schreiben, und beides zu verwechseln ist der häufigste Schlüsselfehler: 0123456789abcdeffedcba9876543210 als Hex gelesen sind 16 Byte, dieselbe Zeichenkette als Text gelesen aber 32 Byte — und wird abgelehnt. Genau dafür gibt es die Formatauswahl und den Byte-Zähler neben dem Schlüsselfeld.
Was ist der SM4-IV, und wie lang muss er sein?
Der IV (Initialisierungsvektor) ist ein 16-Byte-Wert, der bei CBC, CTR, CFB und OFB in den ersten Block eingemischt wird; ECB verwendet keinen. Er muss genau 16 Byte lang sein — 32 Hex-Ziffern oder 16 ASCII-Zeichen. Erhalten Sie einen Fehler zur IV-Länge, prüfen Sie also, ob ein 32-stelliger Hex-String als 32 Byte Text gelesen wurde. Der IV ist nicht geheim, darf sich unter demselben Schlüssel aber nicht wiederholen: Erzeugen Sie ihn zufällig und senden Sie ihn mit dem Chiffretext mit, oft direkt davor. Ein falscher IV löst bei CBC meist keinen Fehler aus und verfälscht nur die ersten 16 Byte. Manche Bibliotheken verwenden stillschweigend einen Null-IV, wenn keiner angegeben ist (sm-crypto-v2, tjfoc/gmsm für Go), während BouncyCastle unter Java einen zufälligen erzeugt — wird dieser IV nicht zusammen mit dem Chiffretext gespeichert, kann niemand mehr entschlüsseln.
Was ist der Unterschied zwischen SM4 ECB und CBC, und was sollte ich verwenden?
Verwenden Sie CBC (oder CTR) mit einem frischen, zufälligen IV für jede Nachricht. ECB verschlüsselt gleiche 16-Byte-Blöcke zu gleichen Chiffretextblöcken, sodass wiederkehrende Strukturen der Daten im Chiffretext sichtbar bleiben. Wählen Sie ECB nur, um mit einem System zu kommunizieren, das es bereits verwendet. Beachten Sie, dass keiner der beiden Modi Manipulationen erkennt: Ist das wichtig, senden Sie zusätzlich einen MAC über IV und Chiffretext mit, zum Beispiel mit dem HMAC-Generator.
Welches SM4-Padding sollte ich nehmen: PKCS5Padding, PKCS#7, Zero-Padding oder kein Padding?
PKCS#7 hängt immer 1 bis 16 Byte an, von denen jedes die Anzahl der angehängten Bytes enthält, sodass der Empfänger es eindeutig entfernen kann. Bei einer Blockchiffre mit 16-Byte-Blöcken wie SM4 ist PKCS5Padding aus Java genau dasselbe Padding — BouncyCastle schickt beide Namen durch denselben Codepfad. Zero-Padding hängt 0x00 nur bis zur nächsten Blockgrenze an. Beim Entschlüsseln entfernen Hutool und BouncyCastle alle abschließenden 0x00, auch Nullbytes, die eigentlich zu den Daten gehörten, während gmssl für Python nur eines entfernt. Ohne Padding muss die Eingabe aus ganzen 16-Byte-Blöcken bestehen. CTR, CFB und OFB sind Stream-Modi und verwenden nie Padding. Endet der entschlüsselte Text auf verirrte Leerzeichen, Kästchen oder Zeilenumbrüche, wurde das Padding nicht entfernt: PKCS#7-Daten, die ohne Padding entschlüsselt werden, behalten am Ende n Bytes mit dem Wert n (0x09, 0x0A und 0x0D erscheinen als Tabulatoren und Zeilenumbrüche); stellen Sie die Ausgabe auf Hex um und sehen Sie sich den letzten Block an.
Wie lang ist SM4-Chiffretext, und lässt sich daran der Modus erkennen?
Rechnen Sie in Bytes. Mit PKCS#7 in ECB oder CBC wird der Klartext auf das nächste Vielfache von 16 aufgerundet, und eine Nachricht, die bereits ein Vielfaches von 16 ist, bekommt einen weiteren vollen Block — aus 5 oder 15 Byte werden 16, aus 16 Byte werden 32. Zero-Padding füllt nur bis zum nächsten Vielfachen von 16 auf, ohne Padding bleibt die Länge gleich, und Chiffretext in CTR, CFB und OFB ist genau so lang wie der Klartext. Hex verdoppelt die Byteanzahl; Base64 braucht 4 × ⌈Bytes / 3⌉ Zeichen, also 24 Zeichen für 16 Byte, 44 für 32 und 88 für 64. Steht der IV vorne, kommen 16 Byte hinzu. Der Chiffretext allein verrät den Modus nicht, aber zwei Indizien helfen: Eine Länge, die kein Vielfaches von 16 ist, schließt ECB oder CBC mit Padding praktisch aus, und zwei identische 16-Byte-Blöcke deuten auf ECB hin. Im Zweifel fügen Sie ihn im Tab „Entschlüsseln“ ein, und die Auto-Diagnose probiert die Modi für Sie durch.
Liefert SM4 jedes Mal denselben Chiffretext, und warum weicht ein anderes Tool ab?
ECB — oder jeder Modus mit festem IV — liefert für denselben Schlüssel und Klartext jedes Mal denselben Chiffretext; mit einem frischen, zufälligen IV pro Durchlauf ändert sich die Ausgabe jedes Mal, und so soll es auch sein. Darüber hinaus vergleichen Sie den Modus, das Padding, ob der Schlüssel als Hex oder Text gelesen wurde, wie der Klartext kodiert wurde — in den meisten Programmen UTF-8, aber GBK, wenn älterer Java-Code auf einem chinesischen Windows-System getBytes() aufruft — und wie das Ergebnis ausgegeben wird: Base64, Hex in Klein- oder in Großbuchstaben. Bei identischen Einstellungen und festem IV liefern zwei korrekte Implementierungen identische Ausgaben. Haben Sie eines der Tools im Verdacht, prüfen Sie zuerst beide gegen den Testvektor aus GB/T 32907.
Wie prüfe ich, ob meine eigene SM4-Implementierung korrekt ist?
Beginnen Sie mit den beiden Vektoren aus Anhang A von GB/T 32907-2016. Sind Schlüssel und Klartext beide 0123456789abcdeffedcba9876543210, muss eine Verschlüsselung 681edf34d206965e86b3e94f536e4246 ergeben und eine Million verkettete Verschlüsselungen 595298c7c6fd271f0402f804c33d3f66. Diese Vektoren testen nur die Blockchiffre selbst; verschlüsseln Sie deshalb als Nächstes einen Text in CBC mit festem Schlüssel und IV und vergleichen Sie das Ergebnis mit dieser Seite oder mit dem angezeigten OpenSSL-Befehl. Die Engine hinter dieser Seite ist gegen beide Vektoren und in allen fünf Modi gegen OpenSSL 3 getestet.
Kann OpenSSL SM4 ver- und entschlüsseln?
Ja. OpenSSL 3 enthält SM4 in ECB, CBC, CFB, OFB und CTR. Verwenden Sie openssl enc -sm4-cbc -K <32 hex digits> -iv <32 hex digits>: -K erwartet den rohen Schlüssel als Hex, es ist also kein Passwort im Spiel, -nopad schaltet PKCS#7 ab, und -base64 -A liest oder schreibt einzeiliges Base64. Achten Sie auf zwei Dinge: Ein bloßes -sm4 bedeutet CBC, und ein -K-Wert mit falscher Länge wird nur mit einer Warnung gekürzt oder mit Nullen aufgefüllt. Der OpenSSL-Bereich auf dieser Seite baut den Befehl aus Ihren aktuellen Einstellungen; openssl enc kennt kein Zero-Padding, deshalb weist der Bereich darauf hin, statt einen Befehl auszugeben, der nicht passen würde.
Wie entschlüssele ich SM4-Chiffretext aus Java (Hutool) oder JavaScript (sm-crypto)?
Finden Sie zuerst heraus, welchen Modus und welches Padding die Gegenseite wirklich verwendet — oft steht das nirgends im Code. SmUtil.sm4(key) von Hutool übergibt nur den Namen SM4, und BouncyCastle ergänzt ECB mit PKCS#7 (in Java PKCS5Padding); erst ein vollständiger String wie SM4/CBC/PKCS5Padding bedeutet CBC. In JavaScript verwendet auch sm-crypto standardmäßig ECB, erwartet den Schlüssel als 32-stelligen Hex-String und gibt Hex in Kleinbuchstaben aus, während gm-crypt standardmäßig CBC verwendet, einen Textschlüssel mit 16 Zeichen erwartet und Base64 ausgibt. Prüfen Sie dann den Zeichensatz des Klartexts: Die String-Methoden von Hutool verwenden immer UTF-8, aber ein bloßes getBytes() kann unter JDK 17 oder älter auf chinesischem Windows GBK bedeuten, was den Chiffretext verändert. Wählen Sie die Bibliothek unter Standardwerte übernehmen von, um all das mit einem Klick einzustellen, oder tragen Sie es selbst ein; ist etwas unklar, fügen Sie den Chiffretext trotzdem ein, und die Auto-Diagnose probiert die Kombinationen aus Modus, Padding, IV und Kodierung durch.
Ist SM4 sicher, und werden meine Daten hochgeladen?
Als Algorithmus verwendet SM4 einen 128-Bit-Schlüssel und 32 Runden; RFC 8998 (2021) hält fest, dass zum Zeitpunkt der Veröffentlichung keine schwachen Schlüssel oder Sicherheitsprobleme von SM4 bekannt waren. Die praktischen Risiken liegen in der Verwendung: ECB verrät Muster, und CBC erkennt keine Manipulationen. Was diese Seite betrifft: Es wird nichts hochgeladen. Browser bringen kein SM4 mit, deshalb liefert diese Seite ihre eigene SM4-Implementierung mit und führt sie lokal aus; Sie können im Netzwerk-Tab der Entwicklertools nachsehen, dass keine Anfrage hinausgeht, oder die Verbindung trennen und das Tool weiter benutzen. Für Testdaten, Debugging und zum Lernen ist das also in Ordnung. Zum richtigen Ort für Produktionsschlüssel wird eine Webseite dadurch aber nicht: Die gehören in ein Schlüsselverwaltungssystem oder ein Hardware-Sicherheitsmodul, nicht in ein Textfeld auf irgendeiner Website.
Was ist der Unterschied zwischen SM4 und AES?
Beide sind Blockchiffren mit 128-Bit-Blöcken, und Modi und Padding funktionieren bei beiden gleich — deshalb sehen Interoperabilitätsfehler bei SM4 genauso aus wie bei AES. SM4 läuft über 32 Runden und hat eine einzige Schlüsselgröße von 128 Bit; AES-128 läuft über 10 Runden, und AES gibt es zusätzlich mit 192- und 256-Bit-Schlüsseln. SM4 ist der chinesische nationale Standard GB/T 32907-2016 und seit 2021 neben AES Teil des internationalen Standards ISO/IEC 18033-3; eingesetzt wird SM4 dort, wo chinesische kommerzielle Kryptografie vorgeschrieben ist. AES ist der NIST-Standard FIPS 197. Für AES verwenden Sie das AES-Verschlüsselungstool.

Verwandte Werkzeuge

Alle Werkzeuge anzeigen →

AES-Entschlüsselungstool — OpenSSL- & CryptoJS-kompatibel

Sicherheitswerkzeuge

AES online entschlüsseln — GCM/CBC/CTR, Passphrase oder Rohschlüssel, erkennt automatisch das OpenSSL- & CryptoJS-Format „U2FsdGVkX1“. 100 % im Browser, Schlüssel verlassen die Seite nie.

AES-Verschlüsselungstool — GCM, CBC & CTR

Sicherheitswerkzeuge

Kostenloses Online-Tool für AES-Verschlüsselung — AES-128/192/256, GCM/CBC/CTR, Passphrase (PBKDF2) oder Rohschlüssel. Läuft zu 100 % im Browser; nichts wird hochgeladen.

Bcrypt-Hash-Generator & Verifizierer

Sicherheitswerkzeuge

Bcrypt-Passwort-Hashes online erzeugen und prüfen — einstellbarer Kostenfaktor, $2b$/$2a$/$2y$. 100 % im Browser; dein Passwort wird nie hochgeladen.

CRC-Prüfsummenrechner

Sicherheitswerkzeuge

Hex oder Text einfügen, alle 63 CRC-8-, CRC-16- und CRC-32-Varianten auf einmal berechnen. Prüfsumme passt nicht? Wert eintragen, das Tool nennt die Variante: MODBUS, CCITT-FALSE, XMODEM, KERMIT. Rechnet lokal im Browser.

HMAC-Generator & Signaturprüfer

Sicherheitswerkzeuge

Kostenloser HMAC-Generator und -Prüfer online. Berechne HMAC-SHA256/SHA1/SHA384/SHA512 mit Schlüsseln als Text, Hex oder Base64 und Ausgabe als Hex/Base64/Base64URL. 100 % in deinem Browser — Schlüssel verlassen nie die Seite.

JWT-Dekodierer

Sicherheitswerkzeuge

Dekodieren Sie JWT-Token online mit unserem kostenlosen JWT-Dekodierer. Inspizieren Sie sofort Header, Payload, Signatur, Ablauf und Claims. 100 % Browser — Ihr Token verlässt niemals Ihr Gerät. Keine Anmeldung, kein Tracking.