Skip to content

Szyfrowanie i odszyfrowanie SM4 online

Szyfrowanie SM4 online. Gdy odszyfrowanie zawodzi, wskaże błędny tryb, dopełnienie, IV lub kodowanie i poda poprawkę. Działa lokalnie, bez wysyłania. ECB, CBC, CTR, CFB, OFB, PKCS#7.

Bez śledzenia Działa w przeglądarce Bezpłatne
Szyfrowanie odbywa się w całości w przeglądarce — wpisany klucz i dane nigdy nie opuszczają tego urządzenia.
Szyfrogram
Równoważne polecenie OpenSSL 
—

Wymaga OpenSSL 3. Polecenie zawiera wpisany klucz.

Wektory testowe SM4 z normy GB/T 32907-2016

Obliczone podczas budowania strony przez ten sam silnik, który tu działa — można na nich sprawdzić własną implementację SM4.
Klucz 0123456789abcdeffedcba9876543210
Tekst jawny 0123456789abcdeffedcba9876543210
Szyfrogram, 1 szyfrowanie 681edf34d206965e86b3e94f536e4246
Szyfrogram, 1 000 000 szyfrowań 595298c7c6fd271f0402f804c33d3f66
Silnik SM4 jest testowany na obu wektorach z załącznika A normy GB/T 32907-2016 i porównywany z OpenSSL 3 w trybach ECB, CBC, CTR, CFB i OFB. Domyślne ustawienia bibliotek sprawdzono, uruchamiając OpenSSL, Node.js, sm-crypto, gm-crypt, gmssl i dwie biblioteki Go oraz czytając kod źródłowy Hutool i BouncyCastle. — Zespół ds. Bezpieczeństwa Go-Tools · Sep 11, 2026

Napisane i zweryfikowane przez programistów budujących narzędzia kryptograficzne. Każdy szyfrogram i każda liczba bajtów podana na tej stronie są obliczane przez silnik narzędzia i sprawdzane testami.

SM4 — szybkie odpowiedzi

Długość klucza SM4

16 bajtów Dokładnie 128 bitów: 16 bajtów, zapisanych jako 32 cyfry szesnastkowe lub 16 znaków ASCII. Nie istnieją 192- ani 256-bitowe klucze SM4.

Wektor testowy GB/T 32907

681edf34d206965e86b3e94f536e4246 Dla klucza i tekstu jawnego 0123456789abcdeffedcba9876543210 jedno szyfrowanie daje 681edf34d206965e86b3e94f536e4246.

Rozmiar bloku i liczba rund SM4

32 rundy Bloki 16-bajtowe (128-bitowe), szyfrowane w 32 rundach.

Czy błędny IV w CBC zawsze powoduje błąd?

pierwsze 16 bajtów Nie. Błędnie odszyfrowuje się tylko pierwsze 16 bajtów, a dopełnienie w ostatnim bloku nadal przechodzi kontrolę.

Czym jest SM4?

SM4 to szyfr blokowy z chińskich standardów kryptografii komercyjnej. Opublikowano go jako GM/T 0002-2012, następnie stał się normą krajową GB/T 32907-2016 (obowiązującą od 1 marca 2017 r.), a w 2021 roku poprawka dodała go do międzynarodowej normy ISO/IEC 18033-3. To szyfr symetryczny: ten sam 128-bitowy klucz służy do szyfrowania i odszyfrowania, a dane są przetwarzane w 128-bitowych blokach, po 16 bajtów naraz — to ten sam rozmiar bloku co w AES.

Wewnątrz każdy blok jest dzielony na cztery 32-bitowe słowa i przechodzi przez 32 rundy. W każdej rundzie trzy słowa są łączone z kluczem rundy, wynik przechodzi przez 8-bitowy S-box i przekształcenie liniowe, a na końcu zostaje połączony z czwartym słowem. Wszystkie 32 klucze rund wyprowadza się z klucza za pomocą dwóch ustalonych zestawów stałych, a odszyfrowanie to te same obliczenia z kluczami rund w odwrotnej kolejności.

Sam szyfr blokowy obsługuje wyłącznie dokładnie 16 bajtów, dlatego prawdziwe dane zawsze przechodzą przez tryb pracy. To narzędzie oferuje pięć klasycznych trybów: ECB i CBC, które działają na pełnych blokach i wymagają dopełnienia, oraz CTR, CFB i OFB, które zamieniają SM4 w szyfr strumieniowy bez żadnego dopełnienia. Większość nieudanych odszyfrowań nie ma nic wspólnego z samym SM4 — wynika z tego, że obie strony różnie ustawiają tryb, dopełnienie, IV, kodowanie tekstu albo sposób zamiany ciągu klucza na bajty, a biblioteki nie zgadzają się nawet co do tego, co oznacza samo „SM4”.

