Skip to content

Enkripsi & Dekripsi SM4 Online

Enkripsi & dekripsi SM4 online. Dekripsi gagal? Alat ini mencari apakah mode, padding, IV, atau encoding yang salah dan memberi perbaikannya. Berjalan di browser, tanpa unggahan. ECB/CBC/CTR/CFB/OFB; PKCS#7, zero, tanpa padding.

Tanpa Pelacakan Berjalan di Browser Gratis
Enkripsi berjalan sepenuhnya di browser Anda — kunci dan data yang Anda masukkan tidak pernah meninggalkan perangkat ini.
Ciphertext
Perintah OpenSSL yang setara 
—

Memerlukan OpenSSL 3. Perintah ini memuat kunci yang Anda masukkan.

Vektor uji SM4 dari GB/T 32907-2016

Dihitung saat build oleh mesin yang dijalankan halaman ini — cocokkan implementasi SM4 Anda sendiri dengan nilai-nilai ini.
Kunci 0123456789abcdeffedcba9876543210
Plaintext 0123456789abcdeffedcba9876543210
Ciphertext, 1 kali enkripsi 681edf34d206965e86b3e94f536e4246
Ciphertext, 1.000.000 kali enkripsi 595298c7c6fd271f0402f804c33d3f66
Mesin SM4 diuji terhadap kedua vektor Lampiran A GB/T 32907-2016 dan dicocokkan silang dengan OpenSSL 3 dalam ECB, CBC, CTR, CFB, dan OFB. Default library diperiksa dengan menjalankan OpenSSL, Node.js, sm-crypto, gm-crypt, gmssl, dan dua library Go, serta dengan membaca source code Hutool dan BouncyCastle. — Tim Keamanan Go Tools · Sep 11, 2026

Ditulis dan ditinjau oleh developer yang membangun alat kriptografi. Setiap ciphertext dan jumlah byte yang dikutip di halaman ini dihitung oleh mesin alat ini dan diperiksa oleh pengujian otomatis.

Jawaban singkat SM4

Panjang kunci SM4

16 byte Tepat 128 bit: 16 byte, ditulis sebagai 32 digit hex atau 16 karakter ASCII. Tidak ada kunci SM4 192-bit atau 256-bit.

Vektor uji GB/T 32907

681edf34d206965e86b3e94f536e4246 Dengan kunci dan plaintext 0123456789abcdeffedcba9876543210, satu kali enkripsi menghasilkan 681edf34d206965e86b3e94f536e4246.

Ukuran blok dan jumlah ronde SM4

32 ronde Blok 16 byte (128 bit), dienkripsi dalam 32 ronde.

Apakah IV yang salah selalu memicu error pada CBC?

16 byte pertama Tidak. Hanya 16 byte pertama yang terdekripsi salah, dan padding di blok terakhir tetap lolos pemeriksaan.

Apa itu SM4?

SM4 adalah cipher blok dalam standar kriptografi komersial Tiongkok. Algoritma ini diterbitkan sebagai GM/T 0002-2012, menjadi standar nasional GB/T 32907-2016 (berlaku sejak 1 Maret 2017), dan ditambahkan ke standar internasional ISO/IEC 18033-3 melalui amandemen pada 2021. SM4 adalah cipher simetris: kunci 128-bit yang sama dipakai untuk mengenkripsi dan mendekripsi, dan cipher ini memproses blok 128-bit, 16 byte sekaligus — ukuran blok yang sama dengan AES.

Di dalamnya, setiap blok dipecah menjadi empat word 32-bit dan diproses melalui 32 ronde. Setiap ronde mencampur tiga word dengan round key, melewatkan hasilnya ke S-box 8-bit dan transformasi linear, lalu menggabungkannya ke word keempat. Ke-32 round key diturunkan dari kunci dengan dua set konstanta tetap, dan dekripsi adalah perhitungan yang sama dengan urutan round key dibalik.

Cipher blok saja hanya bisa menangani tepat 16 byte, jadi data sungguhan selalu melewati sebuah mode operasi. Alat ini menyediakan lima mode klasik: ECB dan CBC, yang bekerja pada blok utuh dan memerlukan padding, serta CTR, CFB, dan OFB, yang mengubah SM4 menjadi cipher stream tanpa padding sama sekali. Sebagian besar dekripsi yang gagal tidak ada hubungannya dengan SM4 itu sendiri — penyebabnya adalah kedua sisi tidak sepakat soal mode, padding, IV, encoding teks, atau cara string kunci diubah menjadi byte, dan library bahkan tidak sepakat soal arti "SM4" tanpa keterangan tambahan.

