ASVS 5.0 V11.3.1 (Level 1) requires that insecure block cipher modes, with ECB as the main example, and weak padding schemes such as PKCS#1 v1.5 for RSA encryption are not used anywhere in the application.
Why it matters
ECB encrypts identical plaintext blocks into identical ciphertext blocks, so patterns survive encryption. The famous encrypted image that still shows the original picture is ECB. PKCS#1 v1.5 padding for RSA encryption has a long history of padding oracle attacks that recover plaintext from error behaviour.
How to implement it
For symmetric encryption use an AEAD mode, with a fresh nonce per message:
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
byte[] iv = new byte[12];
new SecureRandom().nextBytes(iv);
c.init(Cipher.ENCRYPT_MODE, key, new GCMParameterSpec(128, iv));
Beware that in Java Cipher.getInstance("AES") silently means AES/ECB/PKCS5Padding. Always name the mode.
For RSA encryption use OAEP, and for signatures use PSS:
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives import hashes
ct = pub.encrypt(data, padding.OAEP(
mgf=padding.MGF1(hashes.SHA256()), algorithm=hashes.SHA256(), label=None))
Better still, avoid RSA encryption of data directly and wrap a random AES key instead.
Try it yourself
Click through it at your own pace, or open it full screen.
How to test it
Search the codebase for /ECB, "AES" with no mode, RSA/ECB/PKCS1Padding, MODE_ECB and PKCS1v15. Add these as failing rules in your static analysis step. Then encrypt a block of repeated bytes in a test and assert the ciphertext has no repeated blocks.
Common mistakes
- Relying on library defaults that pick ECB
- Keeping PKCS#1 v1.5 for "compatibility" with an old partner
- Using CBC without integrity protection as a substitute
Quick check
Why is Cipher.getInstance("AES") risky in Java?
It defaults to ECB mode on many providers, so name the mode explicitly.