Wbudowany w przeglądarki interfejs Web Crypto API nie obejmuje SM4, dlatego ta strona zawiera własną implementację i uruchamia ją lokalnie. Jest ona testowana na dwóch wektorach testowych GB/T 32907 i porównywana z OpenSSL 3 w każdym trybie.

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

Funkcje narzędzia SM4

Wyjaśnia, dlaczego odszyfrowanie się nie powiodło

Gdy odszyfrowanie zawodzi, strona ponownie sprawdza kodowanie szyfrogramu, format klucza, tryb, IV, dopełnienie i kodowanie tekstu, a następnie pokazuje ustawienia, które dają czytelny tekst.

Gotowe ustawienia najczęściej używanych bibliotek

Jedno kliknięcie ustawia wartości domyślne OpenSSL, Hutool, sm-crypto, gm-crypt lub tjfoc/gmsm — bibliotek, które nie zgadzają się nawet co do tego, czy samo „SM4” oznacza ECB, czy CBC.

Pięć trybów, trzy rodzaje dopełnienia, UTF-8 lub GBK

ECB, CBC, CTR, CFB i OFB z PKCS#7, dopełnieniem zerami lub bez dopełnienia. Tekst jawny może być w UTF-8 albo w GBK — kodowaniu, które starszy kod w Javie tworzy w chińskiej wersji Windows. GCM nie jest obsługiwany.

Klucz i IV SM4: losowe albo jako hex, tekst lub Base64

Losowy 16-bajtowy klucz lub IV można wygenerować jednym kliknięciem albo wpisać w takiej postaci, w jakiej zapisuje go kod. Licznik bajtów na żywo potwierdza, że jest ich dokładnie 16, zanim zacznie się szukać innych przyczyn.

Wektory testowe GB/T 32907 na stronie

Oba wyniki z załącznika A są podane w tabeli i można je wczytać jednym kliknięciem, więc każdą implementację SM4 da się sprawdzić względem normy.

Równoważne polecenie OpenSSL

Każdemu wynikowi towarzyszy polecenie openssl enc, które go odtwarza, dzięki czemu można go potwierdzić w terminalu albo przekazać współpracownikowi.

Działa w całości w przeglądarce

Silnik SM4 działa lokalnie. Klucze i dane nigdy nie opuszczają strony, a narzędzie działa także offline.

Domyślne ustawienia SM4 w popularnych bibliotekach

OpenSSL 3 (openssl enc)

-sm4 = CBC

-sm4 to alias -sm4-cbc. -K i -iv przyjmują hex, PKCS#7 pozostaje włączone, dopóki nie poda się -nopad, a wynik to surowe bajty, chyba że doda się -base64 -A. -K o złej długości jest obcinany lub dopełniany zerami, a OpenSSL wyświetla jedynie ostrzeżenie.

Java: Hutool SmUtil.sm4(key)

ECB · PKCS#7

Hutool przekazuje samo SM4, które BouncyCastle wykonuje jako ECB z PKCS#7 (w JCE: PKCS5Padding). Metody tekstowe używają UTF-8, a encryptHex zwraca hex małymi literami. Dla CBC trzeba użyć new SM4(Mode.CBC, Padding.PKCS5Padding, key, iv).

Java: BouncyCastle Cipher.getInstance("SM4")

ECB · PKCS#7

W trybie, który wymaga IV, ale go nie dostaje, szyfrowanie po cichu generuje losowy IV, a odszyfrowanie rzuca no IV set when one expected — więc szyfrogramu zaszyfrowanego bez zapisania tego IV nie da się nigdzie odszyfrować.

JavaScript: sm-crypto

ECB · klucz hex

sm4.encrypt(data, key) domyślnie używa ECB z PKCS#7, oczekuje klucza jako 32-cyfrowego ciągu szesnastkowego i zwraca hex małymi literami. Tryb zmienia tylko mode: 'cbc'; każda inna wartość po cichu pozostawia ECB. sm-crypto-v2 zachowuje się tak samo, ale gdy CBC nie dostanie iv, używa IV złożonego z samych zer.

JavaScript: gm-crypt

CBC · klucz tekstowy · Base64

Domyślnie używa CBC, przyjmuje klucz i IV jako 16-znakowe ciągi UTF-8 i zwraca Base64. Klucza, którego bajty nie są poprawnym UTF-8, w ogóle nie da się do niego przekazać.

Python: gmssl CryptSM4

PKCS#7 · klucz obcinany do 16 bajtów

Tryb wybiera się, wywołując crypt_ecb lub crypt_cbc. set_key odczytuje tylko pierwsze 16 bajtów, więc dłuższy klucz jest po cichu obcinany, a błędny klucz zwykle zwraca puste bajty zamiast błędu.

Go: tjfoc/gmsm sm4

domyślnie zerowy IV

