Cyberlium

Cryptography › Module 4 › Lesson 1

BeginnerModule 4Lesson 1/4

Common Crypto Mistakes

Avoid homebrew crypto, reused nonces, and rolling your own protocols

15 min+19 XP3 quiz
Module progress1 of 4
Padlock on fragile string · Human error

Opening

Do not invent cryptography at 2 a.m. — and do not ship a “broken cipher” to practice on other people.

Attackers rarely need to factor AES-256. They find a reused nonce, ECB screenshots of a penguin that still looks like a penguin, a key hardcoded in a public repo, verify=False on a login client, or a custom “encryption” that is XOR with a password. Those are engineering mistakes. This lesson names them so you AVOID them. It does not hand you a working toy cipher and a target list. “Broken crypto” as a weapon against someone else’s app is out of scope. “I will not roll my own protocol” as a habit is the point. You will write a hall-of-shame checklist into $HOME/cyberlium-lab — what not to do, which libraries to prefer, and the ethics line. You will not implement a homebrew cipher to attack a classmate’s homework server. You will not disable TLS verification in a script you then point at a bank. Next — Key Management Basics — is how secrets are generated, stored, rotated, and revoked without landing in git or chat.

1. Homebrew and rolled protocols: novelty is a research paper, not a payment path

A cryptographic algorithm that survived public attack for years is boring on purpose. AES-GCM, ChaCha20-Poly1305, SHA-256, Argon2, TLS 1.3 libraries in your language’s standard or well-maintained packages — those are the default. Homebrew is: XOR with a repeating key, “encrypt” by reversing strings, a custom substitution table, a secret algorithm whose only defense is that nobody has seen the code. Secrecy of the algorithm is not a substitute for a key (Kerckhoffs’s principle: assume the method is public). This course will not print a broken cipher for you to point at other systems. If you need to see why XOR-with-a-password fails, read a textbook later — do not use this app as an attack workbook. Rolling your own protocol is the cousin: inventing a handshake in JSON because TLS “looked heavy,” inventing a MAC by appending MD5 of the password, inventing a token format that is base64(userid) and calling it signed. Use TLS for transport. Use vetted token libraries if you need tokens. Use vetted password hashes (slow KDF, unique salt) if you store passwords. The moment you type encrypt() as a 20-line function in a product, you are the incident.

2. Modes, nonces, and verify=False: the math can be fine while the wiring is on fire

ECB mode encrypts each block independently. Patterns leak. The classic warning is an image that still shows its outline after “encryption.” Do not use ECB. Modern systems want authenticated encryption (AES-GCM, ChaCha20-Poly1305) so ciphertext cannot be silently flipped. GCM and similar AEAD modes require a nonce (IV) that must not be reused with the same key. Reuse can destroy confidentiality — that is a famous footgun, not a puzzle this course will help you exploit against a live app. Operational rule: let a high-level library generate nonces; never hardcode IV=0; never copy a nonce between messages “to keep it simple.” verify=False (or equivalent) in an HTTP client turns TLS into encryption to whoever answered. An active attacker presents any certificate. You already know from Module 3 that authentication is the other half of the padlock. Disabling it in production because a lab CA was annoying is how you undo three lessons. Fix the trust store properly on machines you own, or fix the server certificate. Do not globally ignore hostname checks. Do not ship a client that skips verification “just for debugging” and then forget.

Hall of shame — recognize and refuse. This list is a stop sign, not a lab menu for attacking others.

  • Homebrew ciphers

    Custom algorithms and “secret” encodings. Use vetted libraries. Do not build a broken cipher to attack someone else.

  • ECB / nonce reuse

    Patterns leak; IV/nonce reuse with the same key can wreck AEAD. Let libraries generate unique nonces.

  • verify=False

    TLS without authentication is a private chat with a stranger. Never a production default.

  • Keys in source/chat

    Repo leaks equal total compromise. Next lesson is the lifecycle. Toy keys only in this topic.

3. Wrong vs right: attacking others with a toy cipher vs refusing homebrew and locking a checklist

Worked failure — treating “common mistakes” as an exploit syllabus. Right is avoidance plus boring libraries.

  • Wrong

    Implement XOR-crypto and point it at a classmate’s API. Reuse a nonce on purpose against a live GCM service “to practice.” Commit verify=False to production. Paste a real AES key into Discord. Call custom base64 a protocol. Publish a broken cipher gist titled “use this on company VPN.” Any attack on systems you do not own stays illegal.

  • Right

    Write the avoidance list: no homebrew, unique nonces from libraries, authenticated encryption, TLS verification on, no keys in git. Prefer boring APIs. Notes in $HOME/cyberlium-lab, chmod 600, no live secrets. Next: Key Management Basics.

