Common mistakes
Cryptography in papers is neat; in applications it fails at the edges — key storage, randomness, error handling and protocol design.
In this lesson
- Spot the ten most common crypto mistakes
- Explain why each one is exploitable
- Apply a short pre-merge checklist
The usual suspects
-
1
Rolling your own algorithm
Every self-designed cipher eventually leaks. Use audited, standardised primitives.
-
2
Weak randomness
Predictable nonces and tokens (rand(), timestamps) let attackers guess keys and session IDs.
-
3
Hard-coded keys
Keys in git, APKs or Docker images are public keys with extra steps.
-
4
Ignoring authentication
Encrypting without a MAC/GCM lets attackers modify ciphertext (bit-flipping attacks).
-
5
Bad error handling
"Invalid padding" vs "wrong password" oracles (Padding Oracle) turn a leak into full decryption.
-
6
No key rotation plan
Keys live forever because nobody planned revocation.
Example · When "encrypted" still leaks
A payment app stored card data with AES-ECB. Identical card numbers produced identical ciphertext blocks, letting an analyst group customers without ever breaking AES. The cipher was fine; the mode was wrong.
Speed is not the goal — correctness is
If you cannot explain why your scheme is safe in one paragraph, treat it as unsafe. Cryptography rewards boring, standard choices.
# good: authenticated encryption from a vetted library\nfrom cryptography.hazmat.primitives.ciphers.aead import AESGCM\nimport os\n\nkey = AESGCM.generate_key(bit_length=256)\naes = AESGCM(key)\nnonce = os.urandom(12) # unique per message\nblob = aes.encrypt(nonce, plaintext, associated_data=b"context")Is encryption enough on its own?
No. You also need authentication, safe key storage, secure randomness, revocation and audit logging.
How do I know my code is safe?
Use a vetted library, follow the platform guidance, and get a review for anything handling long-lived secrets.
Attacks never go where the maths is — they go where the implementation is.