Sm4Cbc używa IV na poziomie pakietu, który pozostaje wyzerowany, dopóki nie zostanie wywołane SetIV, dopełnia PKCS#7 nawet w CFB i OFB i ignoruje błędy usuwania dopełnienia — błędny klucz zwraca nil bez żadnego błędu.

Przykłady szyfrowania i odszyfrowania SM4

Wektor testowy GB/T 32907 (ECB, bez dopełnienia)

Klucz 0123456789abcdeffedcba9876543210, tekst jawny (hex) 0123456789abcdeffedcba9876543210
681edf34d206965e86b3e94f536e4246

To przykład 1 z załącznika A normy GB/T 32907-2016: klucz i tekst jawny mają tę samą 128-bitową wartość, a jedno szyfrowanie daje 681edf34d206965e86b3e94f536e4246. Szyfrowanie wyniku raz za razem, łącznie milion razy, daje 595298c7c6fd271f0402f804c33d3f66. Obie wartości są podane w tabeli wektorów testowych na tej stronie i zostały obliczone przez ten sam silnik, który obsługuje narzędzie. Przycisk Wektor testowy GB/T 32907 wczytuje pierwszą z nich.

CBC z PKCS#7: tekst na wejściu, Base64 na wyjściu

Klucz 0123456789abcdeffedcba9876543210, IV fedcba98765432100123456789abcdef, tekst jawny: SM4 interop test: order 20260911-0042
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y

Tekst jawny to 37 bajtów UTF-8. PKCS#7 dopełnia go do 48 bajtów, czyli trzech 16-bajtowych bloków, które w Base64 zajmują 64 znaki. Przycisk Wczytaj przykład wstawia dokładnie te wartości, a panel OpenSSL pokazuje polecenie, które odtwarza w terminalu ten sam ciąg Base64.

Błędny IV w CBC: psuje się tylko pierwsze 16 bajtów

Szyfrogram z poprzedniego przykładu odszyfrowany z IV 00000000000000000000000000000000
16 bajtów śmieci, potem ": order 20260911-0042"

CBC miesza IV wyłącznie z pierwszym blokiem, a dopełnienie PKCS#7 znajduje się w ostatnim bloku, więc kontrola dopełnienia nadal przechodzi i OpenSSL nie zgłasza żadnego błędu. Ta strona zauważa nieczytelny pierwszy blok i informuje, że klucz i tryb są poprawne, a problemem jest IV — albo że pierwsze 16 bajtów szyfrogramu to właśnie IV.

Jak korzystać z narzędzia do szyfrowania i odszyfrowania SM4

  1. 1

    Wybierz ustawienia biblioteki albo tryb i dopełnienie

    Jeśli wiadomo, z jakiej biblioteki korzysta druga strona, wystarczy wybrać ją w polu Domyślne ustawienia biblioteki. W przeciwnym razie wybierz Szyfruj lub Odszyfruj i dopasuj tryb oraz dopełnienie. Tryby strumieniowe (CTR, CFB, OFB) nie mają dopełnienia, więc selektor dopełnienia jest dla nich wyłączony.

  2. 2

    Wpisz klucz i IV

    Oba mają dokładnie 16 bajtów. Wybierz format, w jakim zapisano ciąg — hex, tekst lub Base64 — i sprawdź, czy licznik bajtów zmienił kolor na zielony. Przyciski Losuj generują nowe wartości.

  3. 3

    Wklej dane wejściowe

    Przy szyfrowaniu wpisz tekst (UTF-8 lub GBK) albo wklej bajty w hex. Przy odszyfrowaniu wklej szyfrogram i wskaż, czy jest zapisany w Base64, czy w hex. Wynik aktualizuje się w trakcie pisania.

  4. 4

    Skopiuj wynik albo sprawdź szyfrowanie w obie strony

    Skopiuj wynik albo kliknij Odszyfruj ten szyfrogram, aby przenieść go do odszyfrowania z tym samym kluczem i IV. Panel OpenSSL pokazuje polecenie, które odtwarza wynik.

  5. 5

    Gdy odszyfrowanie zawodzi, przeczytaj diagnozę

    Diagnoza wymienia ustawienia, przy których dane wejściowe dają czytelny tekst. Każde z nich można zastosować jednym kliknięciem; jeśli zawodzi tylko pierwsze 16 bajtów, warto przeczytać uwagę — wskazuje ona na IV.

Dlaczego odszyfrowanie SM4 zawodzi

Odczytanie klucza hex jako tekstu

32-znakowy ciąg szesnastkowy ma 16 bajtów tylko wtedy, gdy zostanie odczytany jako hex. Odczytany jako tekst ma 32 bajty, które SM4 odrzuca — albo, w kodzie po cichu obcinającym lub dopełniającym klucze, staje się zupełnie innym kluczem.