4. Practical: crypto-mistakes-notes.txt — a stop list, not a weapon

The file is a checklist you can reread before you merge code. It contains forbidden patterns and the replacement (vetted library, unique nonce, verify on). It does not contain a cipher implementation. It does not contain a live key. chmod 600 because Module 4’s lab folder will also hold a lab passphrase. Empty notes fail. Notes that include an attack script fail ethics even if you titled them “defensive.”

Command guide

crypto-mistakes-notes.txt — avoidance checklist, YOUR lab, no attack cipher

DEFENSIVE checklist. Do NOT implement a homebrew cipher here. Do NOT use this file as an attack plan against anyone's system.

Command — copy this

mkdir -p "$HOME/cyberlium-lab"
NOTES="$HOME/cyberlium-lab/crypto-mistakes-notes.txt"

Command — copy this

{
  echo "=== COMMON CRYPTO MISTAKES (AVOID) ==="
  echo "1 Homebrew: no XOR-password 'ciphers', no secret algorithms. Use vetted libs (AES-GCM / TLS 1.3 stacks)."
  echo "2 Do not roll your own handshake or MAC. Use TLS for transport. Use slow salted KDFs for passwords."
  echo "3 ECB: do not use. Prefer authenticated encryption (AES-GCM, ChaCha20-Poly1305)."
  echo "4 Nonce/IV: never reuse with the same key. Never hardcode IV=0. Let the library generate."
  echo "5 verify=False / skip hostname checks: never production. Fix certs; do not disable TLS auth."
  echo "6 Keys in git/chat: never live secrets. Toy keys only. Next lesson: generate/store/rotate/revoke."
  echo ""
  echo "replacement: boring high-level crypto APIs with safe defaults"
  echo "ethics: this list is a STOP sign — not a broken-cipher kit to attack others"
  echo "no live API keys, no production PEMs, no classmate targets"
} > "$NOTES"

Command — copy this

chmod 600 "$NOTES"

Windows without chmod: WSL/Git Bash, or restrict the file in your profile.

NEVER: paste a live key into this file NEVER: add an XOR implementation "to demo the mistake" against a live host NEVER: commit verify=False in an app that talks to real users

Mission: crypto-mistakes-notes.txt avoidance list (mode 600)

1) In your own words, list homebrew ciphers, rolled protocols, ECB/nonce reuse, and verify=False as mistakes to AVOID. 2) Write the replacement: vetted libraries, unique nonces, authenticated encryption, TLS verification on. 3) Save as $HOME/cyberlium-lab/crypto-mistakes-notes.txt and chmod 600. Do not include a working broken cipher. Do not point anything at systems you do not own. No live keys.

Stuck? Ask Cyberlium AI Mentor

If “I should code a weak cipher so I understand attacks” still feels like this lesson, ask for a hint — not a payload. Try: "Hint only: why is homebrew a stop, what does nonce reuse break conceptually, why is verify=False TLS theater, and why must I not ship a broken cipher against other people?" You still fill the notes. No live keys. No classmate targets.

You now treat most crypto failures as wiring, not as “AES got solved.” Avoidance is the skill: boring libraries, unique nonces, verification on, no homebrew weapons. Next — Key Management Basics — generate, store, rotate, and revoke keys without leaving secrets in chat or git. Toy keys only. Then a lab that hashes and encrypts a sample file YOU created with a lab passphrase you will not reuse.

Knowledge Check

1

APPLY: A teammate wants to XOR a password with the data “because AES is slow,” reuse IV=0, and test it against a public API they do not own. What is the common real-world failure class, and what do you refuse?

Multiple choice

Knowledge Check

2

APPLY: True or False: Disabling TLS verification in production is safe if the code is Python, and you should include a working broken cipher in the lab notes so classmates can attack each other.

True or False

Knowledge Check

3

APPLY: Hardcoding a live API/crypto key in git is on the hall of shame. Why, and what belongs in crypto-mistakes-notes.txt instead?

Multiple choice

← Previous

Answer all 3 knowledge checks to continue. (0/3 answered)