Web Crypto API bawaan browser tidak menyertakan SM4, jadi halaman ini membawa implementasinya sendiri dan menjalankannya secara lokal. Implementasi ini diuji terhadap dua vektor uji GB/T 32907 dan dicocokkan silang dengan OpenSSL 3 di setiap 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

Fitur alat SM4

Memberi tahu mengapa dekripsi gagal

Saat dekripsi gagal, halaman ini mencoba ulang encoding ciphertext, format kunci, mode, IV, padding, dan encoding teks, lalu menampilkan pengaturan yang menghasilkan teks terbaca.

Preset untuk library yang paling sering jadi biang masalah

Satu klik mengatur default OpenSSL, Hutool, sm-crypto, gm-crypt, atau tjfoc/gmsm — library yang bahkan tidak sepakat apakah "SM4" saja berarti ECB atau CBC.

Lima mode, tiga padding, UTF-8 atau GBK

ECB, CBC, CTR, CFB, dan OFB dengan PKCS#7, zero padding, atau tanpa padding. Plaintext bisa UTF-8 atau GBK, encoding yang dihasilkan kode Java lama di Windows berbahasa Tionghoa. GCM tidak didukung.

Kunci dan IV SM4: acak, atau sebagai hex, teks, atau Base64

Buat kunci atau IV 16-byte acak dengan satu klik, atau masukkan persis seperti yang ditulis kode Anda. Penghitung byte langsung memastikan Anda punya tepat 16 byte sebelum mulai memburu penyebab lain.

Vektor uji GB/T 32907 langsung di halaman

Kedua hasil Lampiran A tercantum dalam tabel dan bisa dimuat dengan satu klik, sehingga Anda bisa memeriksa implementasi SM4 apa pun terhadap standarnya.

Perintah OpenSSL yang setara

Setiap hasil disertai perintah openssl enc yang mereproduksinya, sehingga Anda bisa memastikannya di terminal atau membagikannya ke rekan kerja.

Berjalan sepenuhnya di browser Anda

Mesin SM4 berjalan secara lokal. Kunci dan data tidak pernah meninggalkan halaman, dan alat ini tetap bekerja secara offline.

Default SM4 di library populer

OpenSSL 3 (openssl enc)

-sm4 = CBC

-sm4 adalah alias dari -sm4-cbc. -K dan -iv menerima hex, PKCS#7 tetap aktif kecuali Anda memberi -nopad, dan output berupa byte mentah kecuali Anda menambahkan -base64 -A. Nilai -K dengan panjang yang salah dipotong atau diisi nol dengan hanya sebuah peringatan.

Java: Hutool SmUtil.sm4(key)

ECB · PKCS#7

Hutool meneruskan SM4 saja, yang dijalankan BouncyCastle sebagai ECB dengan PKCS#7 (JCE menyebutnya PKCS5Padding). Method string memakai UTF-8 dan encryptHex mencetak hex huruf kecil. Untuk CBC, gunakan new SM4(Mode.CBC, Padding.PKCS5Padding, key, iv).

Java: BouncyCastle Cipher.getInstance("SM4")

ECB · PKCS#7

Pada mode yang memerlukan IV tetapi tidak diberi IV, enkripsi diam-diam membuat IV acak dan dekripsi melempar no IV set when one expected — jadi ciphertext yang dienkripsi tanpa menyimpan IV tersebut tidak bisa didekripsi di mana pun.

JavaScript: sm-crypto

ECB · kunci hex

sm4.encrypt(data, key) default ke ECB dengan PKCS#7, mengharapkan kunci berupa string hex 32 digit, dan mengembalikan hex huruf kecil. Hanya mode: 'cbc' yang mengubah mode; nilai lain apa pun diam-diam tetap ECB. sm-crypto-v2 berperilaku sama, tetapi memakai IV serba nol jika CBC tidak diberi iv.

JavaScript: gm-crypt

CBC · kunci teks · Base64

Default ke CBC, menerima kunci dan IV berupa string UTF-8 16 karakter, dan mengembalikan Base64. Kunci yang byte-nya bukan UTF-8 valid sama sekali tidak bisa diberikan ke library ini.

Python: gmssl CryptSM4

PKCS#7 · kunci dipotong ke 16 byte

Anda memilih mode dengan memanggil crypt_ecb atau crypt_cbc. set_key hanya membaca 16 byte pertama, jadi kunci yang lebih panjang diam-diam terpotong, dan kunci yang salah biasanya mengembalikan byte kosong alih-alih error.