✗ Niepoprawne 
Klucz (tekst): 0123456789abcdeffedcba9876543210  -> 32 bajty, odrzucony
✓ Poprawne 
Klucz (hex):   0123456789abcdeffedcba9876543210  -> 16 bajtów

Odszyfrowywanie szyfrogramu CBC jako ECB

Obie strony muszą używać tego samego trybu. Szyfrogram CBC odszyfrowany jako ECB daje śmieci w każdym bloku i zwykle nie przechodzi kontroli dopełnienia na końcu.

✗ Niepoprawne 
szyfrowanie:   SM4/CBC/PKCS5Padding
odszyfrowanie: SM4/ECB/PKCS5Padding  -> bad decrypt
✓ Poprawne 
szyfrowanie:   SM4/CBC/PKCS5Padding
odszyfrowanie: SM4/CBC/PKCS5Padding, ten sam IV

Użycie innego IV

W CBC błędny IV nie wywołuje błędu: pierwsze 16 bajtów wychodzi zniekształcone, a reszta odszyfrowuje się normalnie. Jeśli uszkodzony jest tylko początek tekstu jawnego, warto porównać IV po obu stronach.

✗ Niepoprawne 
IV przy odszyfrowaniu: 00000000000000000000000000000000
-> 16 bajtów śmieci + ": order 20260911-0042"
✓ Poprawne 
IV przy odszyfrowaniu: fedcba98765432100123456789abcdef
-> "SM4 interop test: order 20260911-0042"

Traktowanie szyfrogramu Base64 jako hex

Base64 i hex to dwa sposoby zapisu tych samych bajtów. Odczytanie jednego jako drugiego od samego początku przekazuje szyfrowi błędne dane wejściowe.

✗ Niepoprawne 
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  odczytany jako hex -> nieprawidłowy
✓ Poprawne 
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  odczytany jako Base64 -> 48 bajtów

Dopełnienie zerami usuwa prawdziwe końcowe zera

Dopełnienie zerami nie odróżnia dopełnienia od danych, więc tekst jawny, który naprawdę kończy się bajtami 0x00, traci je. Do wszystkiego, co nie jest zwykłym tekstem, lepiej używać PKCS#7.

✗ Niepoprawne 
dopełnienie zerami: 61 62 00  -> po odszyfrowaniu 61 62
✓ Poprawne 
PKCS#7:             61 62 00  -> po odszyfrowaniu 61 62 00

Założenie, że „SM4” wszędzie oznacza ten sam tryb

OpenSSL traktuje sm4 jako CBC. BouncyCastle — a więc także SmUtil.sm4(key) z Hutool — traktuje SM4 jako ECB z PKCS#7. Dwa systemy, które „po prostu używają SM4”, mogą różnić się trybem.

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

Bajty GBK po jednej stronie, UTF-8 po drugiej

getBytes() w Javie bez podania zestawu znaków używa domyślnego kodowania platformy, którym w chińskiej wersji Windows z JDK 17 lub starszym jest GBK. Ten sam chiński tekst daje wtedy inny szyfrogram, a druga strona odszyfrowuje go do nieczytelnych „krzaczków”.

✗ Niepoprawne 
"国密SM4 test".getBytes()  // GBK w chińskiej wersji Windows, JDK <= 17
-> szyfrogram ECB 3188d06cf28db70092f8753cbd5ee518
✓ Poprawne 
"国密SM4 test".getBytes(StandardCharsets.UTF_8)
-> szyfrogram ECB d830308b0ae4fa7b9a2b5d59f7f65ca5

Kiedy przydaje się szyfrowanie SM4 online

Zgodność wyników SM4 między backendem a frontendem
Usługa w Javie i klient webowy zwracają różne szyfrogramy dla tego samego tekstu. Wystarczy odtworzyć tu każdą ze stron z ustawieniami jej biblioteki, aby zobaczyć, który parametr się różni.
Debugowanie nieudanego odszyfrowania z systemu partnera
Partner przesyła szyfrogram SM4, którego nie da się odszyfrować. Wystarczy wkleić go z uzgodnionym kluczem i IV, a diagnoza ustali, jakiego trybu, dopełnienia lub kodowania faktycznie użyto.
Weryfikacja implementacji SM4
Własny kod warto sprawdzić na wektorach GB/T 32907 z tej strony, a potem porównać szyfrowanie i odszyfrowanie w CBC, zanim implementacja choćby zbliży się do danych produkcyjnych.
Dane testowe do migracji na SM4
Gdy system przechodzi z AES na SM4, można tu wygenerować znane zestawy klucza, IV i szyfrogramu i użyć ich jako danych wzorcowych w nowych testach.
Obserwacja działania trybów szyfru blokowego
Zaszyfruj dwa identyczne bloki w ECB i CBC albo odszyfruj dane z błędnym IV i zobacz, co zmienia się w szyfrogramie i w wyniku.

