AES Encryption and Decryption: Modes, IVs, and Padding for Testers

Advanced Encryption Standard (AES) is the workhorse symmetric algorithm for modern payment platforms—protecting keys at rest, wrapping key material, securing TLS payloads, and underpinning many MAC constructions when combined with proper modes. Yet “we use AES” is never enough for a certification binder: auditors and integration partners want named modes, explicit IV/nonce rules, and unambiguous padding behavior.

This guide frames AES the way payment labs need it: as a contract between components that must produce byte-identical results under pinned inputs. ISO8583Studio (iso8583.studio) is a free desktop app for Windows, macOS, and Linux with 70+ tools spanning cryptography (AES, DES/3DES, RSA, ECDSA, hash, FPE), Host Simulator, HSM Simulator (PayShield 10K), EMV utilities, and payment primitives.

AES key sizes: 128, 192, and 256 bits

AES supports:

Your test plan should name the key size explicitly. “AES key” without length is an invitation for two teams to ship incompatible clients.

ECB: test vectors, not production privacy

ECB encrypts each block independently (16 bytes for AES). It is easy to implement and debug, which is why it survives in unit tests. It is a poor choice for structured plaintext because repeated blocks yield repeated ciphertext.

Use ECB in the lab to validate primitive correctness:

C = AES_Encrypt(K, P)   // single-block sanity checks

Then move to a mode appropriate for real data.

CBC: IV plus chaining

CBC XORs each plaintext block with the previous ciphertext block before AES; the first block uses an IV.

Rules testers must freeze in documentation:

• IV length equals block size (16 bytes for AES).
• IV must be unpredictable for many threat models; for repeatable tests, pin a fixed IV and record it.
• Decryption requires the same IV—without it, only block two onward can sometimes be recovered in partial fault scenarios—your harness should treat IV as mandatory metadata.

Common pitfall: two systems “match” except one prepends the IV to the ciphertext while the other stores it separately. Always define a wire format.

CTR: treat the counter as a nonce stream

CTR turns AES into a stream cipher by encrypting a counter/nonce sequence and XORing with plaintext. It parallelizes well and avoids padding if you handle length at the message layer.

Rules testers must freeze:

• Nonce uniqueness under the same key is non-negotiable. Duplicate nonce usage can catastrophically break confidentiality.
• Define endianness and counter width—implementations differ.

CTR is attractive for high-throughput pipelines, but your test vectors must specify the exact counter block evolution.

Padding: PKCS#7 vs “no padding”

For modes that operate on blocks (notably CBC), messages often use PKCS#7 padding to reach a multiple of 16 bytes. Test edge cases:

If your system uses authenticated encryption (e.g., AES-GCM), padding stories change—your spec must name the AEAD mode and tag handling. ISO8583Studio focuses testers on core symmetric workflows; always align with your security architecture for production.

Practical encryption testing workflow

1. Choose a canonical message — short, medium, long; include non-ASCII if your channel allows UTF-8.
2. Pin K, IV/nonce, mode — write them in hex in your test case.
3. Encrypt — capture ciphertext hex.
4. Decrypt — round-trip must match bit-for-bit.
5. Negative tests — flip one ciphertext bit; decryption should fail or produce garbage under your integrity rules.

Worked example (conceptual)

Suppose you select AES-256-CBC with PKCS#7:

• K = 32-byte key
• IV = 16-byte IV
• P = plaintext bytes

Your ciphertext C should decrypt only when (K, IV) match. Change IV by one bit and confirm your test harness flags the mismatch—this proves your logs bind IV correctly.

Performance vs correctness

AES is fast in hardware and modern CPUs. For payment testing, prioritize determinism over micro-optimizations: stable libraries, pinned versions, and reproducible vectors beat shaving microseconds in a lab harness.

Using ISO8583Studio in symmetric crypto work

ISO8583Studio bundles AES alongside DES/3DES, RSA, ECDSA, hash functions, and FPE—plus payment utilities (CVV, PIN block, DUKPT, MAC/HMAC/CMAC) and key-management calculators (Thales, Futurex, Atalla, SafeNet, TR-31, keyshare, DEA keys). That makes it straightforward to connect “AES wrap step” with “key block parse step” in one desktop session—without exporting sensitive material to browser-based sandboxes.

Conclusion

AES is simple in concept and rich in footguns: mode selection, IV/nonce discipline, padding, and wire formats must be specified like any wire protocol. Get ISO8583Studio at https://iso8583.studio for a free, cross-platform desktop toolkit that supports practical encryption testing alongside the broader payment and EMV workflows your team already runs.