Go: tjfoc/gmsm sm4

IV nol secara default

Sm4Cbc memakai IV tingkat package yang tetap serba nol sampai SetIV dipanggil, memberi padding PKCS#7 bahkan pada CFB dan OFB, dan mengabaikan error unpadding — kunci yang salah mengembalikan nil tanpa error.

Contoh enkripsi dan dekripsi SM4

Vektor uji GB/T 32907 (ECB, tanpa padding)

Kunci 0123456789abcdeffedcba9876543210, plaintext (hex) 0123456789abcdeffedcba9876543210
681edf34d206965e86b3e94f536e4246

Ini adalah contoh 1 dari Lampiran A GB/T 32907-2016: kunci dan plaintext bernilai 128-bit yang sama, dan satu kali enkripsi menghasilkan 681edf34d206965e86b3e94f536e4246. Mengenkripsi output itu lagi dan lagi, total satu juta kali, menghasilkan 595298c7c6fd271f0402f804c33d3f66. Kedua nilai tercantum di tabel vektor uji di halaman ini, dihitung oleh mesin yang sama dengan yang sedang Anda pakai. Tombol Vektor uji GB/T 32907 memuat vektor yang pertama.

CBC dengan PKCS#7: input teks, output Base64

Kunci 0123456789abcdeffedcba9876543210, IV fedcba98765432100123456789abcdef, plaintext: SM4 interop test: order 20260911-0042
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y

Plaintext-nya berukuran 37 byte UTF-8. PKCS#7 menambahkan padding hingga 48 byte, yaitu tiga blok 16-byte, yang ditulis Base64 sebagai 64 karakter. Tombol Muat contoh mengisi persis nilai-nilai ini, dan panel OpenSSL menampilkan perintah yang menghasilkan string Base64 yang sama di terminal.

IV salah pada CBC: hanya 16 byte pertama yang rusak

Ciphertext di atas, didekripsi dengan IV 00000000000000000000000000000000
16 byte rusak, lalu ": order 20260911-0042"

CBC hanya mencampurkan IV ke blok pertama, sedangkan padding PKCS#7 berada di blok terakhir, sehingga pemeriksaan padding tetap lolos dan OpenSSL tidak memunculkan error. Halaman ini mendeteksi blok pertama yang tidak terbaca dan memberi tahu bahwa kunci dan mode sudah benar dan IV-lah masalahnya — atau bahwa 16 byte pertama ciphertext itu sendiri adalah IV.

Cara memakai alat enkripsi dan dekripsi SM4

  1. 1

    Pilih preset library, atau mode dan padding

    Jika Anda tahu library di sisi lain, pilih di Cocokkan dengan default. Jika tidak, pilih Enkripsi atau Dekripsi, lalu samakan mode dan padding. Mode stream (CTR, CFB, OFB) tidak memakai padding, jadi pemilih padding dinonaktifkan untuk mode tersebut.

  2. 2

    Masukkan kunci dan IV

    Keduanya tepat 16 byte. Pilih format penulisan string-nya — hex, teks, atau Base64 — dan pastikan penghitung byte berubah hijau. Tombol Acak membuat nilai baru.

  3. 3

    Tempelkan input

    Untuk enkripsi, ketik teks (UTF-8 atau GBK) atau tempelkan byte hex. Untuk dekripsi, tempelkan ciphertext dan tentukan apakah formatnya Base64 atau hex. Hasilnya diperbarui saat Anda mengetik.

  4. 4

    Salin hasil atau periksa round trip

    Salin output-nya, atau klik Dekripsi ciphertext ini untuk membawanya ke tab dekripsi dengan kunci dan IV yang sama. Panel OpenSSL menampilkan perintah yang mereproduksi hasilnya.

  5. 5

    Jika dekripsi gagal, baca diagnosisnya

    Diagnosis menampilkan pengaturan yang membuat input Anda terdekripsi menjadi teks terbaca. Terapkan salah satunya dengan satu klik, atau baca catatannya jika hanya 16 byte pertama yang gagal — itu menunjuk ke IV.

Mengapa dekripsi SM4 gagal

Membaca kunci hex sebagai teks

String hex 32 karakter hanya berukuran 16 byte jika di-decode sebagai hex. Jika dibaca sebagai teks, ukurannya 32 byte dan ditolak SM4 — atau, pada kode yang diam-diam memotong atau mengisi kunci, menjadi kunci yang sama sekali berbeda.