Jak działa SM4 i jego tryby pracy

Rozmiar bloku, długość klucza i liczba rund
SM4 szyfruje 128-bitowe bloki 128-bitowym kluczem w 32 rundach. Każda runda stosuje 8-bitowy S-box do 32-bitowego słowa, a potem przekształcenie liniowe, które łączy słowo operacją XOR z czterema jego rotacjami. Odszyfrowanie wykonuje te same 32 rundy z kluczami rund w odwrotnej kolejności.
ECB: każdy blok osobno
ECB szyfruje każdy 16-bajtowy blok niezależnie. Nie potrzebuje IV, ale jednakowe bloki tekstu jawnego stają się jednakowymi blokami szyfrogramu, więc wzorce w danych pozostają widoczne. Wymaga dopełnienia, chyba że dane wejściowe są wielokrotnością 16 bajtów.
CBC: bloki w łańcuchu i IV
CBC przed zaszyfrowaniem łączy każdy blok tekstu jawnego operacją XOR z poprzednim blokiem szyfrogramu, a dla pierwszego bloku używa IV. Ponieważ IV wpływa tylko na pierwszy blok, błędny IV psuje dokładnie pierwsze 16 bajtów tekstu jawnego i nie narusza dopełnienia w ostatnim bloku, więc często nie pojawia się żaden błąd.
CTR, CFB i OFB: SM4 jako szyfr strumieniowy
Te tryby szyfrują licznik lub wartość sprzężenia zwrotnego i łączą wynik z danymi operacją XOR, więc szyfrogram jest tak długi jak tekst jawny i nie ma dopełnienia. W CTR cały 16-bajtowy IV jest zwiększany jako jeden 128-bitowy licznik big-endian, zgodnie z OpenSSL. Błędny IV psuje całą wiadomość w CTR i OFB, ale w CFB tylko pierwszy blok.
Zasady dopełnienia
PKCS#7 dodaje od 1 do 16 bajtów o wartości n, więc wiadomość, która już składa się z pełnych bloków, i tak dostaje pełny blok dopełnienia. Dopełnienie zerami dodaje bajty 0x00 tylko wtedy, gdy to konieczne, i przy odszyfrowaniu usuwa wszystkie końcowe zera. Brak dopełnienia pozostawia dane bez zmian i odrzuca dane wejściowe, które nie wypełniają pełnych bloków.

Najlepsze praktyki szyfrowania SM4

Nie wybieraj ECB w nowych projektach
ECB zdradza, które bloki są jednakowe. Lepiej używać CBC lub CTR, chyba że trzeba dopasować się do istniejącego systemu, który już korzysta z ECB.
Nowy losowy IV dla każdej wiadomości
IV nie jest tajny, ale nie może się powtarzać przy tym samym kluczu. Należy generować go losowo dla każdej wiadomości i przechowywać lub przesyłać obok szyfrogramu.
Uwierzytelniaj szyfrogram
GB/T 17964-2021, chińska norma dotycząca trybów pracy szyfrów blokowych, stwierdza, że opisane w niej tryby chronią poufność, a nie integralność. W CBC zmiana jednego bajtu IV zamienia pay=100.00 w pay=900.00, a odszyfrowanie nadal się udaje. Warto obliczyć MAC z IV i szyfrogramu i sprawdzić go przed odszyfrowaniem, na przykład za pomocą generatora HMAC.
Zapisz każdy parametr w specyfikacji interfejsu
„Zaszyfrowane SM4” to jeszcze nie specyfikacja. Trzeba zapisać tryb, dopełnienie, sposób kodowania klucza i IV, zestaw znaków tekstu jawnego oraz to, czy szyfrogram jest w hex, czy w Base64.
Prawdziwe klucze poza stronami internetowymi i kodem źródłowym
Tej strony najlepiej używać z kluczami testowymi. Klucze produkcyjne należą do systemu zarządzania kluczami lub sprzętowego modułu bezpieczeństwa (HSM) i powinny być ładowane w czasie działania, a nie wklejane ani zapisywane w repozytorium.

FAQ dotyczące szyfrowania SM4

