AES ECB encryption with padding and no padding in java language.

Hello there!

When working with AES encryption in Java, one important thing to understand is how AES handles input length, especially when using ECB mode with padding and no padding.

AES is a block cipher, which means it encrypts data in fixed-size blocks. For AES, the block size is always 16 bytes.

Because of this, the input data must fit into 16-byte blocks before it can be encrypted.

AES ECB With Padding

When you use AES ECB with padding, Java will automatically adjust the input length so it becomes a multiple of 16 bytes.

For example, if your input is less than 16 bytes, padding will be added automatically until the total length becomes 16 bytes.

The calculation looks like this:

Input length 1–15 bytes   → encrypted as 16 bytes
Input length 16 bytes     → encrypted as 32 bytes
Input length 17–31 bytes  → encrypted as 32 bytes
Input length 32 bytes     → encrypted as 48 bytes
Input length 33–47 bytes  → encrypted as 48 bytes
Input length 48 bytes     → encrypted as 64 bytes
Input length 49–63 bytes  → encrypted as 64 bytes

In short, padding makes sure the input is always aligned to the AES block size.

One important note: with common padding such as PKCS5Padding/PKCS7Padding, even if your input is already exactly 16 bytes, an additional 16-byte padding block is usually added. This is why 16 bytes can become 32 bytes after encryption.

AES ECB With No Padding

When using AES ECB with NoPadding, Java will not automatically adjust the input length.

This means your input must already be a multiple of 16 bytes before encryption.

For example:

16 bytes  → valid
32 bytes  → valid
48 bytes  → valid
64 bytes  → valid

But if your input is not a multiple of 16 bytes, the encryption process will fail.

For example:

5 bytes   → invalid
15 bytes  → invalid
17 bytes  → invalid
31 bytes  → invalid

Java will usually return an error like this:

javax.crypto.IllegalBlockSizeException: Input length not multiple of 16 bytes

This happens because AES with NoPadding expects the data to already match the required block size.

Simple Difference

The main difference is:

AES/ECB/PKCS5Padding
→ Java automatically adds padding to match the 16-byte AES block size.

AES/ECB/NoPadding
→ You must manually make sure the input length is already a multiple of 16 bytes.

Important Security Note

Although ECB mode is simple and easy to understand, it is generally not recommended for secure applications.

ECB encrypts the same plaintext block into the same ciphertext block. This can expose patterns in the encrypted data.

For real-world applications, it is usually better to use a more secure mode such as:

AES/GCM/NoPadding

or, in some cases:

AES/CBC/PKCS5Padding

with a proper IV.

Conclusion

AES encryption requires data to be processed in 16-byte blocks.

If you use padding, Java will automatically handle the block-size requirement for you.

If you use NoPadding, you must ensure the input length is already a multiple of 16 bytes, otherwise Java will throw an IllegalBlockSizeException.

So, for most normal use cases, using padding is easier and safer from an implementation point of view. But for production security, always choose the encryption mode carefully and avoid ECB unless you have a very specific reason to use it.