✗ Salah 
Kunci (teks): 0123456789abcdeffedcba9876543210  -> 32 byte, ditolak
✓ Benar 
Kunci (hex):  0123456789abcdeffedcba9876543210  -> 16 byte

Mendekripsi ciphertext CBC sebagai ECB

Kedua sisi harus memakai mode yang sama. Ciphertext CBC yang didekripsi sebagai ECB menghasilkan data acak di setiap blok, dan biasanya gagal pemeriksaan padding di akhir.

✗ Salah 
enkripsi: SM4/CBC/PKCS5Padding
dekripsi: SM4/ECB/PKCS5Padding  -> bad decrypt
✓ Benar 
enkripsi: SM4/CBC/PKCS5Padding
dekripsi: SM4/CBC/PKCS5Padding, IV sama

Memakai IV yang berbeda

Pada CBC, IV yang salah tidak memunculkan error: 16 byte pertama keluar rusak dan sisanya terdekripsi normal. Jika hanya awal plaintext Anda yang rusak, bandingkan IV-nya.

✗ Salah 
IV dekripsi 00000000000000000000000000000000
-> 16 byte rusak + ": order 20260911-0042"
✓ Benar 
IV dekripsi fedcba98765432100123456789abcdef
-> "SM4 interop test: order 20260911-0042"

Menganggap ciphertext Base64 sebagai hex

Base64 dan hex adalah dua cara menulis byte yang sama. Membaca yang satu sebagai yang lain membuat cipher menerima input yang salah sejak awal.

✗ Salah 
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  dibaca sebagai hex -> tidak valid
✓ Benar 
Wi6BuLpov8RndEfedUyLXFvDRnLMoo7T6O04Q83IzKDuDvPQ2S5clq+cEQXMvy/y  dibaca sebagai Base64 -> 48 byte

Zero padding menghapus byte nol asli di akhir data

Zero padding tidak bisa membedakan padding dari data, sehingga plaintext yang memang diakhiri 0x00 kehilangan byte tersebut. Gunakan PKCS#7 untuk apa pun yang bukan teks biasa.

✗ Salah 
zero padding: 61 62 00  -> terdekripsi menjadi 61 62
✓ Benar 
PKCS#7:       61 62 00  -> terdekripsi menjadi 61 62 00

Mengira "SM4" berarti mode yang sama di mana-mana

OpenSSL memperlakukan sm4 sebagai CBC. BouncyCastle — dan karena itu juga SmUtil.sm4(key) milik Hutool — memperlakukan SM4 sebagai ECB dengan PKCS#7. Dua sistem yang sama-sama "cukup pakai SM4" bisa berbeda mode.

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

Mengenkripsi byte GBK di satu sisi dan UTF-8 di sisi lain

getBytes() di Java tanpa charset memakai default platform, yaitu GBK pada JDK 17 atau lebih lama di Windows berbahasa Tionghoa. Teks Tionghoa yang sama lalu terenkripsi menjadi ciphertext yang berbeda, dan sisi lain mendekripsinya menjadi mojibake.

✗ Salah 
"国密SM4 test".getBytes()  // GBK di Windows berbahasa Tionghoa, JDK <= 17
-> ciphertext ECB 3188d06cf28db70092f8753cbd5ee518
✓ Benar 
"国密SM4 test".getBytes(StandardCharsets.UTF_8)
-> ciphertext ECB d830308b0ae4fa7b9a2b5d59f7f65ca5

Kapan Anda butuh enkripsi SM4 online

Samakan output SM4 antara backend dan frontend
Layanan Java dan klien web Anda menghasilkan ciphertext berbeda untuk teks yang sama. Reproduksi masing-masing sisi di sini dengan preset library-nya dan lihat parameter mana yang berbeda.
Debug dekripsi yang gagal dari sistem mitra
Mitra mengirim ciphertext SM4 yang tidak bisa didekripsi. Tempelkan bersama kunci dan IV yang disepakati, lalu biarkan diagnosis menemukan mode, padding, atau encoding yang sebenarnya mereka pakai.
Verifikasi implementasi SM4
Jalankan kode Anda terhadap vektor GB/T 32907 di halaman ini, lalu bandingkan round trip CBC, sebelum implementasinya menyentuh data produksi.
Siapkan data uji untuk migrasi ke SM4
Saat sebuah sistem beralih dari AES ke SM4, buat trio kunci, IV, dan ciphertext yang sudah diketahui di sini untuk dipakai sebagai fixture dalam pengujian baru.
Pahami perilaku mode cipher blok
Enkripsi dua blok identik dalam ECB dan CBC, atau dekripsi dengan IV yang salah, lalu amati apa yang berubah pada ciphertext dan output-nya.