Dlaczego odszyfrowanie SM4 kończy się błędem dopełnienia lub daje nieczytelny tekst?
Odszyfrowanie działa tylko wtedy, gdy wszystko zgadza się ze stroną szyfrującą: bajty klucza, tryb, IV, dopełnienie oraz sposób zapisu szyfrogramu (hex lub Base64). Otrzymany błąd — „bad decrypt”, wyjątek dopełnienia albo ekran pełen śmieci — nie mówi, który element się nie zgadza, a niektóre biblioteki zamiast błędu zwracają po prostu pusty wynik. Mimo to warto wkleić tutaj szyfrogram, klucz i IV. Gdy odszyfrowanie się nie powiedzie, strona sprawdza każdą kombinację kodowania szyfrogramu, formatu klucza, trybu, IV i dopełnienia — łącznie z kluczami, które biblioteka po cichu obcięła do 16 bajtów, i tekstem jawnym zakodowanym w GBK — po czym wyświetla warianty dające czytelny tekst i oznacza te, w których dopełnienie PKCS#7 okazało się poprawne. Jeśli błędne jest tylko pierwsze 16 bajtów, klucz i tryb są dobre, a zawodzi IV.
Jak długi jest klucz SM4 i czy może mieć 256 bitów?
Klucz SM4 ma dokładnie 128 bitów, czyli 16 bajtów — tyle samo co blok. GB/T 32907 definiuje tylko tę jedną długość klucza; nie istnieje 192- ani 256-bitowy SM4. Jeśli ktoś żąda 256-bitowego klucza SM4, trzeba sprawdzić, czy 32-cyfrowy ciąg szesnastkowy nie został policzony jako 32 znaki po 8 bitów każdy. Szesnaście bajtów można zapisać jako 32 cyfry szesnastkowe albo jako 16 znaków ASCII, a pomylenie tych dwóch zapisów to najczęstszy błąd klucza: 0123456789abcdeffedcba9876543210 odczytany jako hex ma 16 bajtów, ale ten sam ciąg odczytany jako tekst ma 32 bajty i zostaje odrzucony. Selektor formatu i licznik bajtów obok pola klucza służą właśnie do wychwycenia tej pomyłki.
Czym jest IV w SM4 i jaką musi mieć długość?
IV (wektor inicjujący) to 16-bajtowa wartość mieszana z pierwszym blokiem w trybach CBC, CTR, CFB i OFB; ECB go nie używa. Musi mieć dokładnie 16 bajtów — 32 cyfry szesnastkowe lub 16 znaków ASCII — więc przy błędzie długości IV warto sprawdzić, czy 32-cyfrowy ciąg szesnastkowy nie został odczytany jako 32 bajty tekstu. IV nie jest tajny, ale nie może się powtarzać przy tym samym kluczu: najlepiej generować go losowo i przesyłać razem z szyfrogramem, często na jego początku. Błędny IV w CBC zwykle nie wywołuje błędu i psuje tylko pierwsze 16 bajtów. Niektóre biblioteki, gdy IV nie zostanie podany, po cichu używają IV złożonego z samych zer (sm-crypto-v2, tjfoc/gmsm w Go), a BouncyCastle w Javie generuje losowy — jeśli ten IV nie zostanie zapisany razem z szyfrogramem, nikt już go nie odszyfruje.
Czym różni się SM4 w trybie ECB od CBC i którego użyć?
Najlepiej używać CBC (lub CTR) z nowym losowym IV dla każdej wiadomości. ECB szyfruje jednakowe 16-bajtowe bloki do jednakowych bloków szyfrogramu, więc powtarzalna struktura danych prześwituje przez szyfrogram. Po ECB warto sięgać tylko wtedy, gdy trzeba współpracować z systemem, który już go używa. Żaden z tych trybów nie wykrywa manipulacji: jeśli to ważne, należy dołączyć także MAC obliczony z IV i szyfrogramu, na przykład za pomocą generatora HMAC.
Jakie dopełnienie wybrać w SM4: PKCS5Padding, PKCS#7, dopełnienie zerami czy brak dopełnienia?
PKCS#7 zawsze dodaje od 1 do 16 bajtów, z których każdy zawiera liczbę dodanych bajtów, dzięki czemu odbiorca może je jednoznacznie usunąć. W 16-bajtowym szyfrze blokowym takim jak SM4 PKCS5Padding z Javy to dokładnie to samo dopełnienie — BouncyCastle obsługuje obie nazwy tą samą ścieżką kodu. Dopełnienie zerami dokłada bajty 0x00 tylko do najbliższej granicy bloku. Przy odszyfrowaniu Hutool i BouncyCastle usuwają wszystkie końcowe bajty 0x00, łącznie z zerami, które naprawdę były częścią danych, a gmssl w Pythonie usuwa tylko jeden. Brak dopełnienia wymaga, by dane wejściowe składały się z pełnych 16-bajtowych bloków. CTR, CFB i OFB to tryby strumieniowe i nigdy nie stosują dopełnienia. Jeśli odszyfrowany tekst kończy się dziwnymi spacjami, prostokątami lub znakami nowej linii, dopełnienie nie zostało usunięte: dane z PKCS#7 odszyfrowane bez dopełnienia zachowują na końcu n bajtów o wartości n (0x09, 0x0A i 0x0D wyglądają jak tabulatory i łamania wierszy); wystarczy przełączyć wynik na Hex i obejrzeć ostatni blok.
Jak długi jest szyfrogram SM4 i czy można z niego odczytać tryb?
Długość liczy się w bajtach. Z PKCS#7 w ECB lub CBC tekst jawny jest zaokrąglany w górę do najbliższej wielokrotności 16, a wiadomość, która już jest wielokrotnością 16, dostaje jeszcze jeden pełny blok — 5 lub 15 bajtów zamienia się w 16, a 16 bajtów w 32. Dopełnienie zerami uzupełnia tylko do najbliższej wielokrotności 16, brak dopełnienia zachowuje długość, a szyfrogram CTR, CFB i OFB jest dokładnie tak długi jak tekst jawny. Hex podwaja liczbę bajtów; Base64 zajmuje 4 × ⌈liczba bajtów / 3⌉ znaków, więc 16 bajtów to 24 znaki, 32 to 44, a 64 to 88. Jeśli IV jest przesyłany na początku, dochodzi jeszcze 16 bajtów. Sam szyfrogram nie zdradza trybu, ale pomagają dwie wskazówki: długość, która nie jest wielokrotnością 16, praktycznie wyklucza ECB lub CBC z dopełnieniem, a dwa identyczne 16-bajtowe bloki wskazują na ECB. W razie wątpliwości wystarczy wkleić szyfrogram po przełączeniu na Odszyfruj, a automatyczna diagnoza sama sprawdzi tryby.
Czy SM4 daje za każdym razem ten sam szyfrogram i dlaczego inne narzędzie zwraca inny?
ECB — albo dowolny tryb ze stałym IV — daje za każdym razem ten sam szyfrogram dla tego samego klucza i tekstu jawnego; przy nowym losowym IV wynik zmienia się przy każdym uruchomieniu i tak właśnie powinno być. Poza tym warto porównać tryb, dopełnienie, to, czy klucz został odczytany jako hex, czy jako tekst, sposób zakodowania tekstu jawnego — w większości kodu UTF-8, ale GBK, gdy starszy kod w Javie wywołuje getBytes() w chińskiej wersji Windows — oraz sposób zapisu wyniku: Base64, hex małymi literami lub hex wielkimi literami. Przy identycznych ustawieniach i stałym IV dwie poprawne implementacje dają identyczny wynik. Jeśli któreś z narzędzi budzi podejrzenia, najpierw należy sprawdzić oba na wektorze testowym GB/T 32907.
Jak sprawdzić, czy własna implementacja SM4 jest poprawna?
Najlepiej zacząć od dwóch wektorów z załącznika A normy GB/T 32907-2016. Gdy klucz i tekst jawny mają wartość 0123456789abcdeffedcba9876543210, jedno szyfrowanie musi dać 681edf34d206965e86b3e94f536e4246, a milion szyfrowań w łańcuchu — 595298c7c6fd271f0402f804c33d3f66. Sprawdzają one wyłącznie sam szyfr blokowy, więc w drugim kroku warto zaszyfrować jakiś tekst w CBC ze stałym kluczem i IV i porównać wynik z tą stroną albo z pokazanym na niej poleceniem OpenSSL. Silnik tej strony jest testowany na obu wektorach oraz porównywany z OpenSSL 3 we wszystkich pięciu trybach.
Czy OpenSSL potrafi szyfrować i odszyfrowywać SM4?
Tak. OpenSSL 3 obsługuje SM4 w trybach ECB, CBC, CFB, OFB i CTR. Służy do tego openssl enc -sm4-cbc -K <32 hex digits> -iv <32 hex digits>: -K przyjmuje surowy klucz w hex, więc żadne hasło nie bierze w tym udziału, -nopad wyłącza PKCS#7, a -base64 -A odczytuje lub zapisuje Base64 w jednym wierszu. Trzeba uważać na dwie rzeczy: samo -sm4 oznacza CBC, a wartość -K o złej długości jest obcinana lub dopełniana zerami, przy czym OpenSSL wyświetla jedynie ostrzeżenie. Panel OpenSSL na tej stronie buduje polecenie z bieżących ustawień; openssl enc nie obsługuje dopełnienia zerami, więc panel o tym informuje, zamiast wypisywać polecenie, które dałoby inny wynik.
Jak odszyfrować szyfrogram SM4 z Javy (Hutool) lub JavaScriptu (sm-crypto)?
Najpierw trzeba ustalić, jakiego trybu i dopełnienia naprawdę używa druga strona — kod często wcale tego nie mówi. SmUtil.sm4(key) z Hutool przekazuje tylko nazwę SM4, a BouncyCastle uzupełnia ją do ECB z PKCS#7 (PKCS5Padding w Javie); CBC oznacza dopiero pełny ciąg, taki jak SM4/CBC/PKCS5Padding. W JavaScripcie sm-crypto również domyślnie używa ECB, przyjmuje klucz jako 32-cyfrowy ciąg szesnastkowy i zwraca hex małymi literami, natomiast gm-crypt domyślnie używa CBC, przyjmuje 16-znakowy klucz tekstowy i zwraca Base64. Następnie trzeba sprawdzić zestaw znaków tekstu jawnego: metody tekstowe Hutool zawsze używają UTF-8, ale gołe getBytes() w JDK 17 lub starszym w chińskiej wersji Windows może oznaczać GBK, co zmienia szyfrogram. Wybranie biblioteki w polu Domyślne ustawienia biblioteki ustawia to wszystko jednym kliknięciem; można też wprowadzić wartości ręcznie. Jeśli któraś z nich jest niepewna, i tak warto wkleić szyfrogram — automatyczna diagnoza sprawdzi kombinacje trybu, dopełnienia, IV i kodowania.
Czy SM4 jest bezpieczny i czy dane są gdzieś wysyłane?
Jako algorytm SM4 używa 128-bitowego klucza i 32 rund; RFC 8998 (2021) stwierdza, że w chwili pisania dokumentu nie były znane żadne słabe klucze ani problemy z bezpieczeństwem SM4. Praktyczne ryzyko wynika ze sposobu użycia: ECB ujawnia wzorce, a CBC nie wykrywa manipulacji. Co do tej strony — nic nie jest wysyłane. Przeglądarki nie mają wbudowanego SM4, więc strona zawiera własną implementację SM4 i uruchamia ją lokalnie; można otworzyć panel sieci i zobaczyć, że nie wychodzi żadne żądanie, albo odłączyć internet i dalej korzystać z narzędzia. Dzięki temu nadaje się do danych testowych, debugowania i nauki. Nie czyni to jednak strony internetowej właściwym miejscem dla kluczy produkcyjnych: te należą do systemu zarządzania kluczami lub modułu sprzętowego, a nie do pola tekstowego na jakiejkolwiek stronie.
Czym różni się SM4 od AES?
Oba są szyframi blokowymi o 128-bitowym bloku, a tryby i dopełnienie działają w nich tak samo — dlatego błędy zgodności SM4 wyglądają dokładnie jak błędy AES. SM4 wykonuje 32 rundy i ma jedną długość klucza, 128 bitów; AES-128 wykonuje 10 rund, a AES ma też klucze 192- i 256-bitowe. SM4 to chińska norma krajowa GB/T 32907-2016, a od 2021 roku także część międzynarodowej normy ISO/IEC 18033-3, obok AES; stosuje się go tam, gdzie wymagana jest chińska kryptografia komercyjna. AES to norma NIST FIPS 197. Do AES służy narzędzie do szyfrowania AES.

