Security reviews often contain a sentence like this: “the data is encrypted with AES.”
That is not enough. AES is a block cipher. It defines how a key transforms one 16-byte block into another 16-byte block. Real messages are often longer than 16 bytes, may contain repeated fields, protocol headers, lengths, padding, and multiple packets.
So the practical question is not only “is it AES?” The real questions are:
- which mode is used
- where the IV or nonce comes from
- how non-16-byte-aligned lengths are handled
- whether ciphertext tampering is detected
- whether decryption errors leak information
- whether a counter or nonce can repeat under the same key
The most useful first model is: AES is the basic block transformation. The mode of operation turns it into an encryption scheme for real messages. The mode decides whether repeated blocks leak, whether padding is needed, what IV/nonce rules apply, whether authentication exists, and whether error handling becomes an attack surface.
AES block cipher:
16-byte block + key -> 16-byte block
mode:
many bytes + key + IV/nonce -> ciphertext
maybe also -> authentication tag
Saying “we use AES” is like saying “we use an engine” without saying whether the vehicle has brakes, steering, or seat belts.
AES Only Handles One Block
AES has a fixed block size of 128 bits, or 16 bytes. In AES-128, AES-192, and AES-256, the number refers to key length, not block size.
At the lowest level:
C = AES_Encrypt(K, P)
P = AES_Decrypt(K, C)
Both P and C are 16 bytes.
Engineering data is usually different:
- device status messages
- JSON or CBOR payloads
- firmware chunks
- file content
- protocol frames and business payloads
Those inputs may be longer than 16 bytes, not aligned to 16 bytes, or structurally repetitive across messages. Modes exist to answer: how do we use a 16-byte block cipher on real messages?
ECB Leaks Repeated Structure
ECB is the most direct and most dangerous mode.
It splits plaintext into 16-byte blocks and encrypts each block independently:
P1 -> AES(K) -> C1
P2 -> AES(K) -> C2
P3 -> AES(K) -> C3
P1 == P3 -> C1 == C3
The problem is that identical plaintext blocks produce identical ciphertext blocks.
An attacker may not know the plaintext, but can still see repeated structure. Images, structured messages, fixed fields, repeated commands, and device states can leak meaningful patterns.
ECB should almost never be used for ordinary business data encryption. It may appear in very low-level constrained constructions where the upper layer has already handled block semantics carefully. In normal engineering review, seeing AES/ECB should raise a warning.
CBC Uses an IV to Break Repetition, but It Does Not Authenticate
CBC XORs each plaintext block with the previous ciphertext block before AES encryption.
The first block has no previous ciphertext block, so it uses an IV:
IV
|
v
P1 -> xor -> AES(K) -> C1
|
v
P2 -----------------> xor -> AES(K) -> C2
|
v
P3 --------------------------------> xor -> AES(K) -> C3
Even if two messages start with the same plaintext, different IVs make the first ciphertext block different, and the chain changes from there.
The important CBC rules are:
- the IV usually does not need to be secret, but it must be generated according to the protocol requirements
- do not encrypt many similar messages under the same key with a fixed IV
- non-16-byte-aligned plaintext needs padding
- CBC provides encryption only, not integrity authentication
The last point is often underestimated. An attacker may not be able to read the ciphertext, but that does not mean they cannot modify it. CBC has no tag, so the receiver cannot know from CBC alone whether ciphertext was altered.
If CBC must be used, it usually needs a MAC, with clearly specified ordering and error behavior. Modern protocols usually prefer mature AEAD instead.
Padding Is a Common CBC Attack Surface
CBC needs to handle plaintext whose length is not a multiple of 16 bytes. A common method is PKCS#7 padding.
If the final block is missing 5 bytes, append five bytes of 0x05. If the plaintext is already aligned, append a full block so decryption can distinguish data from padding.
The receiver must check padding during decryption.
If the system exposes different errors, such as:
- padding error
- MAC error
- format error
- JSON parsing error
an attacker may use those differences to probe plaintext gradually. This is the source of padding-oracle style problems.
A safer rule is: do not design a CBC composition yourself. If legacy compatibility requires CBC, use audited protocol constructions, authenticate ciphertext and context, and avoid exposing detailed error differences.
CTR Turns a Block Cipher Into Stream-Like Encryption
CTR mode does not directly encrypt plaintext blocks. It encrypts a sequence of counters to produce a keystream, then XORs that with plaintext:
nonce || counter1 -> AES(K) -> S1
P1 --------------------------> xor -> C1
nonce || counter2 -> AES(K) -> S2
P2 --------------------------> xor -> C2
Its advantages are:
- no padding
- parallel keystream generation
- arbitrary-length data
- encryption and decryption share the same structure
But CTR has a hard boundary: under the same key, the same nonce/counter range must not repeat.
If two messages use the same keystream:
C1 = P1 xor S
C2 = P2 xor S
an attacker can compute:
C1 xor C2 = P1 xor P2
That leaks relationships between the plaintexts. CTR also does not authenticate, so it needs a separate MAC or an AEAD mode built from counter encryption plus authentication.
GCM Is Encryption Plus Authentication
AES-GCM is a very common AEAD mode in modern protocols.
It roughly combines two pieces:
+-> CTR encryption -> ciphertext -+
key, nonce -+ |
v
AAD ---------------------------------------> GHASH -> tag
GCM is not just another way to encrypt with AES. It provides:
- plaintext encryption
- ciphertext integrity authentication
- AAD authentication
- tag verification
AAD is cleartext context that must not be tampered with, such as protocol headers, device IDs, message types, sequence numbers, or versions.
key + nonce + plaintext + AAD
-> ciphertext + tag
The receiver must verify the tag. If tag verification fails, at least one of ciphertext, AAD, nonce, or key does not match, and business logic must not process plaintext.
GCM’s central requirement is that nonce must not repeat under the same key. Nonce reuse is not a small mistake; it can break both confidentiality and authentication. Deeper nonce persistence, power-loss rollback, and replay handling belong in AEAD nonce design.
CCM Is Common in Embedded and Wireless Protocols
AES-CCM is also AEAD. It combines:
plaintext -----------------> CTR encryption -----> ciphertext
AAD + plaintext + nonce ---> CBC-MAC ------------> tag
Many embedded, low-power, and wireless protocols use CCM because AES hardware acceleration is common and protocol parameters are already standardized.
Like GCM, CCM should not be understood as “encryption only.” It outputs ciphertext plus an authentication tag, and it requires nonce uniqueness within the key scope.
If a protocol specifies AES-CCM, follow the protocol parameters. Do not casually change nonce length, tag length, AAD layout, or counter range.
XTS and KW Are Not General Communication Modes
AES also has specialized modes, such as:
- XTS: often used for disk or block-device encryption
- KW / KWP: used for key wrapping
- CMAC: used for message authentication, not encryption
These modes have their own boundaries. Seeing “AES mode” does not mean it is suitable for protecting device communication payloads.
Communication protocols care about message boundaries, authentication, replay, sequence numbers, session keys, and error behavior. Disk encryption and key wrapping protect different objects. Modes should not be moved between domains casually.
How to Choose for New Designs
For new device communication or application-layer protocols, the order is usually simple.
First, prefer mature protocols such as TLS, DTLS, Noise, OSCORE, or platform security channels instead of designing custom encryption wrappers.
Second, if message-layer encryption is necessary, prefer AEAD:
- AES-GCM: common in general-purpose systems and hardware acceleration
- AES-CCM: common in embedded and wireless protocols
- ChaCha20-Poly1305: software-friendly when AES acceleration is unavailable
Third, consider CBC only for legacy compatibility. Then check all of these together:
- how IV is generated
- how padding is handled
- whether MAC exists
- whether the design is encrypt-then-MAC or something else
- whether error responses create an oracle
- whether keys are separated by purpose
Fourth, ECB should not be used for ordinary business data.
What to Ask When Reviewing an AES Scheme
In security review or field debugging, do not stop at “is it AES?”
Use this path:
what AES mode is used
-> is it AEAD
-> does IV / nonce satisfy the mode requirement
-> is padding needed
-> are ciphertext and context authenticated
-> does tag / MAC failure stop processing
-> can counters repeat under the same key
-> do error responses leak padding or parsing details
-> can a mature protocol replace the custom composition
If the symptom is “occasional decryption failure,” “only fails after reboot,” “server reports tag error,” or “old devices interoperate but new devices do not,” focus on mode parameters, IV/nonce, padding, tag length, and protocol version.
The Boundary to Remember
AES is a reliable primitive, but “using AES” is not a complete security design.
ECB leaks repeated structure. CBC needs IV and padding, and it does not authenticate by itself. CTR avoids padding, but nonce/counter must not repeat and it does not authenticate. GCM and CCM are AEAD modes, providing encryption and authentication together, but they still have strict nonce, tag, AAD, and error-handling requirements.
A better engineering statement is not “encrypt with AES,” but:
which mode
how IV / nonce is generated
whether data is authenticated
how tag / MAC is verified
what happens on failure
If the mode or composition is wrong, the system may not fail immediately. It may appear to work for a long time while the security boundary has already collapsed.