Cara kerja SM4 dan mode-modenya

Ukuran blok, ukuran kunci, dan ronde
SM4 mengenkripsi blok 128-bit dengan kunci 128-bit dalam 32 ronde. Setiap ronde menerapkan S-box 8-bit pada word 32-bit, lalu transformasi linear yang meng-XOR word tersebut dengan empat rotasi dirinya sendiri. Dekripsi menjalankan 32 ronde yang sama dengan urutan round key dibalik.
ECB: setiap blok berdiri sendiri
ECB mengenkripsi setiap blok 16-byte secara independen. Mode ini tidak memerlukan IV, tetapi blok plaintext yang sama menjadi blok ciphertext yang sama, sehingga pola dalam data tetap terlihat. ECB memerlukan padding kecuali input berupa kelipatan 16 byte.
CBC: blok berantai dan IV
CBC meng-XOR setiap blok plaintext dengan blok ciphertext sebelumnya sebelum dienkripsi, dan memakai IV untuk blok pertama. Karena IV hanya masuk ke blok pertama, IV yang salah merusak tepat 16 byte pertama plaintext dan membiarkan padding di blok terakhir tetap utuh, sehingga sering kali tidak ada error sama sekali.
CTR, CFB, dan OFB: SM4 sebagai cipher stream
Mode-mode ini mengenkripsi nilai counter atau feedback lalu meng-XOR hasilnya dengan data, sehingga ciphertext sama panjangnya dengan plaintext dan tidak ada padding. Pada CTR, seluruh IV 16-byte dinaikkan sebagai satu counter big-endian 128-bit, sama seperti OpenSSL. IV yang salah merusak seluruh pesan pada CTR dan OFB, tetapi hanya blok pertama pada CFB.
Aturan padding
PKCS#7 menambahkan 1 hingga 16 byte bernilai n, sehingga pesan yang sudah berupa kelipatan utuh blok tetap mendapat satu blok padding penuh. Zero padding menambahkan byte 0x00 hanya bila diperlukan dan membuang semua nol di akhir saat dekripsi. Tanpa padding, data dibiarkan apa adanya dan input yang tidak mengisi blok utuh ditolak.

Praktik terbaik enkripsi SM4

Jangan pilih ECB untuk desain baru
ECB membocorkan blok mana saja yang sama. Gunakan CBC atau CTR, kecuali Anda perlu menyamai sistem yang sudah memakai ECB.
Gunakan IV acak baru untuk setiap pesan
IV tidak rahasia, tetapi tidak boleh berulang dengan kunci yang sama. Buat secara acak untuk setiap pesan dan simpan atau kirim bersama ciphertext.
Autentikasi ciphertext
GB/T 17964-2021, standar Tiongkok tentang mode cipher blok, menyatakan bahwa mode yang dijelaskannya melindungi kerahasiaan, bukan integritas. Pada CBC, mengubah satu byte IV bisa mengubah pay=100.00 menjadi pay=900.00 dan dekripsi tetap berhasil. Hitung MAC atas IV dan ciphertext lalu periksa sebelum mendekripsi, misalnya dengan generator HMAC.
Tulis setiap parameter di spesifikasi antarmuka
"Dienkripsi dengan SM4" bukanlah spesifikasi. Tuliskan mode, padding, cara kunci dan IV di-encode, charset plaintext, dan apakah ciphertext berupa hex atau Base64.
Jauhkan kunci asli dari halaman web dan source code
Gunakan halaman ini dengan kunci uji. Kunci produksi seharusnya berada di sistem manajemen kunci atau hardware security module, dimuat saat runtime, bukan ditempel atau di-commit.

FAQ enkripsi SM4