Powiązane narzędzia

Zobacz wszystkie narzędzia →

Narzędzie do odszyfrowywania AES — OpenSSL i CryptoJS

Narzędzia bezpieczeństwa

Odszyfruj AES online — GCM/CBC/CTR, hasło lub klucz surowy, automatyczne wykrywanie formatu OpenSSL i CryptoJS „U2FsdGVkX1”. 100% w przeglądarce, klucze nigdy jej nie opuszczają.

Narzędzie do szyfrowania AES — GCM, CBC i CTR

Narzędzia bezpieczeństwa

Darmowe szyfrowanie AES online — AES-128/192/256, GCM/CBC/CTR, hasło (PBKDF2) lub klucz surowy. Działa w 100% w przeglądarce; nic nie jest przesyłane.

Generator i weryfikator skrótów bcrypt

Narzędzia bezpieczeństwa

Generuj i weryfikuj skróty bcrypt haseł online — regulowany koszt, prefiksy $2b$/$2a$/$2y$. W 100% w przeglądarce; Twoje hasło nigdy nie jest wysyłane.

Kalkulator sumy kontrolnej CRC

Narzędzia bezpieczeństwa

Wklej hex albo tekst i policz naraz wszystkie 63 warianty CRC-8, CRC-16 i CRC-32. Suma kontrolna z urządzenia się nie zgadza? Wpisz ją, a narzędzie wskaże wariant: MODBUS, CCITT-FALSE, XMODEM, KERMIT. Wszystko lokalnie.

Generator HMAC i weryfikator podpisów

Narzędzia bezpieczeństwa

Darmowy generator i weryfikator HMAC online. Oblicz HMAC-SHA256/SHA1/SHA384/SHA512 z kluczem Tekst, Hex lub Base64 i wynikiem Hex/Base64/Base64URL. 100% w Twojej przeglądarce — klucze nigdy nie opuszczają strony.

Dekoder JWT

Narzędzia bezpieczeństwa

Dekoduj JWT online darmowym dekoderem JWT. Sprawdź header, payload, signature, claims i wygaśnięcie. W 100% w przeglądarce — token nie opuszcza urządzenia.