SM4 cipher

The key must decode to exactly 16 bytes (128 bits) and the CBC IV to 16 bytes as well — so in hex that's 32 hex characters, and in base64 a 24-character string ending in ==. The format option sets the encoding for the key, IV, and ciphertext together; the plaintext side is always plain UTF-8 text.

Both modes use PKCS#7 padding, and that padding is verified on decrypt — a wrong key, wrong IV, wrong mode, or a ciphertext pasted in the wrong encoding (hex vs base64) almost always produces invalid padding and this error. If the padding does check out but the recovered bytes aren't valid UTF-8, you'll get a separate "not valid UTF-8 text" error instead.

ECB takes no IV, which makes it convenient for interop tests and verifying known-answer vectors — but identical plaintext blocks encrypt to identical ciphertext blocks, leaking structure. For anything real, use CBC (the default) with a fresh random 16-byte IV per message.

Yes. This is standard SM4 per GB/T 32907-2016 (the implementation reproduces the specification's known-answer test vector) with PKCS#7 padding, so ciphertext exchanges cleanly with OpenSSL's -sm4-cbc/-sm4-ecb and other GM/T-compliant libraries as long as the key, IV, mode, and encoding match.