Mengapa dekripsi SM4 saya gagal dengan error padding atau teks acak?
Dekripsi hanya berhasil jika semuanya sama dengan sisi yang mengenkripsi: byte kunci, mode, IV, padding, dan cara ciphertext dituliskan (hex atau Base64). Error yang Anda dapat — "bad decrypt", exception padding, atau layar penuh karakter acak — tidak menyebutkan mana yang keliru, dan beberapa library malah mengembalikan output kosong tanpa error apa pun. Tetap tempelkan ciphertext, kunci, dan IV di sini. Saat dekripsi gagal, halaman ini mencoba ulang setiap kombinasi encoding ciphertext, format kunci, mode, IV, dan padding — termasuk kunci yang diam-diam dipotong library menjadi 16 byte dan plaintext yang di-encode sebagai GBK — lalu menampilkan kombinasi yang menghasilkan teks terbaca, dengan tanda pada kombinasi yang padding PKCS#7-nya lolos pemeriksaan. Jika hanya 16 byte pertama yang salah, kunci dan mode sudah benar, tetapi IV-nya tidak.
Berapa panjang kunci SM4, dan bisakah 256-bit?
Kunci SM4 tepat 128 bit, atau 16 byte — sama dengan ukuran bloknya. GB/T 32907 hanya mendefinisikan satu panjang kunci ini; tidak ada SM4 192-bit atau 256-bit. Jika ada yang meminta kunci SM4 256-bit, periksa apakah string hex 32 digit dihitung sebagai 32 karakter yang masing-masing 8 bit. Enam belas byte bisa ditulis sebagai 32 digit hex atau 16 karakter ASCII, dan tertukar di antara keduanya adalah kesalahan kunci yang paling umum: 0123456789abcdeffedcba9876543210 yang dibaca sebagai hex berukuran 16 byte, tetapi string yang sama jika dibaca sebagai teks berukuran 32 byte dan ditolak. Pemilih format dan penghitung byte di sebelah kolom kunci ada untuk menangkap persis kesalahan ini.
Apa itu IV pada SM4, dan berapa panjangnya?
IV (initialization vector, vektor inisialisasi) adalah nilai 16-byte yang dicampurkan ke blok pertama pada CBC, CTR, CFB, dan OFB; ECB tidak memakainya. Panjangnya harus tepat 16 byte — 32 digit hex atau 16 karakter ASCII — jadi jika Anda mendapat error panjang IV, periksa apakah string hex 32 digit terbaca sebagai teks 32 byte. IV tidak rahasia, tetapi tidak boleh berulang dengan kunci yang sama: buat secara acak dan kirim bersama ciphertext, sering kali diletakkan di depannya. IV yang salah pada CBC biasanya tidak memunculkan error dan hanya merusak 16 byte pertama. Beberapa library diam-diam memakai IV serba nol jika IV tidak diberikan (sm-crypto-v2, tjfoc/gmsm di Go), sementara BouncyCastle di Java membuat IV acak — jika IV itu tidak disimpan bersama ciphertext, tidak ada yang bisa mendekripsinya.
Apa beda SM4 ECB dan CBC, dan mana yang sebaiknya dipakai?
Gunakan CBC (atau CTR) dengan IV acak yang baru untuk setiap pesan. ECB mengenkripsi blok 16-byte yang sama menjadi blok ciphertext yang sama, sehingga struktur berulang dalam data ikut terlihat di ciphertext. Pilih ECB hanya untuk berkomunikasi dengan sistem yang sudah memakainya. Perlu diingat, kedua mode ini tidak mendeteksi manipulasi data: jika itu penting, kirim juga MAC atas IV dan ciphertext, misalnya dengan generator HMAC.
Padding SM4 mana yang sebaiknya dipakai: PKCS5Padding, PKCS#7, zero padding, atau tanpa padding?
PKCS#7 selalu menambahkan 1 hingga 16 byte, masing-masing berisi jumlah byte yang ditambahkan, sehingga penerima bisa membuangnya tanpa ambigu. Untuk cipher blok 16-byte seperti SM4, PKCS5Padding di Java adalah padding yang sama — BouncyCastle memproses kedua nama itu lewat jalur kode yang sama. Zero padding menambahkan 0x00 hanya sampai batas blok berikutnya. Saat dekripsi, Hutool dan BouncyCastle membuang semua 0x00 di akhir, termasuk byte nol yang sebenarnya bagian dari data, sementara gmssl di Python hanya membuang satu. Tanpa padding, input harus berupa kelipatan utuh blok 16-byte. CTR, CFB, dan OFB adalah mode stream dan tidak pernah memakai padding. Jika teks hasil dekripsi diakhiri spasi, kotak, atau baris baru yang tidak semestinya, padding-nya belum dibuang: data PKCS#7 yang didekripsi tanpa padding menyisakan n byte bernilai n di akhir (0x09, 0x0A, dan 0x0D tampil sebagai tab dan baris baru); ganti output ke Hex dan periksa blok terakhirnya.
Berapa panjang ciphertext SM4, dan bisakah modenya ditebak dari ciphertext?
Hitung dalam byte. Dengan PKCS#7 pada ECB atau CBC, plaintext dibulatkan ke atas ke kelipatan 16 berikutnya, dan pesan yang sudah kelipatan 16 mendapat satu blok penuh tambahan — 5 atau 15 byte menjadi 16, dan 16 byte menjadi 32. Zero padding hanya mengisi sampai kelipatan 16 berikutnya, tanpa padding panjangnya tetap, dan ciphertext CTR, CFB, dan OFB persis sepanjang plaintext-nya. Hex menggandakan jumlah byte; Base64 memakai 4 × ⌈byte / 3⌉ karakter, jadi 16 byte menjadi 24 karakter, 32 menjadi 44, dan 64 menjadi 88. Tambahkan 16 byte jika IV disertakan di depan. Ciphertext saja tidak mengungkap modenya, tetapi ada dua petunjuk: panjang yang bukan kelipatan 16 hampir pasti menyingkirkan ECB atau CBC dengan padding, dan dua blok 16-byte yang identik mengarah ke ECB. Jika ragu, tempelkan ke tab dekripsi dan diagnosis otomatis akan mencoba mode-mode tersebut untuk Anda.
Apakah SM4 selalu menghasilkan ciphertext yang sama, dan mengapa hasil alat lain berbeda?
ECB — atau mode apa pun dengan IV tetap — selalu menghasilkan ciphertext yang sama untuk kunci dan plaintext yang sama; dengan IV acak baru di setiap proses, output berubah setiap kali, dan memang seharusnya begitu. Di luar itu, bandingkan mode, padding, apakah kunci dibaca sebagai hex atau teks, bagaimana plaintext di-encode — UTF-8 di sebagian besar kode, tetapi GBK saat kode Java lama memanggil getBytes() di sistem Windows berbahasa Tionghoa — dan bagaimana hasilnya dicetak: Base64, hex huruf kecil, atau hex huruf besar. Dengan pengaturan identik dan IV tetap, dua implementasi yang benar menghasilkan output yang identik. Jika Anda mencurigai salah satu alat, uji keduanya lebih dulu dengan vektor uji GB/T 32907.
Bagaimana cara memeriksa apakah implementasi SM4 saya sendiri sudah benar?
Mulailah dengan dua vektor dari Lampiran A GB/T 32907-2016. Dengan kunci dan plaintext sama-sama 0123456789abcdeffedcba9876543210, satu kali enkripsi harus menghasilkan 681edf34d206965e86b3e94f536e4246, dan satu juta enkripsi berantai harus menghasilkan 595298c7c6fd271f0402f804c33d3f66. Keduanya hanya menguji cipher bloknya, jadi selanjutnya enkripsi sebuah teks dalam CBC dengan kunci dan IV tetap, lalu bandingkan dengan halaman ini atau dengan perintah OpenSSL yang ditampilkannya. Mesin di balik halaman ini diuji terhadap kedua vektor tersebut dan terhadap OpenSSL 3 di kelima mode.
Bisakah OpenSSL mengenkripsi dan mendekripsi SM4?
Bisa. OpenSSL 3 menyertakan SM4 dalam ECB, CBC, CFB, OFB, dan CTR. Gunakan openssl enc -sm4-cbc -K <32 hex digits> -iv <32 hex digits>: -K menerima kunci mentah dalam hex, jadi tidak ada kata sandi yang terlibat, -nopad mematikan PKCS#7, dan -base64 -A membaca atau menulis Base64 satu baris. Waspadai dua hal: -sm4 saja berarti CBC, dan nilai -K dengan panjang yang salah akan dipotong atau diisi nol dengan hanya sebuah peringatan. Panel OpenSSL di halaman ini menyusun perintah dari pengaturan Anda saat ini; openssl enc tidak punya zero padding, jadi panel ini menyatakan hal itu alih-alih mencetak perintah yang hasilnya tidak akan cocok.
Bagaimana cara mendekripsi ciphertext SM4 dari Java (Hutool) atau JavaScript (sm-crypto)?
Pertama, cari tahu mode dan padding yang sebenarnya dipakai sisi lain — sering kali kodenya tidak pernah menyebutkannya. SmUtil.sm4(key) milik Hutool hanya meneruskan nama SM4, dan BouncyCastle mengisinya dengan ECB dengan PKCS#7 (PKCS5Padding di Java); hanya string lengkap seperti SM4/CBC/PKCS5Padding yang berarti CBC. Di JavaScript, sm-crypto juga default ke ECB, menerima kunci sebagai string hex 32 digit, dan mencetak hex huruf kecil, sedangkan gm-crypt default ke CBC, menerima kunci teks 16 karakter, dan mencetak Base64. Lalu periksa charset plaintext: method string Hutool selalu memakai UTF-8, tetapi getBytes() tanpa argumen pada JDK 17 atau lebih lama di Windows berbahasa Tionghoa bisa berarti GBK, yang mengubah ciphertext. Pilih library-nya di Cocokkan dengan default untuk mengatur semua ini dalam satu klik, atau masukkan sendiri; jika ada yang belum pasti, tetap tempelkan ciphertext-nya dan diagnosis otomatis akan mencoba kombinasi mode, padding, IV, dan encoding.
Apakah SM4 aman, dan apakah data saya diunggah?
Sebagai algoritma, SM4 memakai kunci 128-bit dan 32 ronde; RFC 8998 (2021) menyatakan bahwa pada saat dokumen itu ditulis tidak ada kunci lemah atau masalah keamanan yang diketahui untuk SM4. Risiko praktisnya datang dari cara pemakaiannya: ECB membocorkan pola dan CBC tidak mendeteksi manipulasi data. Untuk halaman ini, tidak ada yang diunggah. Browser tidak menyertakan SM4, jadi halaman ini membawa implementasi SM4 sendiri dan menjalankannya secara lokal; Anda bisa membuka panel Network dan melihat tidak ada request yang keluar, atau memutus koneksi dan tetap memakai alat ini. Karena itu, halaman ini cocok untuk data uji, debugging, dan belajar. Namun itu tidak menjadikan halaman web tempat yang tepat untuk kunci produksi: kunci seperti itu seharusnya berada di sistem manajemen kunci atau modul perangkat keras, bukan di kotak teks situs web mana pun.
Apa perbedaan SM4 dan AES?
Keduanya adalah cipher blok dengan blok 128-bit, dan mode serta padding bekerja dengan cara yang sama pada keduanya — itulah sebabnya bug interoperabilitas SM4 terlihat persis seperti bug AES. SM4 menjalankan 32 ronde dan hanya punya satu ukuran kunci, yaitu 128 bit; AES-128 menjalankan 10 ronde, dan AES juga punya kunci 192-bit dan 256-bit. SM4 adalah standar nasional Tiongkok GB/T 32907-2016 dan, sejak 2021, bagian dari standar internasional ISO/IEC 18033-3 bersama AES; SM4 dipakai di tempat yang mewajibkan kriptografi komersial Tiongkok. AES adalah standar NIST FIPS 197. Untuk AES, gunakan alat enkripsi AES.

Alat Terkait

Lihat semua alat →

Alat Dekripsi AES — Kompatibel OpenSSL & CryptoJS

Alat Keamanan

Dekripsi AES online — GCM/CBC/CTR, frasa sandi atau kunci mentah, otomatis mendeteksi format OpenSSL & CryptoJS "U2FsdGVkX1". 100% di browser, kunci tidak pernah meninggalkan halaman.

Alat Enkripsi AES — GCM, CBC & CTR

Alat Keamanan

Enkripsi AES online gratis — AES-128/192/256, GCM/CBC/CTR, frasa sandi (PBKDF2) atau kunci mentah. Berjalan 100% di browser Anda; tidak ada yang diunggah.

Generator & Verifier Hash Bcrypt

Alat Keamanan

Buat dan verifikasi hash kata sandi bcrypt online — biaya yang dapat diatur, prefiks $2b$/$2a$/$2y$. 100% di browser Anda; kata sandi tidak pernah diunggah.

Kalkulator Checksum CRC

Alat Keamanan

Tempel data hex atau teks dan dapatkan 63 varian CRC-8, CRC-16, dan CRC-32 sekaligus. Punya checksum yang tidak bisa dicocokkan? Masukkan nilainya dan alat ini menyebut nama variannya — MODBUS, CCITT-FALSE, XMODEM, KERMIT.

Generator HMAC & Verifikator Tanda Tangan

Alat Keamanan

Generator dan verifikator HMAC online gratis. Hitung HMAC-SHA256/SHA1/SHA384/SHA512 dengan kunci Teks, Hex, atau Base64 dan output Hex/Base64/Base64URL. 100% di browser Anda — kunci tidak pernah meninggalkan halaman.

JWT Decoder

Alat Keamanan

Dekode token JWT online dengan dekoder JWT gratis kami. Periksa header, payload, tanda tangan, kedaluwarsa, dan klaim secara instan. 100% browser — token Anda tidak meninggalkan perangkat. Tanpa pendaftaran, tanpa pelacakan.